Sektion 25: Power & Sleep Settings via Intune

Warum Power- und Sleep-Settings im Enterprise keine Kleinkram-Themen sind

Energieverwaltung klingt nach Nutzerkomfort. In Wahrheit ist sie Infrastruktur. Drei reale Szenarien: Ein Autopilot-Deployment bricht um 2 Uhr nachts ab, weil der Laptop nach 15 Minuten Inaktivität einschläft und mitten im ESP aufwacht – mit halb installierter Software. Ein BitLocker-Gerät liegt über Nacht im Sleep-Zustand in der Bahn – der RAM bleibt bestromt, die Verschlüsselungsschlüssel liegen im Klartext im Speicher. Ein Digital-Signage-Client im Foyer geht um 22:00 Uhr aus, weil niemand an Energy-Settings gedacht hat, und zeigt morgens einen schwarzen Bildschirm statt der Werbecampagne.

Ohne zentrale Steuerung entscheidet jedes Gerät selbst: OEM-Defaults, Nutzereingaben, alte Group Policies und Modern-Standby-Eigenheiten mischen sich zu einem unvorhersehbaren Verhalten. Der Helpdesk sammelt dabei Tickets der Kategorie „mein Rechner macht komische Sachen“, ohne dass jemand die Ursache im Energieverhalten vermutet. Mit Intune holt ihr das komplette Power-Verhalten in eine versionierbare, reportbare Konfiguration – und dieser Artikel zeigt euch genau, wie, bis auf Registry-Ebene.

Grundkonzepte: Wie Windows Energieentscheidungen trifft

Die Energiestufen: S0 bis S5

Windows kennt mehrere ACPI-Zustände, und jede Intune-Policy wirkt nur auf die Zustände, die die Hardware tatsächlich unterstützt:

• S0 Low Power Idle / Modern Standby: Das System bleibt technisch aktiv, fällt aber in einen tiefen Idle-Zustand (DRIPS – Deepest Runtime Idle Platform State). Netzwerk kann in definierten Fenstern erreichbar bleiben. Fast alle aktuellen Laptops arbeiten so.
• S1–S3 (klassischer Standby): RAM bleibt bestromt, Prozessor und Peripherie sind aus. Resume in Sekunden – aber der RAM-Inhalt bleibt physisch zugreifbar, solange Strom fließt.
• S4 (Hibernate): Der RAM-Inhalt wird in die hiberfil.sys geschrieben, danach fährt das System komplett herunter. Kein Standby-Verbrauch, langsamerer Resume.
• S5 (Soft Off): Das reguläre Herunterfahren.
• Hybrid Sleep: S3 plus gleichzeitiges Sichern des RAM auf Disk – konzipiert für Desktops, damit ein Stromausfall die Session nicht zerstört.

Welche Zustände ein konkretes Gerät kann, verrät ein einziger Befehl:

powercfg /a

Typische Ausgabe auf einem Modern-Standby-Laptop:

The following sleep states are available on this system:
    Standby (S0 Low Power Idle)
    Hibernate
    Fast Startup

The following sleep states are not available on this system:
    Standby (S3)
        The system firmware does not support this standby state.

Merkwürdigkeiten im Geräteverhalten fast immer hier begründen: Eine Policy, die S3 erwartet, wirkt auf einem Modern-Standby-Gerät sichtbar „nicht“, obwohl sie korrekt angewendet wurde. Ein Desktop ohne Akku hat gar keinen DC-Zustand – alle „on battery“-Einstellungen sind dort per Definition nicht anwendbar. Und ein System ohne aktives Hiberfile kann nicht nach S4 wechseln, egal was die Policy sagt.

Modern Standby vs. klassischer Sleep – und warum das für eure Policies zählt

Beim klassischen S3-Sleep ist die Welt einfach: Sleep heißt Strom vom RAM, fertig. Modern Standby dagegen ist ein aktiv gemanagter Zustand: Windows wacht intern periodisch auf, erledigt Wartungsfenster (Windows Update, Defender-Scans, indexierung), kann Netzwerk halten (Connected Standby) und entscheidet pro Aufwacher, ob es weiterschlafen darf. Konsequenz für euch: Auf Modern-Standby-Geräten sind AllowStandbyStatesWhenSleepingOnBattery-artige Einstellungen irrelevant, dafür sind die Connectivity- und Power-Request-Policies des ADMX_Power CSP relevant. Ein „Gerät wacht nachts ständig auf“ ist auf solchen Geräten erst mal kein Fehler, sondern Design – entscheidend ist, was es beim Aufwachen tut.

