Four types of Wake-on-Lan (WoL) currently exist in System Center Configuration Manager (ConfigMgr/SCCM). Each operates differently and must be accounted for at the network level for them to work.
The Magic Packet
I won’t go into much detail on WoL in general other than to define what a magic packet is. If you need or want to know more about WoL in general, then the Wake-on-LAN Wikipedia article in a great place to start.
As the name implies, the magic packet is where the magic happens. In all WoL cases, the magic packet is a specially crafted frame at the data link layer containing the MAC address of the targeted system. The network delivers this frame to the targeted system, which, if configured to do so, wakes up and resumes operation.
The first two types of wake-up in ConfigMgr send magic packets based on required deployment deadline times to the systems in the collection targeted by the deployment. You set the option to send a WoL magic packet on the deployment. As noted, this is only applicable to required deployments. There is no built-in ad-hoc method to initiate these methods.
1. Subnet-Directed Broadcast
This is the first type of WoL in ConfigMgr and is the traditional WoL method. With this method, the primary site server sends a subnet-directed broadcast to the IP subnet where the targeted system was last known to be online. It’s important to know that in this case, it’s up to the network to deliver the magic packet to the subnet; ConfigMgr just initiates the process. Thus, the network must be configured to allow subnet-directed broadcasts. If it’s not, then there is not a thing that ConfigMgr can do about it.
Subnet-direct broadcast-based WoL is by far the simplest and most effective method in well-connected networks that allow subnet-directed broadcasts. Other network traffic has the potential to use subnet-directed broadcasts, including malicious distributed denial of service attacks (DDOS), however. For this reason, many networks have disabled subnet-directed broadcasts altogether.
2. Unicast
This is the second standard-type of WoL built into ConfigMgr. With unicast WoL, the ConfigMgr primary site server sends the magic packet directly to the targeted client using that client’s IP Address. The main limitation with unicast-based WoL is that for the network to deliver the magic packet (or any packet for that matter) to a targeted system, the network must know the targeted system’s MAC address. The router closest to the target system typically caches the MAC address in that router’s Address Resolution Protocol (ARP) cache. The ARP cache has a limited lifetime, though (15 minutes by default generally). Thus, if the site server sends a magic packet using unicast to a targeted system that has not been on the network in more than the timeout, the network does not know how to deliver the magic packet to the intended target system and drops it.
[su_note note_color=”#ffcb05″]A ConfigMgr site cannot use both unicast and subnet-directed broadcast WoL simultaneously; you must configure the site to use one or the other. [/su_note]
3. Wake-up Proxy
A somewhat recent addition to ConfigMgr is wake-up proxy. This WoL type uses peers to proxy unicast WoL magic packets sent from the primary site server. There is no direct way to invoke wake-up proxy; it supplements the unicast WoL method (there’s no reason to use wake-up proxy if subnet directed broadcasts work in the environment).
Peer systems, called managers, assume the MAC address of other systems on the same subnet that go to sleep, hibernate, or power-down. Because the MAC address is still alive and available on the subnet, the network can deliver the magic packet to the manager that assumed the MAC address. This side-steps the significant restriction with ARP cache timeouts, as noted for standard unicast WoL above. Managers then send a magic packet on the local subnet where the sleeping system can pick it up and subsequently wake up.
There are two notable problems with wake-up proxy, both are network-related (it’s always the network):
- Network switch ports that your endpoints connect to do not allow multiple MAC addresses.
- Network switches restrict or do not allow rapid or frequent MAC addresses movement from one network switch port to another. This is often called MAC-flapping.
In both cases, the network shuts down the port on the network switch. This, in turn, causes other peers on the network to assume the MAC addresses of systems on the switch ports that are shut down and a downward spiral of the network slowly shutting down ensues.
If you want to enable wake-up proxy, talk to your networking folks first.
Note that wake-up proxy isn’t specific to ConfigMgr or ConfigMgr initiated WoL magic packets. Managers send magic packets if they receive any traffic for the sleeping system that the sleeping system may have been listening for.
4. Client Notification
The final and newest WoL method in ConfigMgr uses client notification. If you are unfamiliar with client notification, then it’s past time to learn about it. See Fast Channel for System Management for detailed information. Unlike the first three methods, this method is unrelated to deployments, and you can only initiate it ad-hoc.
Similar to wake-up proxy, this method uses a peer on the local subnet of the targeted system. When you initiate wake-up using client notification, ConfigMgr chooses an online peer in the targeted system’s current subnet(( Clients send IP address information to ConfigMgr using heartbeat discovery, which is sent every seven days by default. I generally recommend changing this to at least daily in most environments. )). The site then sends a request to that peer using client notification, and the peer, in turn, broadcasts a WoL magic packet to the local subnet where the sleeping system can pick it up and subsequently wake up.
Client notification elegantly side-steps all of the problems with the other three wake-up types. Unfortunately, as noted, it is only available as an ad-hoc action currently (as of 1906).
Summary
WoL in ConfigMgr isn’t perfect but it can work well with proper planning and coordination with your network team. Also, keep in mind that you must enable WoL in the firmware of managed systems as ConfigMgr cannot do this for you since it is a hardware-specific configuration. ConfigMgr will, however, automatically enable WoL in the NIC driver.
For more details on WoL in ConfigMgr, see the following official documents:
- Plan how to wake up clients in System Center Configuration Manager
- How to configure Wake on LAN in System Center Configuration Manager