Wake-on-LAN with Windows Home Server — and Any Windows PC

There is a familiar frustration for anyone who runs a home network and cares about their electricity bill: you want your PCs to sleep when nobody is using them, but you also want them available on demand — for a scheduled backup, a remote-desktop session, or a file you left on the other machine. Sleep saves power; sleep also makes a machine unreachable. Wake-on-LAN (WOL) is the feature that squares that circle. It lets one device on your network send a small, specially formed network message that tells another machine's network card to power the computer back up — no physical button press, no walking to the other room.

Windows Home Server was, in its day, an ideal place to orchestrate this. It was always on, always on the network, and it already had a reason to reach out and touch the other PCs in the house. The original post this page replaces flagged a community add-in that did exactly that. Below, we explain the whole mechanism from the ground up, walk through enabling WOL correctly on any Windows PC, and put it in present-day context — because while Windows Home Server itself is long discontinued, Wake-on-LAN works today almost exactly as it did then.

What Wake-on-LAN is, and how the "magic packet" works

Wake-on-LAN is a feature built into most wired network adapters and PC firmware. When a computer is asleep, in hibernation, or even soft-powered-off, the network card is not fully dead: it stays partly powered from standby power and keeps "listening" on the wire for one specific pattern. When it hears that pattern addressed to it, it signals the motherboard to wake the machine.

That specific pattern is the magic packet. It is a small broadcast frame with a very recognisable structure. It begins with six bytes of all ones (the value FF FF FF FF FF FF), followed by the target computer's 6-byte MAC address repeated sixteen times in a row. That repetition is what makes the packet "magic": ordinary traffic almost never contains a MAC address stamped 16 times back-to-back, so the network card can recognise the wake request cheaply while running on minimal power, without needing an IP stack or an operating system.

Two consequences follow from that design, and they explain almost everything about how WOL behaves in practice:

• It targets a MAC address, not an IP address. The sleeping machine has no live IP configuration while it is asleep — that is handled by Windows, which isn't running. So the wake request identifies the target by its hardware (MAC) address instead.
• It is normally a broadcast on the local network. Because the sender can't rely on the target having a known IP, the magic packet is usually sent to the network's broadcast address so that every device on the local segment sees it — and only the card whose MAC matches acts on it.

The packet is typically carried inside a UDP datagram, and by convention it is sent to UDP port 7 or port 9. The port number is largely a convention here; what the network card actually inspects is the magic-packet byte pattern itself, wherever it appears in the frame.

Enabling Wake-on-LAN: firmware first, then Windows

Getting WOL working reliably is a two-layer job. The firmware (BIOS/UEFI) has to allow the network card to stay partly alive and wake the board, and Windows has to be told not to fully power the adapter down and to permit it to wake the machine. If either layer says no, WOL silently fails. Do them in this order.

Step 1 — Enable WOL in the BIOS/UEFI

Restart the PC and enter its firmware setup (usually a key such as Delete, F2, F10, or F12 pressed during boot — the exact key varies by manufacturer). Look under power management, or an advanced/onboard devices section, for an option along the lines of:

• Wake on LAN, Wake on PCI-E, or Power On By PCI-E/PCI
• Resume by LAN or Remote Wake-Up
• On some business machines, a dedicated Wake-on-LAN or PXE remote wake toggle

Wording differs between vendors, so match on the idea rather than an exact string. Enable it, save, and exit. If your firmware has a "deep sleep", "ErP", or "EuP" energy-saving setting, be aware it can cut standby power to the network card and defeat WOL from a powered-off state; if wake-from-shutdown won't work, that setting is a common culprit.

Step 2 — Configure the network adapter in Windows Device Manager

Once firmware allows it, tell Windows to cooperate. Open Device Manager (right-click Start and choose it, or run devmgmt.msc), expand Network adapters, right-click your wired Ethernet adapter, and choose Properties. Then:

1. On the Power Management tab, tick Allow this device to wake the computer. There is usually a second option, Only allow a magic packet to wake the computer — enabling it is wise, so the machine wakes on an intentional WOL request rather than on stray network chatter.
2. On the Advanced tab, look through the property list for entries such as Wake on Magic Packet and Wake on Pattern Match, and make sure the magic-packet option is enabled. Names vary by adapter and driver.
3. Some adapters expose a related setting for waking from a full shutdown (often labelled around "Shutdown Wake-On-Lan" or similar). Enable it only if you need wake-from-off, not just wake-from-sleep.

Step 3 — Note the target's MAC address

To wake a machine you need its network adapter's MAC address. On the target PC, open a command prompt and run ipconfig /all; the value shown as the adapter's Physical Address is its MAC. Record it for the wired adapter you enabled WOL on — that is the address the magic packet must carry.

Why a home server was a natural Wake-on-LAN controller

Everything above enables a PC to be woken. Something still has to send the magic packet at the right moment, and that sender has to be awake and on the network when the moment comes. This is exactly the role a home server fills so neatly.