AC und DC: jede Einstellung existiert doppelt

Das Windows-Power-Modell trennt konsequent zwischen Netzbetrieb (AC) und Batteriebetrieb (DC). Display-Timeout, Sleep-Timeout, Hibernate-Timeout, Lid-Action, Button-Actions – alles gibt es in einer „on battery“ und einer „plugged in“ Variante. Das ist keine Formsache: Der häufigste Designfehler in realen Umgebungen ist, AC-Werte auf DC zu kopieren. Plötzlich schläft der Laptop in der Präsentation ein, sobald das Netzteil gezogen wird. Entwerft beide Spalten bewusst, mit der Frage: „Was soll das Gerät tun, wenn es mobil ist?“

Der Transportweg: Power CSP, ADMX_Power CSP und der Settings Catalog

Intune transportiert Energie-Einstellungen über zwei Configuration Service Provider:

• Power CSP unter ./Device/Vendor/MSFT/Policy/Config/Power/...: die eigenständigen Policies wie SelectLidCloseActionOnBattery, StandbyTimeoutPluggedIn oder EnergySaverBatteryThresholdOnBattery. Die meisten davon sind intern ADMX-backed – sie schreiben in die klassischen GPO-Registry-Schlüssel unter HKLM\SOFTWARE\Policies\Microsoft\Power\PowerSettings\{GUID} mit den Wertenamen ACSettingIndex und DCSettingIndex.
• ADMX_Power CSP unter ./Device/Vendor/MSFT/Policy/Config/ADMX_Power/...: die klassischen Power.admx-Policies, die im GPO-Editor unter System > Power Management liegen – etwa Netzwerk-Konnektivität im Standby, Power-Requests von Anwendungen, Batterie-Aktions- und Level-Einstellungen oder Power Throttling.

Vier Eigenschaften dieser CSPs muss man auswendig kennen, weil sie 90 Prozent der Troubleshooting-Fälle erklären:

• Datentyp chr für ADMX-backed Policies: Der SyncML-Payload muss XML-kodiert sein. Wer solche Einstellungen als Custom OMA-URI mit Integer-Datentyp setzt, produziert stille Fehler. Praktische Konsequenz: Settings Catalog verwenden, der die Kodierung übernimmt.
• Scope: Fast alle Power-Policies sind Device-Scope. Die große Ausnahme ist Prompt for password on resume from hibernate/suspend (PW_PromptPasswordOnResume) – die ist User-Scope und schreibt unter HKCU\Software\Policies\Microsoft\Windows\System\Power. In ein Device-Profil gepackt, wartet ihr vergeblich.
• Versionsschwellen: Die Timeouts (Display, Sleep, Hibernate) existieren seit Windows 10 1709, die Button- und Lid-Actions sowie Energy-Saver-Thresholds seit 1903, AllowStandbyStatesWhenSleepingOnBattery seit 1803, AllowHibernate erst ab Windows 11 21H2, und der komplette ADMX_Power CSP ab Windows 10 2004 mit KB5005101 bzw. Windows 11 21H2. Ältere Clients melden die Policies als „Nicht zutreffend“.
• Dependencies: Die Energy-Saver-Thresholds hängen an Power/EnableEnergySaver – der Settings Catalog zeigt diese Abhängigkeit beim Hinzufügen an, und ihr solltet die abhängige Einstellung im selben Profil konfigurieren, damit die Policy atomar ankommt.

Praxis-Implementierung: die Power-Baseline in sechs Schritten

Schritt 1: Bestandsaufnahme mit powercfg

Bevor ihr Werte festlegt, wisst ihr, was eure Flotte kann. Drei Befehle auf einem Referenzgerät jeder Hardwareklasse:

# Unterstützte Sleep-States
powercfg /a

# Akku-Gesundheit und -Kapazität (HTML-Report)
powercfg /batteryreport

# Wer blockiert gerade den Sleep? (Apps, Treiber, Audio)
powercfg /requests

