Wake-on-LAN mit PowerShell kann einen geeigneten Rechner über das Netzwerk aufwecken. Dafür sendest du ein sogenanntes Magic Packet an seine Netzwerkkarte. Ob der Rechner darauf reagiert, hängt allerdings von Hardware, Firmware, Energiezustand und Netzwerkweg ab. Dieser Leitfaden zeigt die Voraussetzungen, ein nachvollziehbares PowerShell-Skript und die wichtigsten Prüfungen für Server und Arbeitsstationen.

Wie funktioniert Wake-on-LAN mit PowerShell?

Das Magic Packet enthält sechs Bytes mit dem Wert FF, gefolgt von der MAC-Adresse der Zielnetzwerkkarte in 16 Wiederholungen. Bei einer sechs Byte langen MAC-Adresse ergibt das 102 Byte Nutzdaten (6 + 16 × 6). Häufig wird das Paket als UDP-Datagramm an eine Broadcast-Adresse auf Port 9 oder 7 geschickt. Die Portnummer ist eine Konvention für den Transport, nicht Bestandteil der Erkennung durch die Netzwerkkarte. Microsoft beschreibt das Paketformat in der Dokumentation zu WakeOnMagicPacket.

Wake-on-LAN startet keine Anwendung und meldet sich nicht am Ziel an. Es löst lediglich einen Aufweckvorgang aus, falls der Netzwerkadapter im jeweiligen Energiezustand dafür vorbereitet ist. Ein erfolgreich gesendetes UDP-Paket ist deshalb kein Nachweis, dass der Zielrechner gestartet wurde.

Voraussetzungen: BIOS/UEFI, Netzwerkkarte und Energiezustand

  • Hardware: Mainboard und Netzwerkadapter müssen Wake-on-LAN im gewünschten Energiezustand unterstützen. Bei kabelgebundenem Ethernet ist das meist einfacher zu prüfen als bei WLAN; Wake-on-Wireless-LAN benötigt besondere Unterstützung.
  • BIOS/UEFI: Aktiviere die herstellerspezifische Option, häufig „Wake on LAN“, „Power on by PCI-E“ oder ähnlich. Energiesparoptionen wie ErP können die Stromversorgung des Adapters im ausgeschalteten Zustand abschalten.
  • Windows und Treiber: Aktiviere „Wake on Magic Packet“ in den Adaptereigenschaften, sofern der Treiber die Funktion anbietet. Im Geräte-Manager können unter „Energieverwaltung“ weitere Optionen stehen; Bezeichnungen und Verfügbarkeit unterscheiden sich je nach Gerät.
  • Strom und Verbindung: Netzteil, Netzwerkkarte und Switch-Port müssen im betreffenden Zustand versorgt beziehungsweise verbunden bleiben. Ein vollständig vom Strom getrennter Rechner lässt sich so nicht einschalten.
  • Energiezustand testen: Prüfe Standby, Ruhezustand und Herunterfahren getrennt. Auf Windows-Systemen kann insbesondere der hybride Schnellstart das Aufwecken nach dem Herunterfahren beeinflussen. Ein Test aus Standby beweist keine Unterstützung aus dem ausgeschalteten Zustand.

Auf dem Zielrechner kannst du in einer erhöhten Windows-PowerShell-Sitzung die vom Treiber gemeldeten Einstellungen ansehen:

Get-NetAdapter | Select-Object Name, InterfaceDescription, MacAddress, Status
Get-NetAdapterPowerManagement -Name "Ethernet" | Format-List *

Ersetze Ethernet durch den tatsächlichen Adapternamen. Das Cmdlet ist Teil des Windows-Moduls NetAdapter; auf anderen Betriebssystemen gelten andere Werkzeuge. Eine angezeigte Einstellung allein bestätigt noch nicht, dass Firmware und Netzwerkpfad funktionieren. Microsoft erläutert sowohl Get-NetAdapterPowerManagement als auch die Grenzen verschiedener Windows-Energiezustände.

MAC-Adresse und Broadcast-Adresse richtig ermitteln

Für das Magic Packet brauchst du die MAC-Adresse des physischen Zieladapters, über den der Rechner aufwachen soll. Unter Windows findest du sie etwa mit Get-NetAdapter oder ipconfig /all. Eine IP-Adresse des ausgeschalteten Rechners ist für das Paketformat nicht erforderlich; sie kann nach dem Start aber für die Erreichbarkeitsprüfung nützlich sein.

Der Sender braucht außerdem eine passende Zieladresse. Im selben IPv4-Subnetz nutzt du meist dessen gerichtete Broadcast-Adresse. Sie ergibt sich aus Netzadresse und Subnetzmaske:

Subnetz Broadcast-Adresse
192.168.10.0/24 192.168.10.255
192.168.10.0/23 192.168.11.255

Die Endung .255 ist also keine allgemeine Regel. Verwende die tatsächliche Maske des Zielnetzes und kläre bei mehreren VLANs, über welchen Weg das Paket gesendet werden darf.

Prüfbares Skript: Magic Packet per PowerShell senden

Speichere den folgenden Inhalt als Send-WakeOnLan.ps1. Er funktioniert mit Windows PowerShell 5.1 und PowerShell 7 auf Systemen, die den verwendeten .NET-UDP-Client unterstützen. Der Sender benötigt normalerweise keine Administratorrechte. Trage eine MAC-Adresse und die vorher ermittelte Broadcast-Adresse ein.

[CmdletBinding()]
param(
    [Parameter(Mandatory = $true)]
    [ValidatePattern('^(?:[0-9A-Fa-f]{12}|(?:[0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2})$')]
    [string]$MacAddress,

    [Parameter(Mandatory = $true)]
    [System.Net.IPAddress]$BroadcastAddress,

    [ValidateRange(1, 65535)]
    [int]$Port = 9
)

if ($BroadcastAddress.AddressFamily -ne
    [System.Net.Sockets.AddressFamily]::InterNetwork) {
    throw 'Bitte eine IPv4-Broadcast-Adresse angeben.'
}

$hexMac = $MacAddress -replace '[:-]', ''
$macBytes = New-Object byte[] 6

for ($i = 0; $i -lt 6; $i++) {
    $macBytes[$i] = [Convert]::ToByte($hexMac.Substring($i * 2, 2), 16)
}

$packet = New-Object byte[] 102
for ($i = 0; $i -lt 6; $i++) {
    $packet[$i] = 0xFF
}

for ($repeat = 0; $repeat -lt 16; $repeat++) {
    for ($i = 0; $i -lt 6; $i++) {
        $packet[6 + ($repeat * 6) + $i] = $macBytes[$i]
    }
}

$udp = [System.Net.Sockets.UdpClient]::new()
try {
    $udp.EnableBroadcast = $true
    $endpoint = [System.Net.IPEndPoint]::new($BroadcastAddress, $Port)
    $bytesSent = $udp.Send($packet, $packet.Length, $endpoint)

    if ($bytesSent -ne 102) {
        throw "UDP-Versand unvollständig: $bytesSent von 102 Byte."
    }

    [pscustomobject]@{
        MacAddress  = $MacAddress
        Zieladresse = $BroadcastAddress.ToString()
        Port        = $Port
        PaketBytes  = $packet.Length
        BytesSent   = $bytesSent
    }
}
finally {
    $udp.Dispose()
}

Aufruf im Verzeichnis der Datei:

./Send-WakeOnLan.ps1 -MacAddress 'AA:BB:CC:DD:EE:FF' `
    -BroadcastAddress '192.168.10.255'

Ersetze beide Beispielwerte durch deine Daten. PaketBytes und BytesSent müssen jeweils 102 anzeigen. Das bestätigt den Aufbau und den lokalen Versand des UDP-Datagramms, nicht dessen Empfang oder den erfolgreichen Systemstart. Du kannst das Paket zusätzlich auf einem eingeschalteten Gerät im Zielnetz mit einer Paketaufzeichnung prüfen; ein Filter auf udp.port == 9 hilft beim Auffinden. Ein sichtbares Paket am Empfänger bestätigt den Netzwerkweg bis zu diesem Messpunkt.

Wake-on-LAN über Subnetze und VLANs

Ein lokaler Broadcast wird normalerweise nicht einfach über Router in ein anderes Subnetz weitergeleitet. Für einen Rechner in einem anderen VLAN brauchst du daher eine bewusst eingerichtete Lösung: etwa einen vertrauenswürdigen WoL-Sender im Zielnetz, eine passende Routerfunktion oder eine kontrollierte Weiterleitung gerichteter Broadcasts. Ob eine solche Weiterleitung verfügbar ist, hängt von der Netzwerkinfrastruktur ab und sollte mit der Netzwerkadministration abgestimmt werden.

Öffne dafür nicht pauschal UDP-Port 9 aus dem Internet. Eine bessere Anordnung ist ein authentifizierter Zugang, zum Beispiel über VPN zu einem Verwaltungsrechner im Zielnetz. Dieser Rechner sendet das Paket lokal. Ein Magic Packet enthält keine eingebaute Benutzeranmeldung; wer das Zielnetz erreichen und die MAC-Adresse verwenden kann, kann unter Umständen einen Rechner aufwecken. VLAN-Grenzen, Routerregeln und Zugriffe auf den Sender gehören deshalb zum Sicherheitskonzept.

Firewall und erfolgreiche Inbetriebnahme prüfen

Für den Versand muss ausgehender UDP-Verkehr zum gewählten Broadcast-Ziel erlaubt sein. Zwischen Subnetzen können Router-ACLs oder Firewalls das Paket blockieren. Eine eingehende Windows-Firewall-Regel auf dem schlafenden Zielrechner ist dagegen nicht automatisch die Lösung: Das Aufwecken erfolgt im Netzwerkadapter, bevor das Betriebssystem vollständig läuft. Prüfe zuerst, ob das Paket überhaupt am Zielsegment ankommt.

  1. Teste zunächst im gleichen Subnetz aus einem nachweislich unterstützten Schlafzustand.
  2. Kontrolliere MAC-Adresse, Broadcast-Adresse und die WoL-Optionen im BIOS/UEFI sowie im Treiber.
  3. Prüfe den Versandwert des Skripts und, falls möglich, den Empfang mit einer Paketaufzeichnung auf einem eingeschalteten Gerät im Zielnetz.
  4. Beobachte, ob der Zielrechner startet. Prüfe erst danach, ob Betriebssystem, Netzwerk und benötigte Dienste verfügbar sind. Ein Ping kann durch Firewalls gesperrt sein und ist deshalb allein kein sicherer Startnachweis.
  5. Teste separat Standby, Ruhezustand und Herunterfahren. Notiere, welche Zustände mit der konkreten Hardware funktionieren.

Ein typisches Problem ist der Windows-Schnellstart: Das Aufwecken nach einem normalen Herunterfahren kann anders funktionieren als aus Standby. Microsoft beschreibt diese Unterscheidung in seiner WoL-Dokumentation. Ändere Energieoptionen nur nach einem gezielten Test, statt ein fehlendes Paket oder eine falsche Adresse damit zu überdecken.

Wake-on-LAN automatisieren: Aufgabenplanung und Grenzen

Für einen festen Zeitpunkt kannst du Wake-on-LAN mit PowerShell auf einem Rechner ausführen lassen, der zu diesem Zeitpunkt eingeschaltet ist und das Zielnetz erreicht. In der Windows-Aufgabenplanung hinterlegst du beispielsweise powershell.exe als Programm und als Argumente:

-NoProfile -File "C:\Scripts\Send-WakeOnLan.ps1" -MacAddress "AA:BB:CC:DD:EE:FF" -BroadcastAddress "192.168.10.255"

Die Aufgabe sollte unter einem dafür vorgesehenen Konto laufen; das Skript und die Aufgabenberechtigungen müssen vor unbefugten Änderungen geschützt sein. Ein Skript auf dem ausgeschalteten Zielrechner kann diesen nicht selbst wecken. Beim Einsatz für einen SQL Server oder einen anderen Dienst prüfst du nach dem Aufwecken zusätzlich dessen Dienststatus und tatsächliche Bereitschaft. Wake-on-LAN ersetzt weder Hochverfügbarkeit noch eine getestete Backup- und Restore-Strategie. Bei virtuellen Maschinen verwendest du in der Regel die Verwaltungsfunktionen des Hypervisors; WoL kann höchstens für einen unterstützten physischen Host relevant sein.

Häufige Fragen zu Wake-on-LAN mit PowerShell

Warum meldet das Skript 102 gesendete Bytes, aber der Rechner bleibt aus?

Der Rückgabewert bestätigt nur den lokalen UDP-Versand. Prüfe den Netzwerkweg, die Ziel-MAC, den Energiezustand und die Einstellungen von Adapter und Firmware. Beobachte den Paketempfang im Zielnetz, bevor du Änderungen am Betriebssystem vornimmst.

Muss die Broadcast-Adresse immer auf .255 enden?

Nein. Sie hängt von der Subnetzmaske ab. Bei 192.168.10.0/23 lautet sie beispielsweise 192.168.11.255.

Ist Wake-on-LAN ein sicherer Fernzugriff?

Nein. Das Magic Packet authentifiziert den Absender nicht und stellt keinen Verwaltungszugang bereit. Schütze den Sender und den Netzwerkweg; für die spätere Anmeldung am Rechner gelten separate Zugriffsregeln.

Fazit: Wake-on-LAN mit PowerShell zuverlässig einsetzen

Wake-on-LAN mit PowerShell ist ein nützliches Werkzeug für geplante Starts im eigenen Netz. Der eigentliche Versand ist kurz; die Zuverlässigkeit entsteht durch korrekte Adressen, unterstützte Energiezustände, kontrollierte Netzgrenzen und eine getrennte Prüfung des gestarteten Systems. Teste die konkrete Kombination aus Hardware, Firmware, Windows und Netzwerk, bevor du darauf automatisierte Abläufe aufbaust.