Microsoft SCCM is deployed generally in a centralised manner – in the datacentre and with some downstream roles assigned to branch servers etc. For example you may have one or two SCCM servers in the primary / secondary DC and downstream you roll out distribution points so that package and image management is not sent over the WAN links – only the management traffic is.

Wake On LAN is a layer 2 broadcast protocol that allows you to turn on a PC. It’s incredibly handy when your far away from the target PC or you want to wake up a bunch of PCs to patch them or roll out new software. However, any decent WAN will block IP directed broadcasts by default for security and to stop broadcast / storm attacks.

SCCM supports serveral ways to roll out Wake on LAN. For the purpose of this blog post we will focus on the client settings power management method. Be sure to enable WOL on your client computers – this is done in BIOS/EFI and is different for each motherboard vendor / model.

Prequisite – Enable Power Management in SCCM Client Settings:
SCCM Console > Site Administration > Client Settings > Edit your client settings > Power Management:
– Allow Power Management set to YES
– Allow Network Wakeup set to ENABLED.
– Wake On LAN port number (UDP) set to 9 (default).

It’s important to note that these settings also configure the network adapter driver in Windows which enables WOL and the recieving of the magic packet. Using SCCM client settings means you dont have to configure any driver settings.

What does this do? When you try and wake up a PC in SCCM it will forward a packet to a client in the same subnet as the target and that client will send a WOL broadcast on the client subnet. How does this work though when you have a dynamic vlan technology such as 802.1x or Mac Address Bypass (MAB)? Short answer is IP Directed Broadcast on your L3 switch. In the below example I am using a Cisco Catalyst C9407R IOS-XE L3 core switch.

You will need to find out what your fail VLAN or network segement is, as we are going to configure the switch to forward the WOL broadcasts that get delivered to a client -> on to the network that is used for unauthorised switch ports. If you do not have a subnet assigned – you will need to create one on the switch. If the port is still authorised for the client segment WOL will work. The below switch configuration is designed to support both scenarios (authenticated port or unauthenticated port).

Here is the IOS-XE configuration:

ip forward-protocol udp 9
!
interface Vlan7
description CLIENT
ip address 10.0.0.1 255.255.254.0
ip helper-address 192.168.91.255
no ip redirects
ip access-group client-in in
end
!
interface Vlan88
description UNAUTHORISED
ip address 192.168.88.246 255.255.252.0
ip directed-broadcast 2000
ip access-group 2000 in
end
!
ip access-list extended 2000
10 remark Permit CLIENT Broadcast
10 permit udp 10.0.0.0 0.0.1.255 any eq 9
30 deny ip any any

Notes:
Configuring the ip forward-protcol command tells the ip helper feature to forward on UDP port 9 (WOL) packets. On IOS-XE UDP port 9 is the “discard” protocol – you can ignore this – it’s still port 9. In the above example the client subnet that is 802.1x or MAB is VLAN 7. We set the IP helper on the client SVI to the broadcast address of the unauthorised network segment. Keep in mind the devices in unauthorised do not need an ip address we just need to be able to send them a broadcast packet for WOL to work.

The unauthorised SVI has the ip directed broadcast statement on it permitting only WOL packets (udp port 9) from the client subnet. So SCCM sends to the host on the client subnet and the switch forwards the packet to the unauthorised VLAN (with ip helper) which in turn forwards it to the entire segment (ip directed broadcast) but only once it passed the access control-list. This is important, it stops someone on the LAN side creating a broadcast storm. Another point to note is the unauthorised SVI has a large subnet to cope with the largest broadcast domain in the environment. The network is non routable on the WAN service as its essentially just serving as a point for the packets to be copied to and forwarded out.

How do I wake a pc in SCCM?
Right click the target client > Client notification > Wake-Up. You will be informed if there is a client device on the target subnet to send the packet to. Simply click ok to that message:


I’ve done all of this and some PCs wont Wake Up – even though I can see the magic packet (with a sniffer like Wireshark)?
Update the network driver on the PC – I have seen this occur on Intel based drivers in Windows 10 and 11 – the EFI/BIOS has WOL enabled but when the PC is turned off the phy does not link the port at layer 1 (link lights are off). As soon as you update to the newest Intel network driver for your version of Windows – it fixes the problem.

It still does not work on Windows 10 / 11?
Disable fast startup. This feature disables Wake on LAN within Windows. If your deploying this via a GPO note that there is a bug with disabling fast startup via GPO for Windows 11. Be sure to use Group Policy preferences and deliver the relevant registry key to disable fast startup in Windows 11.

This project took the best part of a month to really iron out the nuances. I hope this helps anyone else whos trying to acheive flawless Wake on Lan. Let there be magic packets!