WOL And Reboot Over Multiple Subnets With SCCM

Running a Wake On LAN can be tricky if you’ve got lots of subnets to worry about. A magic packet will only work in the local subnet unless you happen to have complete access to your entire network and make some router changes.

There’s also ‘Wake Up Proxy‘ which was added to Configuration Manager that can potentially work too as it’s peer to peer and clients try to wake each other up, but won’t work in a lot of scenarios such as 802.1X.

In light of these, I wrote a script that was a mashed up version of a few things I could find and accomplish the task of sending WOL packets to each subnet I cared about.

What this script does:

  • Pulls computers and in turn, MAC addresses from a pre-created SCCM collection.
  • Checks each computer to see if it’s online
  • If online, it will trigger a reboot countdown of 5 minutes, with a warning prompt
  • If offline, it will send a WOL magic packet to the computer

This is valuable to me for software installs that require no user logged onto a computer. It will leave all computers at the login screen, ready for software installs.

This only works in a single subnet though, so the next trick is to set this up on a server in each subnet as a scheduled task. Each server is configured to check the SCCM collection of computers that exist in that subnet. Then, a master task is created that calls the task on each of the other servers:


This master task triggers all the WOL scripts, on a schedule or on demand as you wish. You need to use an account that has access on all servers required of course to be able to remotely trigger the scheduled tasks.

I’ll also note that Adam Bertram wrote a different WOL script that will find each subnet and use any PC it can find to send WOL commands to other computers which is worth checking out. It doesn’t incorporate the forced reboot, but should be modifiable to achieve that result.

The script uses the free wol.exe program from Gammadnye and is expecting to run from C:\Scripts\ but you can change that to whatever you like without breaking anything.

Download the script here (rename to .ps1)


Start-Transcript -path C:\Scripts\Log\wolreboot.txt
$SiteCode = ‘SCCM Site Code goes here’
$CollectionName = ‘Target collection name goes here’
#Retrieve SCCM collection by name
$Collection = GWMI -ComputerName $siteServer -NameSpace “ROOT\SMS\site_$SiteCode” -Class SMS_Collection | where {$_.Name -eq “$CollectionName”}
#Retrieve members of collection
$SMSMembers = GWMI -ComputerName $SiteServer -Namespace “ROOT\SMS\site_$SiteCode” -Query “SELECT * FROM SMS_FullCollectionMembership WHERE CollectionID=’$($Collection.CollectionID)’ order by name” | select Name