Gruppiert danach gedanklich in drei Klassen: Modern-Standby-Laptops, klassische S3-Geräte und Alt-Desktops, und Sonderfälle (Kioske, Signage, Build-Maschinen), die bewusst nie einschlafen dürfen.

Schritt 2: Die Baseline entwerfen

Eine bewährte Start-Baseline für Standard-Office-Laptops – alle Timeouts in Sekunden:

Video and Display Settings
  Turn off the display (on battery)        = 300    (5 Min)
  Turn off the display (plugged in)        = 600    (10 Min)

Sleep Settings
  Specify the system sleep timeout (on battery)     = 900    (15 Min)
  Specify the system sleep timeout (plugged in)     = 1800   (30 Min)
  Specify the system hibernate timeout (on battery)  = 10800  (3 Std)
  Specify the system hibernate timeout (plugged in) = 3600   (1 Std)

Button Settings
  Select the lid close action (on battery)   = Sleep
  Select the lid close action (plugged in)   = Take no action
  Select the Power button action (on battery)  = Hibernate
  Select the Power button action (plugged in)  = Shut down

Die Systematik dahinter:

• Die Timeout-Kette ist aufsteigend: Display < Sleep < Hibernate. Das Display geht zuerst aus, dann schläft das System ein, und nach einer definierten Zeit sichert Hibernate den Zustand endgültig auf Disk. Eine durchbrochene Kette (Sleep nach 10 Minuten, Hibernate nach 5) erzeugt unvorhersehbares Verhalten.
• Lid-Close im Netzbetrieb auf „Take no action“: Nutzer im Docking-Setup schließen den Deckel und arbeiten am externen Monitor weiter. Der häufigste Legacy-Fehler ist hier „Sleep“ – dann geht der externe Screen schwarz.
• Der Powerbutton als Hibernate-Fallback: Damit hat der Nutzer eine kontrollierte Methode, den Zustand manuell zu sichern, ohne einen vollständigen Shutdown zu machen.

Die Action-Werte sind bei allen Button- und Lid-Einstellungen identisch: 0 = Take no action, 1 = Sleep (Default), 2 = Hibernate, 3 = Shut down.

Schritt 3: Das Profil im Settings Catalog anlegen

Devices > Configuration > Create > New Policy > Plattform „Windows 10 and later“ > Profile type „Settings catalog“. Im Katalog nach den Friendly Names suchen – alle Power-Einstellungen liegen unter Administrative Templates > System > Power Management mit den Unterordnern Sleep Settings, Button Settings, Video and Display Settings, Energy Saver Settings und Notification Settings.

Drei Details, die beim Anlegen regelmäßig übersehen werden:

• Alle Timeout-Werte werden in Sekunden eingegeben – 300, nicht 5.
• Jede Einstellung gibt es als AC- und DC-Variante. Wer nur eine Variante konfiguriert, lässt die andere bewusst dem Nutzer bzw. den Defaults über – das kann gewollt sein, sollte aber entschieden sein.
• Power-Settings niemals in zwei Profilen gleichzeitig konfigurieren. Intune meldet das als Konflikt, und welcher Wert gewinnt, ist im Nachhinein nicht sauber nachvollziehbar. Ein einziges, dokumentiertes Baseline-Profil pro Geräteklasse.

Schritt 4: Sonderfälle per Custom OMA-URI abbilden

Die wenigen echten Integer-Policies lohnt ihr über ein Custom-Profil. Beispiel Hibernate explizit erlauben (ab Windows 11 21H2):

Name:      AllowHibernate
OMA-URI:   ./Device/Vendor/MSFT/Policy/Config/Power/AllowHibernate
Data type: Integer
Value:     1

Wichtiges Detail aus der Doku: Diese Policy überschreibt keine powercfg-Konfiguration. Wenn Hibernate lokal per powercfg /hibernate off oder per Registry-Wert HibernateEnabled=0 unter HKLM\SYSTEM\CurrentControlSet\Control\Power deaktiviert wurde, bleibt es aus – die Policy wirkt nur als Freigabe, nicht als Zwang. Klassischer Stolperstein bei OEM-Images, die Hibernate ab Werk abschalten.

Und die Passwortabfrage nach dem Aufwachen – User-Scope, also ein eigenes Profil mit User-Zuweisung:

