Tuesday 4 December 2018

Major Wake on LAN improvement with SCCM 1810

This has been an eagerly awaited feature. It's been on Uservoice since May of last year and has now been released to production in SCCM 1810. You can now wake up clients from the Configuration Manager console, even if the client isn't on the same subnet as the site server. The site server uses the client notification channel to identify another client that's awake on the same remote subnet. The awake client then sends a wake on LAN request (magic packet). I must admit that I was a bit sceptical about this but I've now tested it in my lab and it just works - I was pleasantly surprised. 

Wake on LAN has been a difficult solution to implement with Configuration Manager for many years. It has worked perfectly on the local subnet but could be problematic for remote subnets.

Why is that?

Let's start but by discussing exactly what it is. Wake-on-LAN (sometimes abbreviated WoL) is the industry standard for waking computers up remotely from a very low power mode. WoL is usually configured through the network card’s firmware, so you don’t need specific software to enable it. Support for Wake-on-LAN is now pretty universal and you can expect that the functionality would be available on any computer purchased in the last ten years.

Wake-on-LAN-enabled computers wait for a “magic packet” to arrive that includes the network card’s MAC address in it. These magic packets are often sent by a management solution (e.g. ConfigMgr). The typical ports used for WoL magic packets are UDP 7 and 9. Magic packets are usually sent over the entirety of a network and contain the subnet information, network broadcast address, and the MAC address of the target computer’s network card.