ForEach ($SMSMember in $SMSMembers){
If (test-connection $SMSMember.Name -Count 1 -quiet)
write-host $SMSMember.Name “Online”
$name = $
Start-Process Shutdown “-r -t 300 -m \\$name -c `”Initiating scheduled maintenance reboot. You have 5mins to save your before your PC will reboot`”” -NoNewWindow -Wait
$a = (GWMI -ComputerName $siteServer -Class SMS_R_SYSTEM -Namespace root\sms\site_$SiteCode | where {$_.Name -eq $SMSMember.Name}).MACAddresses
$a = $a -replace ‘:’,”
foreach ($mac in $a){

C:\Scripts\\wol.exe $mac
write-host $ “WOL packet sent” $mac
write-host `r`n}


Update 9th August 2016

A few changes to the script – it’ll now log via transcript, but more importantly will support SCCM client objects with multiple MAC addresses, and broadcast each found MAC address.

SCCM 2012 R2 Slow Imaging Fix

Microsoft have released on 8th November 2013 a hotfix for SCCM 2012 R2, KB2905002. Unless you’re not using SCCM for imaging, this hotfix is a must. This fix fixes two seperate issues. The first which I’ll copy verbatim from Microsoft’s site is:

After you enable the PXE Service Point role on an instance of a specific distribution point, or you select the Deploy this boot image from the PXE-enabled distribution point property of a boot image, the Windows Deployment Service (WDS) stops running.

Pretty major bug. The second fix everyone would have noticed is around the slowless of deploying an image (a.k.a. OSD) from R2. It’s rather slow! Again, verbatim:

When operating system image files are downloaded to Configuration Manager 2012 R2 clients, you may find that the download takes longer than it did in previous versions of Configuration Manager 2012 clients. You may see this behavior when the target client is running Windows PE or a full Windows operating system.

You can download the fix from and the fix needs to be installed on pretty much any SCCM server you have. It will nicely create packages if you have lots of servers to push it out to, or you can just do it manually per server. It will stop and start services, and ask you to restart after installing in most scenarios so keep this in mind.

Distribution Points don’t need the update, even if they’re running as a PXE Service Point. You can’t run it on one (I tried!).

You’ll also need to run the hotfix against any PC running the console as there’s an update for that too.

Thanks yet again to @nickstugr for alerting me to the update.

Update 12/11/2013 – Confirmed that the patch has put deployment speeds back to how they once were.

SCCM 2012 R2 Upgrade Breaks Report Builder


Just a quickie. After upgrading System Center Configuration Manager 2012 SP1 to R2, I could no longer create a report in the console. The error you see when clicking ‘Create Report’ is “The Report Builder click-once application does not exist on the report server ‘’. Ensure that the report builder application manifest exists on the server and try again.”

It DOES exist, just that the R2 upgrade changes a few settings.

This is actually the same issue when SP1 is installed, with the exact same fix. The full details are on this technet article: but the brief two steps to perform on your SCCM/Config Manager server are –

1. Change the registry key “HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/ConfigMgr10/
AdminUI/Reporting/ReportBuilderApplicationManifestName” from the value “ReportBuilder_2_0_0_0.application” to “ReportBuilder_3_0_0_0.application”

2. Edit the file
“C:\Program Files (x86)\Microsoft Configuration
Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe.config” and change the 2 to a 3 in the two areas:


<add key=”10.0″ value=”ReportBuilder_2_0_0_0.application”/>
<add key=”DEFAULT” value=”ReportBuilder_2_0_0_0.application”/>

<add key=”10.0″ value=”ReportBuilder_3_0_0_0.application”/>
<add key=”DEFAULT” value=”ReportBuilder_3_0_0_0.application”/>


That’s it. You should now be able to build reports again.

Troubleshooting NIC Drivers in WinPE for SCCM 2012


This is one of the problems that every SCCM (System Center Configuration Manager) admin will come across. You’re trying to deploy an image to a PC from PXE booting, and you can’t get the list of task sequences to show up. The PC will reboot, and you’ll wonder what happened.

There’s several different ways to troubleshoot this, but it’s most likely network card drivers required in your Boot Image in SCCM. Where do you start on this though? There’s a couple of things to enable/set to make it a little easier.

First, enable command support on both your x86 and x64 boot images (Software Library > Overview > Operating Systems > Boot Images). This will allow you to press F8 when running WinPE from a task sequence, which brings up a command prompt to let you check things like log files.

The other setting I recommend is making custom Windows PE backgrounds (same screen as the command support option). Have one for your 32 bit Boot Image, and a different one for your 64 bit. This means when something fails, you can tell at a glance which boot image was used and troubleshooting accordingly.

boot image

Back to working out your NIC issue. If the task sequence is bombing out early on, press F8 to get your command prompt, then use the command ‘ipconfig’ If you see hardly any information, including the lack of an IP address then it’s a strong indicator that the correct NIC driver isn’t loaded. I’m going to guess you’ve checked the network cable is plugged in :)

To work out what NIC driver is required can be tricky. If your hardware came with an OS already loaded, or a recovery disk, you can load that up and from Windows see what driver is associated with the Network card. Here’s a good step by step guide on how to add the drivers:

Generally (but not always) the driver you see in the standard OS should work in the WinPE environment too. You will probably need both 32 and 64 bit versions injected into the relevant boot images.