Name:      PW_PromptPasswordOnResume
OMA-URI:   ./User/Vendor/MSFT/Policy/Config/ADMX_Power/PW_PromptPasswordOnResume
Data type: String
Value:     <enabled/>

Falls ihr eine ADMX-backed Einstellung mit Element-Wert doch per OMA-URI setzen müsst, ist das dokumentierte Muster der XML-kodierte Payload mit dem ADMX-Element-Namen, zum Beispiel für den Sleep-Timeout:

Name:      StandbyTimeoutOnBattery
OMA-URI:   ./Device/Vendor/MSFT/Policy/Config/Power/StandbyTimeoutOnBattery
Data type: String
Value:     <enabled/><data id="DCStandbyTimeOut_2" value="900"/>

Schritt 5: Zuweisung, Filter und Rollout

Power-Policies wirken je nach Hardwareklasse unterschiedlich – deshalb sortiert die Zuweisung vorab nach Chassis. Ein Intune-Filter für mobile Geräte:

(device.chassisType -in ["9", "10", "14"])

Chassis 9 ist Laptop, 10 Notebook, 14 Sub-Notebook. Damit bekommt das Laptop-Baseline-Profil nur Geräte mit Deckel, Akku und Sleep-Logik – Desktops bleiben raus und verschmutzen eure Reports nicht mit „Nicht zutreffend“.

Drei Muster für die Zuweisung:

• Laptop-Baseline an die gefilterte Gruppe der mobilen Geräte. Lid- und Button-Actions sind der Hauptgrund für die Trennung.
• Never-Sleep-Profil für Kioske, Signage und CI-Maschinen als eigene Policy: Sleep-Timeouts auf 0 (= nie automatisch einschlafen), Unattended Sleep Timeout auf 0, Display je nach Use Case.
• Pilot vor dem Rollout: eine kleine Testgruppe, zwei Tage Verhalten beobachten, dann den nächsten Ring ausrollen. Power-Settings sind für Nutzer sofort spürbar – ein Fehlrollout ist hier lauter als bei fast jeder anderen Policy.

Schritt 6: Validieren – auf Registry-Ebene

Die Policy schreibt ihre Werte in die Policy-Registry, und genau dort lest ihr sie zur Kontrolle wieder aus. Die GUIDs sind stabil und dokumentiert – ein Auslesescript für die Kernwerte:

$base = 'HKLM:\SOFTWARE\Policies\Microsoft\Power\PowerSettings'

# Sleep-Timeout (GUID 29F6C1DB-86DA-48C5-9FDB-F2B67B1F44DA)
Get-ItemProperty "$base\29F6C1DB-86DA-48C5-9FDB-F2B67B1F44DA" |
    Select-Object ACSettingIndex, DCSettingIndex

# Display-Timeout (GUID 3C0BC021-C8A8-4E07-A973-6B14CBCB2B7E)
Get-ItemProperty "$base\3C0BC021-C8A8-4E07-A973-6B14CBCB2B7E" |
    Select-Object ACSettingIndex, DCSettingIndex

# Lid-Close-Action (GUID 5CA83367-6E45-459F-A27B-476B1D01C936)
Get-ItemProperty "$base\5CA83367-6E45-459F-A27B-476B1D01C936" |
    Select-Object ACSettingIndex, DCSettingIndex

# Powerbutton-Action (GUID 7648EFA3-DD9C-4E3E-B566-50F929386280)
Get-ItemProperty "$base\7648EFA3-DD9C-4E3E-B566-50F929386280" |
    Select-Object ACSettingIndex, DCSettingIndex

Steht dort der erwartete Wert, hat Intune geliefert. Weicht das Verhalten trotzdem ab, liegt das Problem auf der Client-Seite – Firmware, blockierende Software, lokal deaktiviertes Hibernate – und nicht im Transport. Diese Unterscheidung erspart euch stundenlanges Portal-Debugging.

Best Practices

