A complete guide to Wake On LAN for ConfigMgr 2007 and ConfigMgr 2012

Hi Folks, hope you doing well! Sometime back I had the opportunity to give a presentation on Wake on LAN (WOL) to our ConfigMgr PRO team so I thought I would share this information here in an effort to help you configure and troubleshoot Wake on LAN as well. This article consists of almost all of information you should need regarding planning, configuring and troubleshooting Wake on LAN (WOL) in both System Center Configuration Manager 2007 (ConfigMgr 2007) as well as System Center 2012 Configuration Manager (ConfigMgr 2012). My intention is to provide a single document that covers each and every point regarding

Wake on LAN and so that there isn’t a need a rely on multiple resources when trying to implement this in your environment.

What’s covered

1. What Wake on LAN is and how it works

2. The requirements for Wake on LAN

3. Wake On LAN in a multiple site hierarchy

4. General configuration

5. Activating Wake on LAN

6. Monitoring

7. Troubleshooting

8. Limitations

What Wake on LAN is and how it works

So what is Wake on LAN? Wake on LAN is essentially a network request or a network message to turn on a computer when it is in hibernate, sleep mode or turned off.

ConfigMgr supports the sleep states documented in the TechNet article here:

However, it also depends upon the architecture of the computer. It is a technology developed by Intel and IBM and is integrated into Microsoft Configuration Manager.

Wake on LAN is implemented in an environment using a special data packet known as Magic Packet. A Magic Packet consists of 6 bytes of all 255 (FF FF FF FF FF FF), followed by sixteen repetitions of the target computer's MAC address. Below is an example of how a magic packet frame looks like captured using a third party network sniffer tool:

For a machine to wake up, it can be in a shutdown, sleep or any other supported state, but it must also be connected to power source. The Magic packet is sent to the computer where the network card then signals the motherboard and the power supply to turn on the machine, similar to turning it on using a power button.

The requirements for Wake on LAN

The requirements can be divided into four categories and we’ll discuss each of them in brief:

1. Requirements for the ConfigMgr server

2. Requirements for the network

3. Requirements for the client

4. Hardware Inventory

The requirements for the ConfigMgr server are that the server must be up and running, the Management Point needs to be working properly, Wake on LAN must be enabled and the port being used must not be blocked on the firewall.

The requirements for the network are that switches and routers must be configured to allow the broadcast network packets if the chosen method is a subnet directed broadcast, and they should be allowed to forward the UDP packets if the chosen method is Unicast. Apart from that, the port being used must be opened on the router and the switch.

The requirements for the client are that the communication between the client and the management point should be healthy (e.g. the client should be able to download the policy from the Management point, etc.), Wake on LAN must be enabled in the BIOS and the network card must support Wake on LAN and have the feature enabled.

Apart these three requirements there is another very important dependency and that is Hardware Inventory. The Hardware Inventory information sent by the client includes the IP address, MAC address and subnet address. The Hardware Inventory information sent by the client (consisting of the MAC address and the subnet address in case of subnet directed broadcast, and the IP address and MAC address in the case of unicast) must be the actual MAC address and IP or subnet address on the client.

Wake On LAN in a multiple site hierarchy

If you wish to implement Wake On LAN in a multiple site hierarchy then you must be aware of following three considerations:

1. Wake-up packet transmissions are sent only from primary site servers. You cannot configure secondary site servers or other computers acting as proxies to send wake-up packets.

2. If you are enabling Wake On LAN on a child site, deployments and advertisements that are inherited from a parent site will include the Enable Wake On LAN configuration.

3. If the child site is not enabled for Wake On LAN, client computers in that site will not be sent wake-up packets.

General Configuration

Server configuration

Now that we’ve covered some of the basics, let’s go through a simple step-by-step configuration of Wake on LAN.

To enable Wake on LAN in ConfigMgr 2007 or ConfigMgr 2012, go to the site properties –> Wake On LAN and put a check mark next to “Enable Wake on LAN for this site” as shown in the screenshot below.

Choose the first or second option if you want to wake machines using AMT. Choose the first or the third option if you want to wake up the machine using Wake on LAN.

There are two transmission methods for WOL magic packets:

Subnet Directed Broadcast: In this method of transmission, the subnet address and the MAC address is retrieved from Hardware Inventory and wake-up packets are targeted to the subnet where they are broadcast to all the machines within that subnet. This method will fail if the machine changed its subnet and the ConfigMgr server has not yet received the updated Hardware Inventory with the information of its latest subnet. However, it should not fail if the machine has changed its IP address because the wake-up packets hit the subnet address rather than the IP address and should still reach the client. By default, subnet broadcasting is disabled on routers and switches, therefore it is important to ensure that is enabled if this is the method you choose. Also keep in mind that subnet-directed broadcasts are not supported with IPv6 addresses. For security reasons and to prevent smurf attacks, Microsoft highly recommends that you use a non-default port with this method of transmission.

