Regarding Tickle Task, What happens when most of the targeted computers are in a low power state?
Symantec documentation states this about the tickle task: HOWTO60817
“This task uses a "proxy agent" as configured in the Targeted Agent Settings to send a broadcast packet to the sleeping computer. It also ships with the main SMP product for free. It works by first finding a computer on the same "last known" subnet as the target, sending a packet to the agent on this subnet, which then sends out a broadcast packet with a target of the known MAC for the client you are trying to wake up. If there are no active or responding systems on that subnet, it will fail.”
This mean that at times when most of the computers in the environment are asleep (e.g. at night or on the weekend) there may be no active systems on the subnet to act as the proxy and the task will fail.
In order to ensure that the Tickle task is able to wake a computer there needs to be at least one computer powered on in each subnet.
Another thing to consider is that we only target 20 computers in that subnet and those are sorted by the 20 most recent active computers (like recent configuration requests or sending data (NSE messages)). As well you need to “Enable tickle on Symantec Management Agents” option under “Settings>Agents/Plug-ins>Symantec Management Agent>Settings>Symantec Management Agent Settings – Targeted” for the desired Targeted AgentSettings policy in order to allow the client machines to become as a Proxy client for Tickle/Power Management usage.
What is the difference between the tickle client and power control?
Both uses the same concept of broadcast packet with a MAC address on it.
Power Management uses Task Servers to broadcast the broadcast packet. The targeted machines needs to be registered to that Task Server, as well they need to be in the same subnet for the Task Server to receive the broadcast packet. Otherwise, you will need to enable on your switch/router “forwarding” functionality to send the broadcast packet between subnets.
Tickle Client Task uses computers in the same subnet as proxies to broadcast the broadcast packet and one of those proxies needs to be turned on.
Power control has always been a broadcast from the task servers to the targeted agents. This means that with that task the task server need to either be in the same subnet or that routers must be configured to allow forwarding of the broadcast packets. This has not changed with ITMS 7.1 SP2 MP1 and will not be changed in ITMS 7.5. The power control is typically used by DS type operation that are expect to be in the same subnet as the DS task server.
For the ongoing use of WOL once in production is better served by the tickle client task which uses other agents in the same subnet to deliver the WOL packet to the targeted machines. This will continue to be supported going forward in our 7.5 release.
To your knowledge will the “Tickle Client” task currently available in 7.1, going to continue to be available in 7.5 for WOL with its unique ability to use other agents to relay the WOL packet? Are you aware of a time when the “Power Control” task did have the ability to send the WOL packet across subnets, or was the “Power Control” task always limited?
Indeed, there are 2 types of WOL implementation:
1.The legacy tickle functionality using a server task of type “Tickle Client”. The settings for it is what you find in the Global Agent Settings and Targeted Agent Settings.
2.And the new one available through a task server task (i.e. it runs on Task Server (TS)) and is part of the “Power Control” task type (which is actually a client task except for WOL). This is what, for example, Managed Software Delivery policy is using. If you select the checkbox to wake the computer up before installing software. The new functionality does not have any settings under Global or Targeted Agent Settings and is not affected by the legacy Power Management Tickle settings.
The two implementations are somewhat different. The legacy one causes Notification Server (NS) to connect to some active client in the same subnet at the machine to be woken up and tells it to send the WOL packet to the target. As the result:
·This works across subnets (so long as you have an active client in the same subnet as the target machine).
·This requires Agent to listen to a TCP port (which is why there is Targeted Agent Settings policy setting which specifies whether clients should listen to the port or not).
·If the target subnet is behind NAT or is otherwise inaccessible for NS, then NS will not be able to contact Agent and wake up the computer.
The new implementation finds the task server that the target machine to be woken up is assigned to and tells that task server to wake up the machine by sending the WOL packet. As the result:
·This works with TS can access client when NS cannot.
·This does not work across subnets (i.e. if TS and target machine are on different subnets and routers/switches between them are not configured to allow WOL packets to propagate).
·At some point testing showed that over time TS may stop recognizing the sleeping machine as its own and may refuse to wake it up.
Thus, “Power Control” task does not appear to have the ability to relay the WOL packet through other agents in order to reach agents not in the same subnet as the task server. Whereas, “Tickle Client” should satisfy your needs and it should still work across subnets.
Are there any plans to fix the limitations of "power control" so that it can function across subnets or is the legacy task the way customers should always plan on doing WOL?
Currently, there are no plans to change/fix behavior of WOL functionality in Power Control task. It was designed for uses cases when Task Server (TS) has access to machine that should be woken up. So, if TS and target machine are on different subnets and routers/switches between them are not properly configured, I suppose the legacy Tickle Client task is the way customers should go.
HOWTO60817 "How does WOL work in the Symantec Management Platform version 7.x?" TECH199794 "When WOL (Power on computers) is enabled on a Managed Software Delivery Policy, the WOL Compliance task runs on all discovered resources not just the targeted resources" HOWTO1429 "What happens when I use the power management options in a Software Delivery task?" HOWTO8057 "How an NS Agent becomes a Wake-On-LAN (WOL) Relay Agent" HOWTO5093 "What is Power Management or WOL (Wake on LAN)?" HOWTO1436 "NS 6 Power Management" TECH42507 "Wake-On-Lan (WOL) is not working when machine is in hibernate or in standby mode." HOWTO25944 "How is a relay agent selected in Notification Server for Wake on Lan?" TECH127251 "Computers not being selected as relay agents for Wake-On-LAN" HOWTO9394 "How Power Management Works"
Imported Document ID: HOWTO84716
Subscribing will provide email updates when this Article is updated. Login is required.