There’s also the log files to read, which can be rather messy when you first start out. From the command line window, run the command ‘cmtrace x:\windows\temp\smstslog\smsts.log’ and have a read – that’s your best bet to find out what’s causing your task sequence to fail. Do a quick google of the error code number you see to get an idea on what you’re dealing with.

Here’s an incredibly long breakdown of SCCM 2012 log files if you’re that way inclined:

Sometimes, this won’t even work which was the case with a new HP 800 G1 SFF I was working on. As a last resort, I knew the NIC was Intel I217, so I grabbed the latest driver pack from Intel themselves:*&DownloadType=Drivers

After downloading an extracting all these drivers, I attempted the brute force method. Following these instructions: I loaded the lot onto a USB drive, and just started loading driver after driver with the command ‘drvload filename.INF’ and then checking if the network was there using the ‘ipconfig’ command. About 10 drivers in, one of them took longer to load (e1d63x64.inf) and I had an IP address! I then loaded both the 32 and 64 bit versions into the boot images, and my task sequence to deploy Windows 7 was working.

If you’re not even getting as far as WinPE launching, then you’ve got a completely different issue, so start researching!

System Center 2012 Configuration Manager SP 1 Cumulative Update 3

Last Friday (18th September 2013) Microsoft released CU3 For SCCM 2012 SP1. This has a few little fixes, but the most important part is the addition of Windows 8.1 support.

Information about the update, and the hotfix itself is available at

The install is required on Primary and Secondary sites, but not Distribution Points. It’s actually quite a nice installer and does the standard pre-requisite checks and has links to deployment instructions. It’s recommended to close all consoles, but a reboot of the server isn’t required (it will shut down a bunch of services anyway, so consider it an outage). Funnily enough, the installer says to restart your computer at the end also.


As part of the install, it will ask if you want to create packages to install the updated client, the console and server. With the push towards Applications rather than Packages you think they’d do both, but that doesn’t seem to be the case.

Note that you can’t update a standalone install of the console with this update, you’ll need to either deploy it, or manually run it. The install file should be located at “\\\SMS_PAA\hotfix\KB2882125\AdminConsole\i386” and the install string: “msiexec.exe /p configmgr2012adminui-sp1-kb2882125-i386.msp /L*v %TEMP%\configmgr2012adminui-sp1-kb2882125-i386.msp.LOG /q REINSTALL=ALL REINSTALLMODE=mous”

You can take out the /q to actually see the install rather than waiting for msiexec.exe to disppear from your running processes :) I also needed to reboot after updating the console.

The install process went without a hitch for me, hopefully you’ll experience the same.

Thanks to @sam1310 for alerting me to this update.

Update: To clarify, this patch is for Windows 8.1 and Windows Server 2012 R2 management, not deployment.

To officially deploy Windows 8.1 or Windows Server 2012 R2 you still need SCCM 2012 R2. This explains it quite well:

 If you are still running System Center Configuration Manager 2007, the SCCM Team has announced that they will be providing an update for Windows 8.1 (and Server 2012 R2) to make them fully supported clients. However, just as Windows 8 there will be no support for Operating System Deployment.


Also from Technet:

 Configuration Manager 2007 Service Pack 2

As with System Center 2012 Configuration Manager Service Pack 1, we are adding the following operating systems to our client support matrix in Configuration Manager 2007 with SP2 (includes Configuration Manager 2007 R2 and Configuration Manager 2007 R3):

  • Windows 8.1 Pro
  • Windows 8.1 Enterprise
  • Windows Server 2012 R2 Standard
  • Windows Server 2012 R2 Datacenter

Note: Though these will be fully supported as clients, there is no plan to add support for deploying these as operating systems by using the Configuration Manager 2007 operating system deployment feature. Also, no site servers or site systems will be supported on any version of Windows Server 2012 R2.