WOL in the Symantec Management Platform
Article ID: 180743
Updated On:
Products
Issue/Introduction
This document will attempt to outline the various methods of waking a computer (Wake on LAN or WOL) currently supported by the Symantec Management Platform and related plug-in products. There are several, and some details may be missed, but we'll add information as we find it.
Environment
ITMS 8.x
DS 8.x
Resolution
Related Questions:
- Why doesn't my WOL task work? WOL is failing.
- What are the requirements for WOL to work?
- What ports must be open for WOL?
WOL Use Cases:
The general use case in this article is for waking a computer that is actually off. There are several scenarios that may be involved in this activity including remote computers (not directly connected to the corporate network), computers in remote corporate locations, and more directly connected computers. What this article will not discuss are ways in which to get a computer that is actually on to respond. We often refer to this as a "Tickle" just like #2 under Methodologies, and though it bears a resemblance to a WOL request it is not the same. Regardless, we will not discuss the application of WOL packets in this article.
WOL Methodologies:
There are actually several ways to wake a system in SMP 7.x, including:
- task: Power Control
- task: Tickle Client
- task: Power Management
- SWD Power on computer if necessary
- Resource Manager
How they work:
1 Task: Power Control.
This task ships with the core product (free) and is Task-Server based. The idea is that we tell the Task Server to which the client last connected to try to reach the client. The task server does this with two packets: one is a broadcast packet, destination 255.255.255.255. this first packet is a UDP Packet that broadcasts the "magic packet" to the environment on which the server resides. The second packet is a TCP packet. This TCP packet is broadcast to the Tickle agents (Site Servers and designated clients). The first packet (UDP) is blocked by most routers due to the nature of the packet, and thus only works on the local segments. The second packet, being a TCP packet, is sent to each tickle agent which then broadcasts within their local segment the "magic packet". The "magic packet" is a targeted broadcast to the MAC Address of the targeted machine. The Altiris "Wake on LAN" follows the standard conventions of industry standard for WoL.
2 Task: Tickle Client - see the article, Understanding and Troubleshooting the Tickle Agent task
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. And, because we don't know in "real time" which agents are active (vs the first method above that uses Task to know about current active status), it can be a bit of a hit and miss.
3 Task: Power Management
This task is also free and ships with the main SMP product as a part of RTCI. There are actually several possible protocols the task will attempt to use to reach the client, including Intel AMT, ASF, or DASH rather than a standard broadcast packet used in #1 and #2 above.
4. Software Delivery's "Power on computers if necessary."
This uses a combination of two things. It uses their own custom WOL method (we are still reverse-engineering this) and the methods in #3 above (AMT, ASF, DASH). It is configured in the Schedule settings of a Software Delivery Policy, and ships with the Software Delivery product.
5. Resource Manager's Power On
This is a Deployment add-in to the core product that uses ILO calls to wake the computer and thus is limited to systems that have ILO support. It is not free, since it ships with the Deployment product.
Feedback
