Configuration Manager – Wake on LAN, one stop shop


Wake on LAN is it a mystery? Is it a myth? Nope it really is not that hard and this guide helps you by putting everything in one nice spot.

 

WOL Requirements:

a. ConfigMgr

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.

 

b. Network

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.

 

c. Client

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.

 

d. 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.

 

WOL Facts:

a. 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.

b. 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.

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

 

Configuration – ConfigMgr:

The ConfigMgr side of the house is fairly straight forward with a few items to take into consideration, the steps and options are detailed below.

 

(1) Open the ConfigMgr 2012 Console

(2) Navigate to Administration \ Site Configuration \ Sites

(3) Select the site server you want to configure, right click and select “Properties”

(4) Click the “Wake On LAN” tab

(5) Check the box next to “Enable Wake On LAN for this site:”

* The first two options use AMT power on commands while the third option use only standard Wake On LAN commands.

 

There are two transmission methods for Wake On LAN:

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.

 

Configuration – Client Side:

 

(1) The Client side configuration, needs to be done via the BIOS which will need to be done via the manufacturer’s directions.

(2) The Network card on the client must support and be configured for Wake-up Packets, this must be verified via the hardware vendor

(3) To set the network card:

a. Open a Command Prompt with elevated rights

b. Run devmgmt.msc

c. Navigate to Device Manager \ Network Adapters

d. Right click the network adapter and go to Properties,

e. Click on the Advanced Tab, select Wake on Magic Packet, ensure it is set to Enabled (If not present in list card does not support)

f. Click on the Power Management Tab, ensure the following options are selected:

* Allow the computer to turn off this devices to save power

* Allow this device to wake the computer

* Only allow a magic packet to wake the computer

g. Click Ok on the Properties

 

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 – Important Step:

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 2012, Deployments must be configured as “Required” for Wake on LAN to work.

 

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.

 

Troubleshooting:

In ConfigMgr we have two logs on the site server to monitor Wake on LAN activity.

* Wolmgr.log basically shows us the status of the Wake on LAN manager component

* Wolcmgr.log which shows us the status of the Wake on LAN packets.

 

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.

 

Reference Links:

 

=====================================

Wake on LAN Proxy:

=====================================

Reference Link: https://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

 

=====================================

Identifying the WOL Port:

=====================================

  1. Download the ConfigMgr 2012 PowerShell Right Click Tools
  2. Download tools from http://psrightclicktools.codeplex.com/
  3. Install the Right Click Tools
  4. Download Wireshark from: https://www.wireshark.org/download.html
  5. Install Wireshark onto the system you wish to capture the network trace
  • Open Wireshark
  • In Wireshark, select Capture and then Options
  • In the Capture Options, select Capture on all interfaces
  • Set the Capture Files (save location)
  • Shut down any other applications that might cause network traffic to avoid their non-relevant activity from showing up in the network trace
  • On the Wireshark Capture Options, click Start to start capturing traffic
  • Once the packet capture has begun:

(PowerShell Right Click Tools – Port 12287 by Default):

      1. Locate the test machine in the ConfigMgr console
      2. Right click the machine and use the PowerShell Right Click tools to perform a Wake On LAN function
      3. Wait for the device to wake up, if it does not after 2 minutes stop

(ConfigMgr Deployment – Port 9 by Default):

      1. Deploy a package with Wake On LAN enabled to collection containing the test machine
      2. Wait for the device to wake up, if it does not after 2 minutes stop

 

  • Once you have completed these steps, then click the STOP button on the capture
  • Once the data has been captured, select File and then Save As from the menu, save the file with a relevant name
  • Filter the capture in Wireshark for WOL
  • Double click an entry to look at its properties, check the port being used in the successful communications

 

Notes:

      • ConfigMgr 2012 default port for Wake On LAN is Port 9
      • Commonly used ConfigMgr 2012 Wake On LAN Ports are 7, 9 and 12287
      • The PowerShell Right Click Tools default port for Wake On LAN is 12287

Recommendations:

      • Test with several machines in different subnets with port 12287 configured in ConfigMgr for Port
      • Test with several machines in different subnets with port 7 configured in ConfigMgr for Port

 

Disclaimer: The information on this site is provided “AS IS” with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Main System Center blog: http://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: http://blogs.technet.com/dpm/

Orchestrator Team blog: http://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: http://blogs.technet.com/momteam/

Service Manager Team blog: http://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Microsoft Intune: http://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: http://blogs.technet.com/sus/

RMS blog: http://blogs.technet.com/b/rms/

App-V Team blog: http://blogs.technet.com/appv/

MED-V Team blog: http://blogs.technet.com/medv/

Server App-V Team blog: http://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: http://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: http://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: http://blogs.technet.com/b/isablog/

Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: http://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Comments (0)

Skip to main content