ConfigMgr 2007: Implementing Wake-on-LAN (WoL)

Article
03/04/2008

We get quite a few questions about enabling Wake-on-LAN (WoL) so I thought I'd post this document that was created by one of our Microsoft Consultants. It's a good overview of what WoL is and how to implement it so hopefully if this is something you're heading towards this will get you started in the right direction.

======

Wake-on-LAN (WoL) allows properly configured (BIOS, Operating System, Network Interface Card) machines to resume operation from various sleep modes in response to a network request. The network request comes in the form of a magic packet which is a special formatted network packet. Sleep refers to the low power states of Windows XP and Vista: Standby (S3), Hibernate (S4), and hybrid sleep. Hybrid sleep is a feature of Windows Vista that combines the features of S3 and S4; when entering sleep a hibernate file is saved to the hard disk but the computer resumes from memory unless power is lost. This can create problems if systems like Configuration Manager need to distribute software to a collection of hardware devices. An example would be a Security Patch that needs to be implemented as quickly as possible for a set of vulnerable machines. By combining all the pieces to create a WoL ready infrastructure, you'll end up with an environment that allows networked PCs to be both responsive 24x7 and efficient from a power consumption perspective.

This document assumes that the following are in place, working and configured properly:

Active Directory
Name Resolution: DNS and WINS
SCCM Site Systems
SCCM Infrastructure (Hierarchy)
SCCM 2007 Advanced Client installed
All machines have a WoL compliant NIC and BIOS
A properly configured network infrastructure

Infrastructure Subsystems

Server Side

Of the three subsystems, the Configuration Manager 2007 settings are simplest to complete. It involves opening the site properties of the Configuration Manager primary site and then on the “Wake on LAN” tab, selecting “Enable Wake on LAN for this site”. This configuration step can be accomplished independently of the other two subsystems. This will result in the Configuration Manager primary site server being ready to support the deployment of WoL Magic Packets via the Software Distribution (SWD) feature using Collections.

After the site is WoL enabled the transmission method needs to be set. We have a choice of either a “Subnet-directed broadcast” or a “Unicast” packet to transmit the magic packet.

If Subnet-directed broadcast is selected the magic packets will be sent to all computers on a subnet. Selecting Unicast sends individual magic packets to a single computer. For reasons discussed later, the recommended setting is Subnet-directed broadcast .

Client Side

SDC images: A Standard Desktop Configuration image for Windows XP and/or Windows Vista should be configured with all the proper hardware drivers. A device driver or software driver is a computer program allowing higher-level computer programs within the Operating System (OS) to interact with a computer’s hardware device. For this WoL scenario, we are interested in the Network Interface Card (NIC).

Client side settings need to be set for all Configuration Manager Advanced Client machines in the environment. Below is a sample of what needs to be set. Changes must be made on both the “Advanced” and “Power Management” tabs of the NIC properties.

The “Advanced” tab nomenclature will vary among Network Interface Card vendors. In the example below the setting is called “Wake Up Capabilities” with 4 possible values. Other NICs could call this setting “Wake on LAN” and the value names could be different as well so consult your network card vendor if you have any questions about this aspect of the configuration. The “Power Management” tab is more consistent with the following items that need to be set.

Allow the computer to turn off this device to save power
Allow this device to bring the computer out of standby
Only allow management stations to bring the computer out of standby.

A sample script, Client Side Configuration Script (see below), has been provided to automate the tasks and can be distributed via the Software Distribution (SWD) feature in Configuration Manager and also built into the SDC imaging process.

This script has had limited testing and requires testing in your environment to be successful with your network cards. Microsoft makes no warranties with regards to the suitability of this script nor is it supported in any way.

In the case of BIOS settings, a physical desktop visit may be required if you're unsure as to the current configuration of the hardware.

Network Side

Certain configuration changes may be necessary in your environment depending on the current configuration:

Enable Subnet Directed Broadcasts to travel via the router to pass the Magic Packet.
Assign security on the routers so only the Configuration Manager site server is allowed to send the subnet directed broadcasts.
Verify the configuration works with 802.1x authentication on the switches.

How WoL Works

Subnet Directed Broadcast

The screen shot below shows a subnet directed broadcast as viewed using Network Monitor. It is a UDP packet sent over port 9 from the Configuration Manager site server (192.168.1.30). The broadcast can be identified by the 255 in the 4^th octet of the destination address (192.168.1.255). The packet travels the network and is processed by each client on the subnet for which it was directed to. In this example the subnet is 192.168.1.0 with 254 possible hosts.

UniCast