Unicast: With this method of transmission, the IP address and the MAC address is retrieved from Hardware Inventory and wake-up packets are targeted directly to the IP address on the subnet. If the target machine has changed its IP address and Hardware Inventory has yet to update, the wake-up packet will reach the destination IP but will fail because the MAC address is different. Be sure to configure switches to forward UDP packets, and verify with your hardware vendor that older network cards support this method of transmission. In order for this method to be successful, entries for the client machines should be in the ARP cache of the router or the site server. More details on this are mentioned in the last section covering troubleshooting.

Which method should I use?

Both transmission methods have their pros and cons and it depends on your environment as to which method you should opt to use.

The advantage of subnet broadcasting is that the success rate is very high if the target machines frequently change their IP addresses. For this reason it is preferred. This is the original method of sending wake-up packets so it works with almost all sleep states. The disadvantage is that it is less secure, it consumes more network bandwidth, it requires reconfiguration of routers and it does not supports IPv6 addresses.

The advantage of unicast is that it’s more secure, it consumes less bandwidth, it supports both IPv4 and IPv6 addresses and requires no reconfiguration on the routers. The disadvantages of unicast are that it can be less successful, switches must be configured to forward UDP packets, and it may not wake-up machines from all sleep states.

After reading the advantages and disadvantages, if you have decided to use the Unicast method but the clients in your environment frequently change their IP addresses, it is recommended that you increase the DHCP lease time and shorten the Hardware Inventory schedule, however doing so can impact traffic on your network.

After enabling WOL and choosing the transmission method, Please choose the port number as shown in the screen shot below. By default, ConfigMgr uses UDP port 9, however you can use a custom UDP port of your choice. Whichever port you choose, please ensure that it’s not blocked on any firewall or intervening routers.

Client Configuration

After enabling and configuring Wake on LAN on server side, let’s proceed with configuring it on the client side.

On the ConfigMgr clients, ensure that Wake on LAN is enabled in the system BIOS. You may see different terminologies for WOL depending on the manufacturer (e.g. Remote Wake-up, Wake on LAN, Wake on PCI card etc.).

In addition to the BIOS, the network card must be configured to support Magic or wake-up packets. To do this, go to Start –> Run –> devmgmt.msc –> Device Manager –> Network Adapters, then right-click the network card and go to Properties. If your card has an advanced tab, ensure that WOL is enabled as per the screenshot below.

On the Power Management tab of the Network Card, please ensure that all three options shown below are checked to allow the NIC to wake the machine.

I can’t really tell you if there is a way in which you can enable Wake on LAN in the BIOS on multiple machines in your environment, however you can use Fix it tool 55017 from http://support.microsoft.com/kb/2740020 to enable power management on all of the machines in your environment. This Fix it tool can be deployed using a Group Policy, ConfigMgr, etc.

Network Configuration

As mentioned earlier, routers and switches must allow the port configured for Wake on LAN. In addition, intervening routers must allow the broadcast of wake-up packets if the chosen transmission method is subnet directed broadcast. Switches must be configured to forward UDP packets if the chosen transmission method is Unicast.

Hardware Inventory

After configuring the above settings, verify that the machine being tested has successfully reported its inventory. You can do this by right-clicking the machine in the console –> Start –> Resource Explorer –> Hardware –> Network Adapter configuration. In the screenshot below you can see that the client is sending its IP address, subnet address and MAC address. The Hardware Inventory information sent by the client consists of the MAC address and the subnet address in the case of subnet directed broadcast, and the IP address and MAC address in the case of unicast. These must be the same as the actual MAC address and IP or subnet address of the client. If there is mismatch between the inventory information and the details on the client, Wake on LAN will fail because the Magic Packet will fail to locate the machine. In such a case you may have to initiate the hardware inventory cycle on the client so that it sends fresh inventory information.

Activating Wake on LAN

After meeting the above requirements, your client should probably be capable of using WOL, however you must still activate Wake on LAN so your clients can turn on when they receive a Software Update, Package or Task Sequence.

Please note that in ConfigMgr 2007, Advertisements/Deployments should be configured as Mandatory and in ConfigMgr 2012, Deployments must be configured as “Required” for Wake on LAN to work.

3. On the Deployment Settings- Purpose must be configured to “Required” and “Send Wake-up Packets” should be checked.

Monitoring

In ConfigMgr we have two logs on the site server to monitor Wake on LAN activity: Wolmgr.log and Wolcmgr.log. Wolmgr.log basically shows us the status of the Wake on LAN manager component but it’s the Wolcmgr.log which shows us the status of the Wake on LAN packets.

If the wake-up packets are being sent out, we get STATMSG=6504 in wolcmgr.log as per the screenshot below.

