See all of the top support solutions for our most common issues here
~ Muhammad Adil
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.
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
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:
Sleep States for Wake On LAN (http://technet.microsoft.com/en-us/library/bb693821.aspx)
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 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.
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.
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.
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.
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.
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.
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.
Configuring Wake on LAN in ConfigMgr 2007
To configure a Software Update for Wake on LAN:
1. In the Configuration Manager console, navigate to System Center Configuration Manager / Site Database / Computer Management / Software Updates / Deployments.
2. Right-click the deployment you want to configure for Wake on LAN and then click Properties.
3. On the Schedule tab, select the option Enable Wake on LAN.
4. Click OK.
To configure a Software Distribution mandatory advertisement for Wake on LAN:
1. In the Configuration Manager console, navigate to System Center Configuration Manager / Site Database / Computer Management / Software Distribution / Advertisements.
2. Right-click the advertisement that supports the Software Distribution you want to enable for Wake on LAN and then click Properties.
To configure a Task Sequence mandatory advertisement for Wake on LAN:
2. Right-click the advertisement that supports the operating system deployment that you want to enable for Wake on LAN and then click Properties.
Configuring Wake on LAN in ConfigMgr 2012
To configure a software update for Wake on LAN:
1. In the Configuration Manager console, navigate to Software Library/ Software Updates/ Software Update Groups
2. Right-click on the Software Update Group and click on deploy
3. On the Deployment Settings- Type of Deployment Settings must be configured to “Required” and “Use Wake on-LAN to wake up clients for required deployments” should be checked.
Configuring an Application or a Package for Wake on LAN:
1. In the Configuration Manager console, navigate to Software Library/ Application Management/ Applications or Packages
2. Right-click on the Application or the Package and click on deploy
3. On the Deployment Settings- Purpose must be configured to “Required” and “Send Wake-up Packets” should be checked.
Configuring a Task Sequence for Wake on LAN:
1. In the Configuration Manager console, navigate to Software Library/ Operating Systems/ Task Sequences
2. Right-click on the Task Sequence and click on deploy
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.
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.
- 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.
Muhammad Adil | Senior Consult-Escalation Engineer | PRO Support Middle East & India
Get the latest System Center news on Facebook and Twitter:
System Center All Up: http://blogs.technet.com/b/systemcenter/ System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/ System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/ System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/ System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/ WSUS Support Team blog: http://blogs.technet.com/sus/ The AD RMS blog: http://blogs.technet.com/b/rmssupp/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
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.
Finally, ConfigMgr 2012 SP1 added wake-up-proxy which adds a peer-to-peer wake-up methodology overcoming most of the challenges and shortcomings of sending magic packets from the site server: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients
Great Job Adil Sir, this will really help us in WOL issues..
Thanks for the information.
One good blog and enough information of WOL..
Awesome Blog, WOL made easy now :)
Here at the National Security Agency we love Wake On Lan (WOL), if your computer is shut off, we just wake it up so we can spy on you!
Nice Blog. It helped me configuring WOL successfully!
i guess Adeel is trying to refer this.
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.
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.
Nice Blog Adeel
Very good post overall for people interested in configuring WOL.
Good work "Muhammad Adil | Senior Consult-Escalation Engineer | PRO Support Middle East & India"
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.
Thanx Bharat for clarifying things and Thanx to everyone else for their comments and appreciation.
Anytime Adeel Bhai
CHOETECH 10000mAh 5x USB Backup External Battery Pack Portable Power Pack Charger for
CHOETECH 5.0V 4.2-Amp (21 Walt) Dual USB Ports High-speed AC Wall Charger Designed for Apple