Windows Home Server was designed to sit quietly in a closet, powered on around the clock, and to reach out to the family's PCs on a schedule — most famously to run automatic nightly backups of each machine. But there is a chicken-and-egg problem: a PC that has been put to sleep to save power can't be backed up, because it isn't reachable. Wake-on-LAN resolves it elegantly. The always-on server can send a magic packet to wake a sleeping PC just before its backup window, let the backup run, and then allow the machine to drift back to sleep afterwards. The household gets both low idle power draw and reliable scheduled maintenance, with no one awake to press a power button at 3 a.m.

The same logic applies to remote access. A home server that acts as a gateway to remote-desktop-capable machines on the LAN is only useful if those machines are awake; pairing that gateway with a WOL trigger means you can reach a PC that had been allowed to sleep. (For more on that gateway role, see the companion archive post, Remote Desktop access with Windows Home Server.)

The community add-ins

Windows Home Server supported add-ins — small extensions that plugged into its console — and the enthusiast community built several that handled Wake-on-LAN: they let you register a PC's MAC address and either send a magic packet on demand or schedule wake-ups so a machine was awake in time for its backup. The original Doug Knox post pointed to one such community add-in. We deliberately don't name a specific add-in or version here: those projects were community-maintained, their download locations and version numbers have long since moved or gone offline, and the underlying mechanism — schedule a magic packet, send it to the target's MAC on the LAN — is what actually matters and is easy to reproduce with any modern WOL tool.

How to send a magic packet, in general terms

You don't need a home server to send a magic packet — any always-available device on the same network can do it, and today that includes routers, NAS boxes, and even phone apps. Whatever the tool, it needs the same three pieces of information:

• The target MAC address — the hardware address of the adapter you enabled WOL on (from ipconfig /all, above).
• Where to broadcast — the local network's broadcast address, so the frame reaches the sleeping card. On a typical home network that is the subnet's broadcast address (for example, the .255 address of your local range).
• A UDP port — conventionally 7 or 9. Either is widely used; the card matches on the magic-packet pattern regardless.

The tool builds the magic packet (the six FF bytes followed by the target MAC repeated 16 times), wraps it in a UDP datagram, and broadcasts it on the LAN. If firmware and Windows are configured as above, the target wakes within a few seconds. That's the entire transaction — it is stateless and one-way, which is why it is so robust and why it has survived essentially unchanged for decades.

Limitations and gotchas

Wake-on-LAN is simple, but its simplicity comes with real constraints worth understanding before you rely on it.

Wired Ethernet is the reliable path

WOL is most dependable over a wired connection on the same local network as the sender. That is the scenario the technology was built for, and it "just works" once configured.

Wi-Fi (WoWLAN) is patchier

Waking a machine over wireless is a distinct feature, usually called Wake on Wireless LAN (WoWLAN). It requires the wireless adapter, its driver, and the access point all to support keeping the radio associated and listening during sleep. Many laptops and Wi-Fi cards simply don't, or do so inconsistently. If you need to wake a specific machine reliably, give it a wired link.

Broadcasts don't cross the internet on their own

Because the magic packet is normally a local broadcast, it does not naturally travel across the internet or between subnets — routers generally don't forward broadcasts inbound. Waking a PC from outside the house therefore takes extra work: either a device already on the LAN (a home server, a NAS, or the router itself) sends the packet locally on your behalf, or the router is configured to relay an incoming wake request to the local broadcast address. Both are doable, but treat any internet-facing wake path as something to secure carefully rather than expose casually.

Power settings can quietly break it

As noted, Windows Fast Startup and aggressive firmware energy-saving modes (ErP/EuP/deep-sleep) can each prevent waking from a fully powered-off state. If WOL works from Sleep but not from shutdown, look there first before assuming the hardware doesn't support it.

Wake-on-LAN today

Windows Home Server itself has been discontinued for years, and its console-add-in ecosystem went with it. But none of that changes Wake-on-LAN, because WOL lives in the network hardware and firmware, not in any particular version of Windows or in the home-server software. The magic packet is exactly the same today as it was then: six FF bytes, the MAC address 16 times, broadcast on the LAN, UDP port 7 or 9.

What has changed is that the "always-on controller" role once played by Windows Home Server is now filled by devices most households already own. A modern NAS can typically send scheduled or on-demand magic packets to wake PCs for backups. Many home routers include a Wake-on-LAN tool in their admin pages. And lightweight WOL utilities and phone apps can wake a desktop across the room or, with the right router setup, from away. The pattern the original post described — let an always-on box wake your sleeping PCs on schedule — is not only still valid, it is easier to achieve now than it was in 2007.

If your goal is a tidy, low-power home network where machines sleep freely but are never truly out of reach, Wake-on-LAN remains one of the most satisfying features to set up. Enable it in firmware, enable it in Windows, note the MAC address, and hand the "send" job to whatever always-on device you already run. For more housekeeping in the same spirit, see our Home Server section and the general How-To Guides, including tune-ups like reclaiming space with Disk Cleanup.