The screen shot below shows a unicast packet as viewed using Network Monitor. It is a UDP packet sent over port 9 from the Configuration Manager site server (192.168.1.30). It appears to be the same as the subnet-directed broadcast, but with one major exception. The unicast packet can be seen in the 4^th octet of the destination address (192.168.1.207). The packet travels the network and is processed by only the single client on the subnet for which it was directed to. In this example the subnet is 192.168.1.0 for client IP address of .207

The difference between the transmission methods is that the unicast packets are easily passed by routers and the subnet directed broadcast packets are not. The reason for this is the routers are normally configured to reject the broadcasts for security reasons. Rules will need to be applied to the routers and switches (VLANs) to pass through each broadcast zone (also known as a hop) from the source (Configuration Manager Site Server) to the destination subnet.

Magic Packet

The screen shot below shows a Magic Packet. This is the data inside the unicast or subnet directed broadcast data frame which is processed by the target computers NIC. The WoL compatible NIC in a sleeping computer is constantly processing all data frames searching for this magic sequence of bytes. Each card has its own unique WoL packet that consists of a header of 6 x 0xff (FF-FF-FF-FF-FF-FF) followed by the physical address of the card (48-bit MAC address) repeated 16 times. By matching to its own MAC address, the client is able to determine if it is the magic packet was targeted to the machine for wake up.

Note that WoL magic packets are delivered to the computer’s IP address that is stored in the Configuration Manager database. There should not be any issues with desktop class devices being woken up since their IP address should rarely change, but it is possible for a laptop to be connected in a new network location in-between SCCM hardware inventory cycles. This would result in Configuration Manager sending the magic packet to the wrong subnet.

Unicast

In some environments, magic packets may not be successfully delivered using the unicast method in a routed or non-routed environment. What can happen is that when the local ARP cache on the Configuration Manager server or on the router doesn’t contain an entry for a WoL target, the Configuration Manager server or the router performs and ARP request. Since the target device is in an inactive state (sleep, standby, hibernate or powered off), the ARP reply never comes and the WoL packet is never sent. This is why as a general rule, a Subnet Directed Broadcast is recommended

Subnet-Directed Broadcast

When using subnet-directed broadcast as the transmission method for sending wake up packets to a computer within a Configuration Manager 2007 site, the site server retrieves the MAC address and IP subnet of the target computer from hardware inventory which is stored in the SQL database. The subnet directed broadcast is sent to the computer's subnet, and the magic packet is then broadcast to all computers on that subnet. Because this is a broadcast, all computers on the subnet will process the packet but only the computer that has the MAC address specified within the magic packet will respond.

This transmission method uses the subnet address rather than the individual clients IP address. It will succeed, if the target computer has changed IP addresses but remained in the same subnet. The use of subnet-directed broadcasts is the more traditional method of sending wake up packets, so this transmission method might be more compatible with a wider range of computer network adapters than transmitting wake up packets using unicast. For subnet directed broadcasts to be successful, all intervening routers must be configured to forward subnet-directed broadcasts.

Security

Subnet directed broadcast security concerns

This broadcast traffic type can be used to specify hosts on a network as a method for a denial of service (DOS) attack. For example, by blocking specific source addresses, you prevent malicious echo requests from causing cascading ping floods.

Directed broadcasts are used in the standard "Smurf" DOS attack, and can also be used in associated attacks as well. In a "Smurf" DOS attack, ICMP echo requests are sent from an erroneous source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the inaccurate source. Transmitting a constant stream of ICMP echo requests can render the hosts on the subnet useless.

Subnet directed broadcast security mitigation

Directed broadcasts are occasionally used for valid purposes, such as in this WoL solution. In order to lower the vulnerability exposure of a DOS attack the routers need to have security access controls assigned. These access controls would only allow subnet directed broadcasts that originated from the address of the ConfigMgr 2007 site server. In the event of a security incident the site server can be isolated from the network. With the problem contained, remediation can be preformed.

Conclusion

After careful lab and limited production testing, it has been determined the subnet directed broadcast is the preferred transmission method for delivering the magic packet to the desktop to support WoL. The industry standardization of subnet directed broadcast and the acceptable security mitigation steps make this method a viable solution for most customers.

Additional Information

Client Side Configuration Script

The script below will to enable WoL for all wired Ethernet adapters. The script has had limited testing and will need additional testing across all desktop and laptop models before deploying in your environment.

NOTE: Microsoft makes no warranty about the suitability of the script or guidance for your environment, nor is this script officially supported by Microsoft in any way. The script is provided for demonstration purposes only.

_________________________________________________________________________________

Option Explicit

Dim colNetworkAdapters
Dim objNetworkAdapter

Dim strDevInstanceName
Dim strNetworkAdapterID