• Ein Owner pro Einstellung: Jede Power-Einstellung genau einmal in genau einem Profil konfigurieren. Doppelte Konfiguration erzeugt Konflikte, die im Device-Report als Conflict auftauchen und im Feld schwer rekonstruierbar sind.
• Die Timeout-Kette als Architekturprinzip: Display < Sleep < Hibernate, in beiden Strommodi. Für Geräte, die nie hibernaten sollen, die Hibernate-Timeouts weglassen und die Nicht-Konfiguration dokumentieren – „nicht gesetzt“ ist eine Entscheidung, kein Versehen.
• Sicherheit: Hibernate statt Sleep auf schützenswerten Geräten. Im klassischen S3-Sleep bleibt der RAM bestromt – bei BitLocker liegen die Verschlüsselungsschlüssel im Klartext im Speicher. Für Geräte mit hohen Schutzanforderungen konfiguriert ihr kurze Hibernate-Timeouts und die Passwortabfrage nach dem Resume. Modern Standby entschärft das teilweise, aber das Grundprinzip bleibt: Je sensibler das Gerät, desto früher S4 statt S3.
• Autopilot und ESP bedenken: Geräte, die während des Provisioning einschlafen, brechen Enrollment und App-Installationen ab. Für Zero-Touch-Nacht-Deployments gehört ein Never-Sleep-Zustand (AC-Sleep-Timeout 0) in die Provisioning-Phase – als eigenes, bewusst begrenztes Profil.
• Energy Saver mit Bedacht: Thresholds im Bereich 20–30 Prozent Akkulaufzeit sind der übliche Kompromiss zwischen Laufzeit und Vorhersagbarkeit. Immer zusammen mit Enable Energy Saver im selben Profil konfigurieren.
• Hybrid Sleep auf Desktops aktiviert lassen: Desktops können bei einem Stromausfall sonst eine offene Session verlieren. TurnOffHybridSleepPluggedIn nur setzen, wenn ihr einen konkreten Grund habt (etwa SSD-Machines mit sehr großem RAM, bei denen das Hiberfile Platz frisst).
• Ausnahmen als Profile, nicht als lokale Fixes: Wenn ein Signage-Client nie schlafen darf, dann als kommentiertes Ausnahme-Profil – nicht als powercfg-Befehl, der beim nächsten Rebuild spurlos verschwindet.
• Power Throttling kennen: ADMX_Power/PowerThrottlingTurnOff schreibt unter HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling. Für Entwickler- und CAD-Maschinen, bei denen Hintergrunddrosselung Messwerte verfälscht, ist das ein bewusstes Ausnahme-Setting – für Standard-Nutzer lasst es im Default.
• Naming und Versionierung: „Power-Baseline Laptop v1.3“ mit Change-Notiz im Profil ist in drei Jahren mehr wert als jede forensische Registry-Analyse.

Troubleshooting: die häufigsten Fehlerbilder

Profil meldet Fehler oder „Nicht zutreffend“

Erste Frage: Unterstützt das Gerät die Einstellung überhaupt? powercfg /a klärt die Sleep-States, Lid-Actions sind auf Desktops per Definition nicht anwendbar, DC-Werte auf Geräten ohne Akku ebenso. Zweite Frage: OS-Version – die Button-/Lid-Actions brauchen Windows 10 1903+, der ADMX_Power CSP 2004+ mit KB5005101 oder Windows 11 21H2, AllowHibernate Windows 11 21H2+. Dritter Klassiker: ADMX-backed Einstellungen als Custom-OMA-URI mit Integer-Datentyp statt String – das schlägt im SyncML still fehl. Lösung: Settings Catalog.

Der Registry-Wert steht da, aber das Gerät schläft trotzdem nicht ein

Dann blockiert etwas auf dem Gerät die Sleep-Transition. Die Diagnose-Kette:

powercfg /requests      # Wer hält gerade einen Power-Request offen?
powercfg /waketimers    # Welche geplante Timer wecken das System?
powercfg /lastwake       # Was hat das letzte Aufwachen verursacht?

Häufige Täter: Streaming- und Kommunikations-Apps, Backup-Agents, Treiber mit offenen Requests. Ein weiterer dokumentierter Fallstrick: Eine aktivierte Lock-Screen-Slideshow verhindert das Abschalten des Displays und den Sleep-Übergang – die Doku der Timeout-Policies verweist explizit auf die Policy „Prevent enabling lock screen slide show“. Wer an einer Stelle Slideshows erlaubt und an anderer strikte Sleep-Timeouts erzwingt, hat den Konflikt selbst gebaut.

Hibernate fehlt im Startmenü oder als Button-Action