WoL magic packets are not routable so configuring the solution for remote subnets has always been problematic. Microsoft previously developed the wake-up proxy to help with this situation but that solution also carried a health warning. In certain circumstances (i.e. when you're using port-security) wake-up proxy could lead to disruption and loss of service. Wake-up proxy caused the network switch to believe that a different network adapter was using the port than the one that was registered. This behaviour is known as a MAC flap and is unusual for standard network operation. Some network monitoring tools look for this behaviour and can assume that something is wrong. Consequently, these monitoring tools can generate alerts or shut down ports when you use wake-up proxy. It was recommended not to use wake-up proxy if the network monitoring tools and services did not allow MAC flaps.

With this new solution in 1810 the site server uses the client notification channel to identify another client that's awake on the same remote subnet. It's all pretty straightforward to configure so let's have a look. Remember this solution allows you to implement a remote WoL solution without having to configure any networking.

SCCM side:

This part hasn't changed from the original WoL configuration.
  • In the ConfigMgr console navigate to Administration > Site Configuration > Sites.
  • Select the site, right click and select Properties.
  • Click the Wake on LAN tab

  • Check the box next to "Enable Wake On LAN for this site:"
  • Select a WoL transmission method
As the name suggests, subnet directed broadcasts send the packet to all computers on the remote subnet and is the most reliable transmission method. Unicast broadcasts send the packet only to the targeted computer. 

  • Click on Advanced to see the WoL transmission options. To make the solution more reliable you may choose to increase the number of retries.
  • Select the Ports tab of the site properties. The default WoL port in ConfigMgr is 9. For security reasons Microsoft recommends that you change this to a more obscure port (I've left it at 9 for now).
  • Save the configuration
Log files

You will notice that two new log files are created on the site server. There are no client-side log files for WOL.

  • WolCmgr.log: Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent, and the number of wake-up packets retried.
  • Wolmgr.log: Contains information about wake-up procedures, such as when to wake up deployments or deployments that are configured for WOL.
Client side configuration

This involves configuration of the NIC properties. Right click on your network card and choose Configure, then click on the Advanced tab.


Scroll down in the list to find Wake on Magic Packet. Change the value to Enabled. The other “Wake on” settings are not required.



Click the Power Management tab, and make sure the "Allow this device to wake the computer” and “Only allow a magic packet to wake the computer” boxes are enabled.

You need to ensure that these options are set for all the computers you will need to wake up. That could be a pain to do manually. Terence has a good blog post on creating a ConfigMgr CI for this.

Testing

Now let's have a look at the new functionality. What do you need?


This is the "remote subnet" of my lab. I have two laptops with the NICs configured for WoL and the ConfigMgr client installed.
  • Client 1 is turned off
  • Client 2 is turned on with a WoL monitor running. Client 2 will receive the magic packet and will turn client 1 on
ConfigMgr cannot track the progress of wake-up packets after they are sent, but you can use any network monitoring tool to verify whether wake-up packets successfully traverse your network infrastructure and reach the computers' network segment. I've used Wake on Lan Monitor for testing. Download it from here. Run it on a machine on the same subnet as the machine you want to wake up to test if the Magic packet signal is reaching that subnet.




Right click on the computer you want to wake up. Select the Client Notification channel. See the new Wake up option. (The same action is available on a specific collection. The site tries to wake up any client in that collection that's asleep.)



ConfigMgr is pretty smart here and will know if there is no other client computer awake on the remote subnet.


I'm in luck. I have a computer that is already awake on the remote subnet. Remember I didn't configure any kind of proxy computer. I merely ensured that the NICs were configured correctly for WoL.



Success. The magic packet is detected almost immediately on client 2 (see the text in the WoL monitor) and immediately wakes up client1.



The WoL monitor shows details of the magic packet. See how I configured the port to match the ConfigMgr WoL port.

Remember that your required deployments continue to work as normal (applications, task sequences and software updates).

I was amazed at how well this works (with minimal effort). I'll now implement this at my customer sites.


Limitations

There are some limitations to the solution
  • At least one client in the target subnet must be awake. 
  • IPv6 is not supported (I presume this means it won't work over Direct Access).
  • 802.1x network authentication is not supported.

Until next time......


7 comments:

  1. Great article for a much anticipated feature.

    Could you elaborate the 802.1x is not supported limitation. If we use 802.1x and want to user WoL we can easily wake computers using 3rd part tools such as http://www.nirsoft.net/utils/wake_on_lan.html, SCCM can't do that? Do you know why?

    ReplyDelete
    Replies
    1. It's not supported because of that fact that, by default, devices are quarantined when powered off. It may be as simple as configuring the switch to allow unidirectional access into the quarantined, sleeping ports but Microsoft have not tested yet. Perhaps you could try it.

      I found this in a Cisco doc

      https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken_guide/dot1x.html

      Using 802.1X Authentication with Wake-on-LAN

      With Release 12.2(33)SXH and later releases, the 802.1X authentication with wake-on-LAN (WoL) feature allows dormant PCs to be powered when the switch receives a specific Ethernet frame, known as the magic packet. You can use this feature in environments where administrators need to connect to systems that have been powered down.
      When a host that uses WoL is attached through an 802.1X port and the host powers off, the 802.1X port becomes unauthorized. The port can only receive and send EAPOL packets, and WoL magic packets cannot reach the host. When the PC is powered off, it is not authorized, and the switch port is not opened.
      When the switch uses 802.1X authentication with WoL, the switch forwards traffic to unauthorized 802.1X ports, including magic packets. While the port is unauthorized, the switch continues to block ingress traffic other than EAPOL packets. The host can receive packets but cannot send packets to other devices in the network.

      When you configure a port as unidirectional by using the dot1x control-direction in interface configuration command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host.
      When you configure a port as bidirectional by using the dot1x control-direction both interface configuration command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.

      Note If PortFast is not enabled on the port, the port is forced to the bidirectional state.

      Delete
  2. Hi Gerry!

    With "Remember that your required deployments continue to work as normal", are you referring to the option to wake the device when the deployment deadline arrives? Because I wanted to ask: do we know if deployments will also use this new WoL method? I don't see why it wouldn't, but then again, that's up to how the product team decides to implement :)

    Do you have any insights on this? I'd appreciate it!

    Take care

    ReplyDelete
    Replies
    1. I'm pretty sure that this functionality has not changed. The new process only refers to the in-console Wake up option.

      Delete
  3. Does WoL in this method care whether are not the MAC is in the ARPchache?

    ReplyDelete
  4. Hi Gerry, thank you for that informatione. Regarding to Merlins question, you replied on it on Dec. 6th. Do you have newer information about it? Will be the "old" or "new" WoL mechanism be used when a deployment deadline is reached? Thanks in advance! Tom

    ReplyDelete
  5. Hi Gerry, great blog by the way, used to use years ago and always found it helpful.

    Quick question, I am trying to wake up some windows 10 clients using Wake Up but get the following error message

    Failed to initiate client side operation

    ConfigMgr Error Object:
    instance of SMS_ExtendedStatus
    {
    Description = "User \"WSHA\\JOHDAV\" does not have permission to wakeup ResourceID =16778346";
    ErrorCode = 1112017920;
    File = "..\\sspsleepserver.cpp";
    Line = 292;
    Operation = "ExecMethod";
    ParameterInfo = "SMS_SleepServer";
    ProviderName = "WinMgmt";
    StatusCode = 2147749889;
    };

    -------------------------------
    Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException
    You do not have security rights to perform this operation.


    Stack Trace:
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters)
    at Microsoft.ConfigurationManagement.AdminConsole.ClientOperation.Utilities.WakeUpClientNowOnMembers(Object sender, ScopeNode scopeNode, ActionDescription action, IResultObject selectedObject, PropertyDataUpdated dataUpdatedDelegate, Status Status)

    -------------------------------

    System.Management.ManagementException
    Generic failure


    Stack Trace:
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters)
    at Microsoft.ConfigurationManagement.AdminConsole.ClientOperation.Utilities.WakeUpClientNowOnMembers(Object sender, ScopeNode scopeNode, ActionDescription action, IResultObject selectedObject, PropertyDataUpdated dataUpdatedDelegate, Status Status)

    -------------------------------

    followed by 'There are no online machines to wake up the selected .....'

    Everything is configured server side and client - set to Uniflow for WOL, any ideas in your vast experience?

    Thanks

    John

    ReplyDelete