Troubleshooting Wake On LAN (WOL) in ConfigMgr

In my other blog about Wake On LAN (WOL): http://henkhoogendoorn.blogspot.com/2011/05/wake-on-lan-wol-functionality-in.html I explained which functionality becomes available in ConfigMgr 2007/2012. This can be used to schedule OS deployment, Software distribution and Patch management during non-working hours to wake-up devices. But what to do when it isn't working and you don't know what to do next? In this blog I will explain my best practices from the field, and how WOL will be functional (again).

Most of times using Unicast is the easiest one to configure. Then devices in the same subnet can be used for WOL functionality only. In the field however there are most of times different subnets for servers and clients. Then "Subnet-directed broadcasts" is the best way for configure WOL functionality. More about that in my other blog: "Wake On LAN (WOL) functionality in ConfigMgr".

First something about Site boundaries here. In ConfigMgr it's possible to create Site boundaries with IP-subnets, AD-sites and IP-address ranges. They all seems okay, but because ConfigMgr cannot handle supernetting, IP-address ranges is the only right choice here! A supernet is an Internet Protocol (IP) network that is formed from the combination of two or more networks (or subnets). WIKI page: http://en.wikipedia.org/wiki/Supernet

Because supernetting can be used in both IP-subnets and AD-sites, they are not the best choice for implementing Wake On LAN functionality. There's also a nice TechNet blog available about that: Known Issue: Supernets in Active Directory Sites Used as Site Boundaries: http://blogs.technet.com/b/configmgrteam/archive/2009/12/21/known-issue-supernets-in-active-directory-sites-used-as-site-boundaries.aspx

(after creating an IP-subnet, only the Subnet ID remains visible) 

(with IP-address ranges, the complete range remains visible) 

Now the best practices from the field, based on above suggestions: 

• Remove any existing Site Boundaries based on both IP-subnets and AD-sites (write down there IP-address ranges, but don't use them anymore)
• Create IP-address ranges based on formerly existing Site boundaries (only use complete ranges from 1-255 to get Wake On LAN working)
• In Site properties > select "Use wake-up packets only" and "Subnet-directed broadcasts" (Power on commands are used only with Out of Band Management)
• In Site properties > the UDP port can remains on port 9 (default), when there are issues with that use port 12287
• Create a new advertisement now, and set an mandatory assignment on that (otherwise there is no WOL functionality possible)

After this WOL functionality must be available on "Subnet-directed broadcasts". Remember that WOL functionality is only available on OS deployment, Software distribution and Patch management in combination with an mandatory assignment. Good luck!

Wake On LAN (WOL) functionality in ConfigMgr

In ConfigMgr 2007/2012 Wake On LAN (WOL) functionality is available. This can be used to schedule OS deployment, Software distribution and Patch management during non-working hours to wake-up devices. In ConfigMgr there are a few checkboxes which must be set to make it functional. In this blog I will describe which settings there are, and what else is needed on routers/switches. 

First choose properties on the Site Server for Wake On LAN properties:

When enable Wake On LAN for this site, only wake-up packets can be selected. For having power on commands also, the Out of Band service point role must also be added. In ConfigMgr 2007 this can be done without any difficulty (but an AMT provisioning certificate is still needed). In ConfigMgr 2012 an AMT provisioning certificate is directly needed. When using WOL functionality instead of Out of Band, no configuration is needed on this role.

Out of band management in ConfigMgr 2007 SP1 and later provides a convenient way to control computers that have the Intel vPro chip set and a version of Intel Active Management Technology (Intel AMT) firmware that is supported by Configuration Manager. Have a look at http://technet.microsoft.com/en-us/library/cc161828.aspx for all functionality, and differences with WOL.

When choosing advanced, multiple values can be set. I leave them most of times on default values. There is also the choice between Subnet-directed broadcast and Unicast, which is selected by default. Microsoft recommends using Subnet-directed broadcasts in ConfigMgr. I will explain the difference between these options.

Unicast, as the transmission method for sending wake-up packets to a computer in a ConfigMgr site, uses the IP address of the target computer from hardware inventory to route to the target computer's subnet, and it uses the MAC address of the target computer from hardware inventory to construct the wake-up packet. When the wake-up transmission reaches the target computer's subnet, the wake-up packet is sent directly to the target computer. More:
http://technet.microsoft.com/en-us/library/bb693568.aspx

Subnet-directed broadcasts, as the transmission method for sending wake-up packets to a computer in a ConfigMgr site, uses the MAC address and IP subnet address of the target computer from hardware inventory. The wake-up transmission is sent to the computer's last known subnet, and it is then broadcast to all computers on that subnet. For this method to be successful, all intervening routers must be configured to forward subnet-directed broadcasts. During this broadcast, the computer that has the MAC address specified in the wake-up transmission will respond. More: http://technet.microsoft.com/en-us/library/bb632807.aspx

By default UDP port 9 is configured. This can be changed to a custom UDP port, if Wake On LAN isn't working. Sometimes port 12287 is used to get it working then. Otherwise it may be unchanged.

What else is needed for Wake On LAN functionality?

1) The ConfigMgr client must be functional on devices
2) Hardware Inventory must be running, and information must be uploaded in the ConfigMgr database
3) IP/Subnet-directed broadcast is needed on routers/switches for broadcast forwarding

