Power Management Functionality

Products

• IT Management Suite

Issue/Introduction

How does Power Management work?

Environment

ITMS 8.x

Resolution

How Power Management Works

Tickle—Server Side

One of the commands of power management is “tickle”. To tickle an agent is either asking the agent to send basic inventory or to get configuration or both.

Clients reject tickles that don’t come from the Notification Server that they report to. There is a registry key on the agent called TrustedServer that stores the name of the Notification Server that the agent is managed by. Each tickle contains the sending server name and, if that doesn’t match TrustedServer, then the packet will be ignored.

To tickle the client computers, Notification Server uses the FQDN from the Inv_AeX_AC_Identification table to do a DNS lookup to get the IP address. If that fails, Notification Server uses the IP address for the resource from the Inv_AeX_AC_TCPIP table.

If a tickle applies to only one computer in a particular subnet, a tickle packet containing the desired requests (send basic inventory and or request configuration) will be sent directly to that computer.

If the direct fails, Notification Server performs the Wake on LAN operation (see below) and waits 5 minutes for the computer to boot and then performs a multicast operation.

If the tickle applies to multiple IP addresses and all computers exist on the local subnet, Notification Server performs a broadcast Wake on LAN, waits 5 minutes for the target computers to boot up, and then does a multicast.

Notification Server will multicast the packet to all computers. The clients on the subnet will receive the packet, determine whether the packet contains its IP address and, if so, perform the functions.

If the tickle applies to multiple computers and these computers are located on other subnets, Notification Server starts a process to locate a relay agent on each subnet that will perform the multicast. Most level 3 devices don’t process broadcast packets or can be configured to reject broadcasts. Because multicast is a type of broadcast, a direct multicast broadcast from the server may be blocked from other subnets. As such, Notification Server attempts to locate a Relay Agent on each subnet to perform the multicast/broadcast function.

The subnet or the relay computers are never pinged to determine whether or not they are alive. Instead a heuristic is used to determine the most suitable relay computers (using data from the Notification Server database). For example, for each subnet, Notification servers will be given the highest priority, then Package Servers, and lastly all other computers in that subnet ordered by the time the computers last communicated with the Notification Server (the more recent the communication, the higher the priority). This list is then iterated (to a maximum level of 50) until communication with a Relay computer is successful.

We establish a direct connection to the proxy agent on the TCP/IP defined in the global power management settings (def 52028). If this direct TCP/IP connection fails, we know the agent is not "alive."

If all 50 of the selected computers in that subnet are switched off, the packet will not be delivered to that subnet.

If computers have multiple IP addresses, the Notification Server will transmit the power management package to all addresses assigned to a computer. The Agent will receive the packet on all IP addresses but the Agent will only send basic inventory or request configuration once.

All target IP addresses are resolved using DNS and, if the IP address returned is different than the one stored in the Notification Server database, then the target is contacted directly (as we can no longer determine what subnet it belongs to) otherwise the target is contacted via a group multicast operation inside its subnet.

Notification Server delays requests according to how many requests are made at the one time; this will adjust the window of time that the agent will perform the specified command.

The target hosts are told to pick a random time within a window. The formula for the window is 1 minute for every 500 hosts, rounded down. Therefore, for 1200 computers, they will be instructed to pick a random point in a two-minute window to contact the Notification Server. This setting cannot be overridden.

There are two multicast protocols: sparse and dense mode. Sparse mode and dense mode are for a different application of multicasting. Power Management uses the dense mode, but this is irrelevant to our application. We do not cross IP subnets with our multicast. We only send to local subnets. If a client in another subnet needs to be contacted, we use a proxy agent. We do not support the functionality of allowing a client to subscribe/unsubscribe to the multicast. This functionality is aimed at data streaming services. Our application of multicast is used to send data to a number of hosts at once. The list is determined by Notification Server and not by clients subscribing to a stream.

Tickle—Client Side

The client must be listening on at least a TCP/IP port. It does not require for both a multi-cast IP address and multi-cast port to be specified. However, using just the TCP/IP port will only work when there is one target and the command is not Wake on LAN.

To confirm that the Altiris Agent is configured for power management, you need to check the following registry settings (none should be zero, they should match server settings):

• \HKLM\SOFTWARE\Altiris\Communications\Multicast Port
• \HKLM\SOFTWARE\Altiris\Communications\Multicast Address
• \HKLM\SOFTWARE\Altiris\Communications\Listener Port

If the global multicast IP addresses and ports are changed on the Notification Server, once the Agent downloads a new policy containing the addresses, its network monitor will notice and start listening through the new IP address and ports automatically.

After clients are tickled, they will de-synchronize their next configuration request and/or send basic inventory to a random interval between half the request interval and the full request interval.

For example: If you tell a large group of computers to immediately send basic inventory, they will all reset their “last sent time”. If they all have the same basic inventory interval then, theoretically, they would all send again after the interval expires. This could create an artificially high load on the server as all agents are now synchronized to send at the same time. To prevent this from occurring, a random interval between half and the full interval is chosen. If the interval is set to one hour, a random time between half and one hour would be used.

After disabling Power Management on Notification Server, the user must wait until the next time the Altiris Agent requests configuration before it will stop listening.

When a command is made for an Agent to send basic inventory, it will send regardless of whether basic inventory has changed since it last sent.

Tickle commands will ignore block-outs configured on the agent, and send basic and request configuration regardless.

Wake on LAN

The other command of power management is Wake on LAN.

Wake on LAN messages are broadcast packets. Thus, the only way to send a Wake on LAN message is to send it to an agent that will relay the packet onto the rest of the subnet.

The subnet or the relay computers are never pinged to determine whether or not they are alive. Instead a heuristic is used to determine the most suitable relay PCs (using data from the Notification Server database). For example, for each subnet, Notification servers will be given the highest priority, then Package Servers, and lastly all other computers in that subnet ordered by the time the computers last communicated with the Notification Server (the more recent the communication, the higher the priority). This list is then iterated (to a maximum level of 50) until communication with a Relay PC is successful.

We establish a direct connection to the proxy agent on the TCP/IP defined in the global power management settings (def 52028). If this direct TCP/IP connection fails we know the agent is not “alive.”

The relay computer on the target’s subnet performs the broadcast that will wake up the specified target with the unique MAC address.