Drei Ursachen, in dieser Reihenfolge prüfen:

powercfg /a          # Ist Hibernate überhaupt verfügbar?
powercfg /h on        # Hiberfile aktivieren, falls deaktiviert
powercfg /hibernate /type full   # Volles Hiberfile statt reduziert

Danach erst die AllowHibernate-Policy prüfen – und daran denken, dass sie ein lokal deaktiviertes Hibernate nicht reaktivieren kann. Das reduzierte Hiberfile (Default bei Windows-Setup mit wenig Disk) unterstützt einige Szenarien nicht; für verlässliche Hibernate-Aktionen gehört /type full in euer Onboarding-Remediation.

Aufwach-Stürme über Nacht

Auf Modern-Standby-Geräten ist periodisches Aufwachen für Wartungsfenster normal. Ob euer Gerät zu viel wacht, zeigt der System-Power-Report:

powercfg /systempowerreport   # erzeugt sleepstudy.html

Der Report zeigt pro Zeitscheibe, wie lange das System wach war, was es geweckt hat und was der wachende Zustand an Akku gekostet hat. Damit trennt ihr sauber zwischen normalem Modern-Standby-Verhalten und einem Störfrieden durch Software. Für Netzwerk-bedingtes Aufwachen gibt es zusätzlich die ADMX-Policies zu Connected-Standby-Konnektivität (AC/DC-Varianten) – auf Geräten, die über Nacht im Netzwerk erreichbar bleiben müssen, bewusst aktivieren, auf allen anderen bewusst deaktivieren.

Hybrid-Umgebungen: GPO gegen Intune

In Environments mit parallelen GPOs setzen oft klassische Policies dieselben Registry-Werte wie Intune. Seit Windows 10 1803 gewinnt bei ADMX-backed Policies die MDM-Richtlinie über die GPO – verlasst euch darauf aber nicht blind, sondern prüft mit gpresult /h report.html, ob eine konkurrierende GPO existiert. Die saubere Lösung bleibt: eine Quelle pro Einstellung, und die GPO zurückfahren, sobald Intune übernimmt.

Die Passwortabfrage nach dem Resume kommt nicht an

PW_PromptPasswordOnResume ist User-Scope. Prüft zwei Dinge: Steht das Profil auf einer Nutzergruppen-Zuweisung (nicht Gerätegruppe), und steht der Wert unter HKCU\Software\Policies\Microsoft\Windows\System\Power mit dem Namen PromptPasswordOnResume? In einem Device-Profil ist die Einstellung grundsätzlich unsichtbar.

Fazit

Energieverwaltung ist oberflächlich trivial und in der Tiefe ein präziser Test eurer Management-Qualität: Ihr müsst ACPI-Zustände kennen, um zu wissen, welche Policy auf welcher Hardware überhaupt wirken kann. Ihr müsst das AC/DC-Doppelprinzip bewusst designen, statt Werte zu kopieren. Ihr müsst den Settings Catalog nutzen, weil ADMX-backed Policies als handgebauter OMA-URI fast immer SyncML-Stille-Fehler produzieren. Und ihr müsst Registry-GUIDs lesen können, um clientseitig zwischen „Policy kam nicht an“ und „Policy kam an, aber etwas blockiert sie“ zu unterscheiden – die wichtigste Diagnose-Weiche in diesem ganzen Themenfeld.

Der Fahrlauf für die Praxis: Bestandsaufnahme mit powercfg /a und /batteryreport, eine dokumentierte Laptop-Baseline mit aufsteigender Timeout-Kette und sauberen Button-Actions, ein Never-Sleep-Ausnahmeprofil für Kioske und Provisioning, ein User-Profil für die Resume-Passwortabfrage, Validierung per Registry-Auslesescript, und ein Pilot-Ring vor dem breiten Rollout. Wer diese Bausteine einmal sauber steht hat, tauscht diffuse Helpdesk-Tickets über „komische Energieeffekte“ gegen nachvollziehbare Reports – und schließt nebenbei eine echte Sicherheitslücke, weil Geräte über Nacht nicht mehr mit geladenem RAM im Sleep liegen. Für BitLocker-Flotten gehört Hibernate-First auf schützenswerten Geräten nicht zum Nice-to-have, sondern zur Compliance-Baseline.

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)