Other Conditions for Wake On LAN to work:

1) Wake-up packet transmissions are sent only from Primary site servers
2) Wake on LAN option to Power On in BIOS should be enabled
3) WOL requires information of both IP and MAC Address (IP address for location, MAC address to receive magic packets)
4) Information of machine should be in ARP cache of the router (ARP is a mapping of MAC and IP addresses)
5) WOL will not be able to wake a Bare Metal Machine since its has not reported back its inventory with its IP address

When Hardware Inventory is not available for a device, no Wake On LAN functionality is possible. Especially the Network Adapter and Network Adapter Configuration is needed to resolve the MAC and IP addresses. 
On the routers/switches broadcast forwarding must be configured. Then all is done to have Wake On LAN functionality working. Now have a look which components in ConfigMgr supporting WOL.

WOL functionality is supported for Software distribution, Software Updates, and OS deployment. Just create an advertisement for that and enable Wake On LAN as part of a mandatory assingment.

When choosing an Advertisement start time during non-working hours, with Wake On LAN enabled, that will be the time when devices will start-up and run the task(s) specified. During installation, updating and/or deploying different reports and logs can be viewed to control them.

Report: "All computers targeted for Wake On LAN activity"
Report: "All sites that are enabled for Wake On LAN" 

Wolmgr.log - Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.
WolCmgr.log - Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent and retried.

When there are specific questions about WOL functionality, leave a comment.

Using Zero Touch Installation (ZTI) in ConfigMgr

With ConfigMgr 2007 and 2012 there is OS Deployment possible with the use of Task Sequences. When advertise/deploy a Task Sequence used for OS Deployment, there is the choice for Lite Touch or Zero Touch Installation. In this blog I willl explain the difference between them, and what to do for having Lite Touch and/or Zero Touch functionality.

First I will explain the difference between them:

• Lite Touch Installation (LTI) is used when F12 must be pressed on the local device during PXE boot the device;
• Zero Touch Installation (ZTI) is used when nothing has to do be done on the local device for PXE boot functionality.

When using Windows Deployment Services (WDS) and/or Microsoft Deployment Toolkit (MDT), Lite Touch functionality is possible. With the use of System Center Configuration Manager (ConfigMgr), Zero Touch functionality will also become available. Both scenarios are handy, and will be used by customers. The choice between them, has something to do with Management, BIOS settings and (remote) locations.

Now let's have a look at the advertise/deploy settings:

When advertise/deploy an OS Deployment Task Sequence, choose "Make this task sequence available to boot media and PXE".

On the next screen create a Mandatory assignment when ZTI is needed. This will make the big difference between LTI and ZTI, a Mandatory assignment!

For having ZTI, also the PXE boot order must be set. When the Network adapter is not in first place, there is no ZTI possible. Also decide on which collection ZTI deployment will be advertised/deployed. This is not recommended on most collections, so create a new collection, specific for ZTI deployments!

On the ConfigMgr PXE service point, additional properties can be set. When "Require a password for computers to boot using PXE" is selected, no ZTI deployment is possible also. This will be become handy with LTI deployment, when pressing F12 for PXE boot, a password is needed to get a new OS image.

Also a big difference; with LTI a device can be installed many times again with a new image, without anything to do with the device in ConfigMgr collections. Only make sure that the device is placed in the right collection, where the advertisement is set.

With ZTI a device gets a PXE advertisement on the device in ConfigMgr collections, to prevent it for being installed over and over again. When a device must get a new OS image, just rightclick on the object, and choose "Clear Last PXE Advertisement. When this is done, the advertisement will become active automatically with next boot.

When will LTI or ZTI be the best solution? It depends..

When total control is needed, Password security, Choose between different OS images, Another boot order (harddisk or USB first), LTI will be the best solution there is. When remote OS deployment is needed, Auto-install on remote locations, Wake-On-LAN support, No interaction on the device, ZTI will be the best solution there is.

Do not hesitate when things are not clear enough, or additional questions are left. Just leave a comment then.