KNOWN ISSUE: TS6, TS7: Task Server Power Control and WOL (Wake on LAN) tasks don't work.
|Article:TECH38547|||||Created: 2008-01-16|||||Updated: 2010-04-30|||||Article URL http://www.symantec.com/docs/TECH38547|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
I have created a Task Server Power Control Task using the Wake on LAN (WOL) option to wake up client computers. Unfortunately when I send this task out to the client, it does not wake up. Using the Notification Server Wake on LAN function does wake the computer up correctly, as do other external applications.
Usually, this is caused by the broadcast packet being sent from the Task Server getting blocked by the Routers. Broadcast packets are routinely blocked to prevent broadcast storms that can happen either accidentally or maliciously on a network. Unfortunately, older versions of Task Server sends out a broadcast packet that is routinely blocked.Other causes can include the Task Servers not functioning correctly (since the packet is sent from a task server), Maintenance windows (v7 only) and missing client information. This KB though will assume that the product is working as designed along with troubleshooting steps to determine that. If you have other issues not related to this product design issue, there are different KB's that help troubleshoot Task Servera and tasks.
This has been corrected in SMP 7.0 SP3. NS v. 6.x does not have a release date set for this fix.
What is now done in SMP v7.0 SP3, is 2 packets are sent, from the task server to which the client last checked into. Both are UDP "magic packets" with the MAC of the destination client in them. If UDP is blocked, obvioiusly they will not arrive. One of the packets is sent to 255.255.255.255, and the other to X.X.X.255 where X.X.X = the first 3 octets of the destination client's last known IP address.
Remember, these packets are only sent once and only from the task server you are connected to. This is a screen shot of a Wireshark trace of SMP 7.0 SP4 HF1 and a single WOL task:
It should be noted that the NS address is 192.168.0.56, the Site Server is at 0.16, the client at 0.34. The MAC listed in the packet is the mac for the client. (00:15:...:42:25)
To determine if you are seeing this issue or something else, you should do the following:
- Determine the Task Server to which the client connects (generally easiest by double-clicking the Task Trey icon and selecting the Task Tab).
- Set up a Wireshark trace either on or on the same subnet as the Task Server to pick up any traffic from the Task Server prior to reaching the routers. The filter should be at least udp.port, or you could be more specific.
- Set up a Wireshark trace on the same subnet as the client with the same filters as for the Task Server.
- Create and send a WOL task to the client.
- Watch the Site Server wire-shark to ensure the packet is sent. You can stop both traces at the same time.
If the job is never sent, consider checking for other problems, such as Maintenance Windows (v7 only) or possibly the Task Server services not running.
If you see the WOL packets on the server but not on the client, then you know the router is blocking the traffic. If you only see the broadcast packet and not the directed task, you are proabably using a version of the product prior to SMP 7.0 SP3 where this issue was corrected.
|Description||Logged in Littlebuggy (Altiris - Lindon, Plymouth) database|
|Description||Logged in Etrack (Symantec) database|
Article URL http://www.symantec.com/docs/TECH38547