'Query for all of the Win32_NetworkAdapters that are wired Ethernet (AdapterTypeId=0 corresponds to Ethernet 802.3)
Set colNetworkAdapters = GetObject("WinMgmts:{impersonationLevel=impersonate}//./root/Cimv2")_
.ExecQuery("SELECT * FROM Win32_NetworkAdapter WHERE AdapterTypeId=0")

WScript.Echo "Enabling WoL for the following adapters:"

For Each objNetworkAdapter In colNetworkAdapters
WScript.Echo " " & objNetworkAdapter.Name & " [" & objNetworkAdapter.MACAddress & "]"

strNetworkAdapterID = UCase(objNetworkAdapter.PNPDeviceID)

            'Query for all of the MSPower_DeviceWakeEnable classes
            Dim colPowerWakeEnables
            Dim objPowerWakeEnable

            Set colPowerWakeEnables = GetObject("WinMgmts:{impersonationLevel=impersonate}//./root/wmi")_
            .ExecQuery("SELECT * FROM MSPower_DeviceWakeEnable")
            'Compare the PNP Device ID from the network adapter against the MSPower_DeviceEnabled instances
            For Each objPowerWakeEnable In colPowerWakeEnables
                        'We have to compare the leftmost part as MSPower_DeviceEnabled.InstanceName contains an instance suffix
                        strDevInstanceName = UCase(Left(objPowerWakeEnable.InstanceName, Len(strNetworkAdapterID)))
                        'Match found, enable WOL
                        If StrComp(strDevInstanceName, strNetworkAdapterID)=0 Then
                                    objPowerWakeEnable.Enable = True
                                    objPowerWakeEnable.Put_           'Required to write the value back to the object
                        End     If
            Next
            'Query for all of the MSNdis_DeviceWakeOnMagicPacketOnly classes
            Dim colMagicPacketOnlys
            Dim objMagicPacketOnly
            Set colMagicPacketOnlys = GetObject("WinMgmts:{impersonationLevel=impersonate}//./root/wmi")_
            .ExecQuery("SELECT * FROM MSNdis_DeviceWakeOnMagicPacketOnly")
            'Compare the PNP Device ID from the network adapter against the MSNdis_DeviceWakeOnMagicPacketOnly instances
            For Each objMagicPacketOnly In colMagicPacketOnlys
                        'We have to compare the leftmost part as MSNdis_DeviceWakeOnMagicPacketOnly.InstanceName contains an instance suffix
                        strDevInstanceName = UCase(Left(objMagicPacketOnly.InstanceName, Len(strNetworkAdapterID)))
                        'Match found, enable WOL for Magic Packets only
                        If StrComp(strDevInstanceName, strNetworkAdapterID)=0 Then
                                    objMagicPacketOnly.EnableWakeOnMagicPacketOnly = True 'Set to false if you wish to wake on magic packets AND wake patterns
                                    objMagicPacketOnly.Put_             'Required to write the value back to the object
                        End     If
            Next
Next

======

The information above was submitted by Jim Hamel (Microsoft Consulting Services) with contributions by Ed McGinn, Jeff Tondt, Georgeanna Wells and Susan Dyer.

Enjoy!

J.C. Hornbeck | Manageability Knowledge Engineer

Comments

