Here’s the scenario: you receive a high-priority voicemail message from your boss in which she tells you nobody in the office can access the company database anymore. You immediately identify two problems: (1) the infrastructure server in question has likely fallen into a hibernation state due to a previous misconfiguration, and (2) you are offsite, and the only person who has access to the server.
Hoo boy ̶ there are quite a few problems there, but let’s focus specifically on one: Is it possible for us to remote-start a Windows Server computer?
Let’s assume in this example the server in question is a hardware server running Windows Server 2016.
Power States and the Windows Operating System
The Advanced Configuration and Power Interface (ACPI) specification defines the following power states for physical computers:
S0: The system is powered on and usable
S1: The system is in standby (sleep) mode
S2: The system is in a deeper sleep state in which CPU context and system cache contents are unavailable
S3: The system is in hybrid sleep mode; the system state is saved to disk in case the computer loses power while in sleep
S4: The system is in hibernation mode. System state is stored on disk, and power consumption is almost nil
S5: The system is completely shut down and consuming no power
The server consumes gradually less power as we move from power states S0 to S5. The bad news for Windows Server administrators, however, is that according to the Microsoft documentation, Windows Server 2016, Windows Server 2012 R2, Windows 10, and Windows 8.1 cannot be remote-started using Wake-on-LAN from the S5 state.
Given that we can remotely start Windows Server 2016 only from sleep (S3) or hibernation (S4), you’ll need to learn what WOL is and how it works.
Wake-on-LAN (WOL) is an industry standard originally created by Intel and IBM that allows a computer system to be awakened by receiving a specially formed Ethernet message.
This “magic” packet has a specially crafted Layer 2 payload that consists of:
6 bytes of hexadecimal Fs
16 repetitions of the target node’s Media Access Control (MAC) hardware address
WOL “magic” packets typically are transmitted as User Datagram Protocol (UDP) datagrams on ports 0, 7 or 9.
To enable WOL on your Windows Server 2016 servers, you need to restart the computers into UEFI/BIOS setup. This is because, at base, WOL functionality is controlled at the motherboard firmware level.
Next, boot back into Windows and inspect the Properties of your server’s network interface card (NIC). Navigate to the Advanced tab and find the setting that corresponds to WOL. The specific setting name depends on your NIC manufacturer; in Figure 1 I show you the robust WOL settings for my Intel NIC driver.
You’ll need to disable fast startup as well because WOL doesn’t work in Windows’ default hybrid shutdown mode. Here’s the relevant Group Policy path:
Computer ConfigurationPoliciesAdministrative TemplatesSystemShutdownRequire use of fast startup
Finally, you’ll either need to configure port forwarding on your home or small office router or create access rules on your corporate firewall to allow WOL traffic into your LAN. Remember that WOL typically communicates on UDP ports 7-9.
Sending the Magic Packet
First-party (Microsoft) configuration management solutions such as System Center Configuration Manager or Operations Management Suite allow you to wake up sleeping or hibernating Windows Server managed nodes with WOL magic packets.
Many third-party systems management tools include WOL functionality as well. Here are three such products:
In Figure 2 you can see SolarWinds Wake-on-LAN, a freeware tool. In Figure 3 you can see LogMeIn, a commercial product. As you’d expect, the free tool requires that you have the target node’s MAC and IP address on-hand; LogMeIn can send a magic packet over the Internet with a single button click.
In Figure 3, the power icon to the left of my “Susan-iMac” system indicates that the computer is in an S3 or S4 state and can be awakened via a WOL magic packet.