Once the sending of the packets is completed we receive STATMSG=6505 in wolcmgr.log.

Below is a table of Message ID’s with the description you will find in Wolcmgr.log. These ID’s will assist you in understanding the status of wake-up packets in the event of a success or a failure.

In addition to the above logs, you can also use a Network Monitor trace or any third party WOL sniffer tool (e.g. http://profshutdown.com/download.aspx) to verify if packets are being sent out.

Troubleshooting

Below are some tips for you that I have learned from my experience with WOL. However, before we begin to troubleshoot Wake on LAN issues, we should always narrow down where exactly the problem is. We need to determine if the problem is at the ConfigMgr server, on the Network or at the client end.

First of all, be sure that you read through each section above to make sure you have the basics covered. And when testing, always have at least two or more machines to test with instead of just one.

For specific troubleshooting I’ll take a shortcut here to save some time.

– If you are unable to wake a machine using ConfigMgr WOL, however your are able to wake it using a 3rd party Wake On LAN utility, most likely the machine is capable of WOL and the issue lies either in the Hardware Inventory, on the server side or in the network.

– If you are able to wake a machine on the same subnet as the Site server, however it’s not waking on a different subnet then most likely the issue is with the switch or the router.

– Verify that problematic machines are communicating with the Management point and are able to download policies. (e.g. check Ccmexec.log, ClientIDManagerstartup.log, PolicyAgent.log etc.).

– Ensure that the port you specified for Wake on LAN is not blocked at the firewall or on any intervening device on the network. You might also try an alternate port for testing purposes.

– Check the binding order of the network cards if there are more than one on the ConfigMgr server or client. Also ensure that all network cards (or at least the one in use) are configured to forward and receive Wake-up Packets.

– If you are using the subnet directed broadcast transmission method, ensure that Broadcast is enabled on intervening routers and switches.

– If you are using Unicast, ensure that switches and routers are configured to forward UDP packets.

– I have come across a specific scenario several times where machines do not wake-up when using Unicast because routers are unable to resolve the IP address to MAC address since the entry of the machine does not exist in the ARP Table on the router. ARP is a mapping of MAC and IP addresses, and by running the command Arp –a on the Router/Site server we can verify if the entry of the machine exists in the ARP cache of the Router/Site Server. To verify is the issue is with ARP cache you can manually add the entry of a machine to the ARP cache of the ConfigMgr site server by running the command arp –s <ip_address> <mac_address> (e.g. arp -s 192.168.x.xxx 00-2x-5x-C1-xx-xx) on the ConfigMgr site server. This will override the ARP cache of the router. To fix this issue for several machines you might have to increase the ARP Cache Stale Timeout period and ARP Cache Update Timeout period. The default time out period for most Routers and Switches is 240 seconds.

– If you have enabled the Time Zone Hardware Inventory class you may come across an issue where a machine wakes-up in a different time zone. In such a case please ensure that the time zone in the Hardware Inventory and the actual time zone of the machine is the same.

Limitations

– Using ConfigMgr Wake On LAN, you will not be able to wake-up machines which are on the Internet.

– You will not be able to wake-up Bare Metal machines.

– Wake On LAN transmissions are always sent at the scheduled time, ignoring any maintenance windows that might be in effect on a client computer.

That’s it for Wake on LAN. Thanks for going through this article and kindly drop me a comment if I forgot to add something.

It’s worth noting that IP Address and MAC Address are also collected by Heartbeat discovery and thus can be updated more frequently than or outside of the HW inventory interval.

Also, this statement is inaccurate when using subnet-directed broadcasts: ” If there is mismatch between the inventory information and the details on the client, Wake on LAN will fail because the Magic Packet will fail to locate the machine.” If the subnet address has not changed, than subnet-directed can still work, that’s the whole point of broadcasting to the entire subnet.

It’s also worth pointing out the both ARP table cache timeouts on layer 3 devices as well as CAM table cache timeouts on layer 2 devices will prevent the network infrastructure from delivering the magic packet when Unicast WoL is in use — another reason that subnet-directed broadcasts generally work better if allowed on the network.

Subnet-directed broadcasts are sometimes not allowed on networks though because they have been used maliciously in the past in DoS attacks. This can be mitigated by restricting the source of the broadcast though.

Computers Do Not Wake Up Because the Client Has Not Completed a Hardware Inventory Cycle
The wake-up packets sent by the site server are constructed using the MAC address of the target computer, using hardware inventory information previously collected. If hardware inventory is not enabled for the site or if the target computer is a new Configuration Manager client that has not yet sent its inventory information back to the site, the site server cannot construct the wake-up packets.

Computers Do Not Wake Up Because They Have Changed Their IP Address Since the Last Hardware Inventory Cycle
When the site server uses uni cast as the wake-up transmission method, it sends the wake-up packet to the target computer’s last known IP address (from hardware inventory). If the target computer no longer has the same IP address, it will not receive the wake-up packets.

When the site server uses subnet-directed broadcast as the wake-up transmission method, it sends the wake-up packet to the target computer’s last known IP subnet address (from hardware inventory). If the target computer no longer has the same subnet address (for example, it is a client that frequently roams in the Configuration Manager hierarchy), it will not receive the wake-up packets.

Solution
Increasing the DHCP lease time and configuring the hardware inventory schedule to run more frequently can help to reduce the likelihood of sending wake-up packets to out-of-date addresses.
Additionally, if computers frequently change IP addresses but keep the same subnet address, selecting subnet-directed broadcast rather than unicast as the transmission method will prove more effective in waking up computers.

Thanks for comment Jason. You have quoted only a specific sentence of what I have mentioned. I mentioned "The Hardware Inventory information sent by the client consists of the MAC address and the subnet address in the case of subnet directed broadcast,
and the IP address and MAC address in the case of unicast. These must be the same as the actual MAC address and IP or subnet address of the client. If there is mismatch between the inventory information and the details on the client, Wake on LAN will fail
because the Magic Packet will fail to locate the machine." What I have mentioned is absolutely correct bcoz magic packet will fail to locate a machine if subnet add. and MAC add. incase of subnet directed broadcast and MAC and IP add incase of unicast present
on the machine do not match the hardware inventory. Under General configuration -server configuration -subnet directed broadcast I have mentioned in depth of all details regarding routers, smurf attack etc. which you just pointed. Information related to ARP
I have covered in Troubleshooting section. Bharat has already given a very good clarification however if u still feel there is anything inappropriate please let me know and I’ll be glad to clarify.

4 years ago

Muhammad Adil

Thanx Bharat for clarifying things and Thanx to everyone else for their comments and appreciation.

Hi
Thanks for the document.
I am trying to implement WOL in our environment.
We have more than 3000 dell desktops and SCCM 2012 in our network
At the moment if the machine is in sleep mode /switch of mode we can switch on the pc/collection using WAKE ON LAN.Now we create some software package , with “Required” and “Send Wake-up Packets” checked in the deployment option.
We create a collection of 3 machines(machines are switched off condition) and advertise the above package over the collection .But still that machines are OFF condition .It’s not waking up & not installing the software’s also. Then I tried Wake up the collection
using Wake On Lan in right click tool ,its wake up and install the application .
Can You please advise me why it is not working since I enable “Required” and “Send Wake-up Packets” checked in the deployment option.
Sunilsunilmon@gmail.com

3 years ago

Sunil

Hi
Thanks for the document.
I am planning to implement WOL in our environment.
We have more than 3000 dell desktops and SCCM 2012 in our network
At the moment if the machine is in sleep mode /switch of mode we can switch on the pc/collection using WAKE ON LAN.Now we create some software package , with “Required” and “Send Wake-up Packets” checked in the deployment option.
We create a collection of 3 machines(machines are switched off condition) and advertise the above package over the collection .But still that machines are OFF condition .It’s not waking up & not installing the software’s also. Then I tried Wake up the collection
using Wake On Lan in right click tool ,its wake up and install the application .
Can You please advise me why it is not working since I enable “Required” and “Send Wake-up Packets” checked in the deployment option.
Sunilsunilmon@gmail.com

3 years ago

Anonymous

If you’re trying to get the Wake On LAN Proxy feature of ConfigMgr 2012 SP1+ working, there’s a lot of

3 years ago

Tuan

Clarification question. When you enable wake-on-LAN for deployment, does the server send the magic package to the clients at "software available time", or at the "installation deadline" time? Thanks.

3 years ago

vijay

Even though this thread is more than a year old, I would like to request Mohammed Adil for a similar guide for Wireless Wake on Lan. WoWLAN has not attracted much attention from professionals and a similar guide from beginning to end would be of much use
and appreciated

cheers

Vijay

2 years ago

David

Thanks for this informative article. I had some troubles with Win 10. For example, after I upgraded it from win 8, my Wake-on-LAN does not work. I tried many things and finally I solved the problem.
Here you can find how to configure Wake-on-LAN on Windows 10.

I have a few hundred systems that do not install the ConfigMgr Wake-up Proxy service and there doesn’t appear to be any log file associated with the install of the service. Their common factor is that the OS is Win7 Embedded. Anyone know if maybe that isn’t supported? All other systems on various other OS are working fine.

2 years ago

Ariel Silverman

Hi Adil,

Can you please provide details on how does ConfigMgr handles balancing the load of wake on packets for large collections?

For example, if my collection of systems contains 1000 systems, are all wol packets sent sequentially 3 minutes before the actual deployment of the task sequence?