Anonymous
January 01, 2003
I was able to get this to work remotely by not using psexec and instead replacing //./ with //computername/. Author please feel free to delete my previous two comments.
Anonymous
January 01, 2003
The team at The Manageability Team Blog have posted a very comprehensive article on how to setup Wake
Anonymous
January 01, 2003
J.C. put together a nice article describing all that is necessary to implement Wake-on-LAN in ConfigMgr
Anonymous
January 01, 2003
Disregard my previous comment, the script will work with both wscript.exe and cscript.exe. I am having trouble getting it to work remotely using psexec but it does work if I run it locally.
Anonymous
January 01, 2003
This script must be run with wscript.exe. If you use cscript.exe then you will get a wmi not supported error and the script will not work.
Anonymous
January 01, 2003
Hi and Thanks for such an informative article. My question is related to the script that has been provided to enable WOL for Network Adapters. When I ran this script on a test computer from command prompt, I get the following Error: Enabling WOL for the following Adapter: Packet Scheduler Miniport [MAC ADDRESS] C:Program FilesLANSCRIPTlanscript.vbs (27,13):0x8004100C Now when I checked this error, It gives me the defination " NOT SUPPORTED " SOURCE : WMI What is wrong with the script and how can it be fixed. Regards, NAveed
Anonymous
January 01, 2003
The script works by running it interactively, but when we tried to implement it using SCCM or running under the SYSTEM context in psexec, we got error code 0x8004100c. To get this to work we had to add the LoadDriver constant in the GetObject/ExecQuery WMI calls, i.e., instead of: {impersonationLevel=impersonate} we put in {impersonationLevel=impersonate, (LoadDriver)} and it works.
Anonymous
January 01, 2003
Late to comment here, but nonetheless... It is quite a relief to find this article. The explanation or SCCM trying to ARP a machine before sending a WOL packet (????) explains the erratic behavior I have seen (I have had my site settings set for unicast WOL packets, for the very reasons discussed in the article above.) Also- this is an EXCELLENTLY written script. In case someone from development sees this: I REALLY hope that this attempt to ARP before sending a unicast WOL packet is dropped in bugfix or SCCM update sometime if at all possible.
Anonymous
January 01, 2003
thank you
Anonymous
November 30, 2010
I know it is a bit late to the party here, but I just want make certain something is covered here for posterity or whatever. You can not remove the ARP function before sending a magic packet. In order to send a packet, it needs to be encapsulated in an ethernet frame. Ethernet, just like IP, requires a destination address for information to go to some location. ARP is what ties the destination's IP address, to the destination's ethernet address. The ARP cache is intended to expire. Only the newest most relevant mappings are in the table. The only way to bypass the need for the ARP table is to use the broadcast method. You can adjust the ARP cache timeout, if you feel a need.
Anonymous
January 25, 2011
Great script and excellent explanation.
Anonymous
April 14, 2011
Even with the script and SCCM, this will just take care of it from the windows side, don't you still need to change settings in the bios to enable wake on lan and enable booting from network? Thanks
Anonymous
September 07, 2011
Just want to clarify the ARP issue from a fundamental networking standpoint. A server or workstation should never have a dynamic/learned arp entry for something that is not on it's local subnet. In order for an IP packet to hit the wire in 99.9 percent of modern LAN's it must be encapsulated in an ethernet frame (as mentioned by ColoQ). The source MAC will be the sender, and the destination MAC will either be the actual destination host (if on the same subnet) or the MAC address of the router (default gateway) interface for that LAN segment. That is it as far as a workstation/server is concerned. If it is sending locally, make an ARP request (Who has x.x.x.x), use the mac address returned in the ARP request to encapsulate IP packet into ethernet frame and transmit. If not local, use the mac address of the gateway to encapsulate IP packet in ethernet frame and transmit. The router will receive the frame, drop the ethernet portion, examine the destination IP, look for a route to that network and hopefully forward. The only reason the configuration manager knows about the client mac address is because of the SCCM client and inventory process. The issue experienced is probably because the infrastructure switches (where the client is connected) arp / mac aging timers expire when the client is powered down or in some form of sleep mode. If any timers would have to be adjusted to make the unicast option work it would be there, but these timers are essential in having a dynamic functioning network and the increase in aging timer to ensure a workstation is still available after hours/days of sleep would most likely cause problems in the normal operations of the network.
Anonymous
November 04, 2011
@Terrance Thanks for the impersonate tip. Saved me a few hours Mike
Anonymous
January 31, 2012
Hi All, Bit late like a few others. I'm also getting this packet scheduler miniport instead of the actual adapter. Was a solution found? Thanks, John
Anonymous
March 13, 2012
This script seems to have a serious flaw (at least in my case with Intel NICs under WinXP). The 0x8004100C error (in my case) is caused by the code trying to reference an instance of the MSPower_DeviceWakeEnable class when there are no (zero) instances. Experimentation and use of wbemtest.exe shows that when "Wake on Settings" and "Enable PME" are manually set to disabled via the Advanced tag of the NIC properties from Device Manager, any instances of the MSPower_DeviceWakeEnable and MSNdis_DeviceWakeOnMagicPacketOnly classes are removed. I suspect for the script to work correctly, it needs to check if there are actually any instances for the MSPower_DeviceWakeEnable and MSNdis_DeviceWakeOnMagicPacketOnly classes, and if not, create a new instance, in the process setting the MSPower_DeviceWakeEnable.Enable property to enabled and the MSNdis_DeviceWakeOnMagicPacketOnly.EnableWakeOnMagicPacketOnly to True. Of course if there are existing instances the current code works fine. These modifications are, I'm afraid, beyond my WMI scripting skills. Adding {impersonationLevel=impersonate, (LoadDriver)} as suggested above, did not work for me either locally or remotely. Regards, Graham Rawolle
Anonymous
June 01, 2012
How to find WOL compatiable/non machines with the help of SQL Query
Anonymous
July 25, 2014
objPowerWakeEnable.Put_ reporting "ACCESS DENIED" on windows 8.1 pro

Share via