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:
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 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.
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.
3. On the Schedule tab, select the option Enable Wake on LAN.
To configure a Task Sequence 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 operating system deployment that you want to enable for Wake on LAN and then click Properties.
3. On the Schedule tab, select the option Enable Wake on LAN.
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
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.
No comments :
Post a Comment
Please Write Your Comments Here....