Quick Machine Recovery auf Windows Server 2025 einrichten – Grams IT

Mit dem kumulativen Update KB5126646 vom 13. Oktober 2026 (OS Build 26100.33650) hat Microsoft Quick Machine Recovery auf Windows Server 2025 gebracht. Die Funktion stammt aus Windows 11 und soll Systeme, die nicht mehr booten, aus der Wiederherstellungsumgebung heraus reparieren: Der Server startet in WinRE, holt sich eine Verbindung ins Netz, fragt Windows Update nach einer passenden Korrektur und spielt sie ein. Microsoft hielt die Neuerung laut für wichtig genug, um am 19. Oktober noch einen eigenen Eintrag im Release-Health-Message-Center nachzuschieben.

Auf Servern ist die Funktion standardmäßig aus. Wer sie nutzen will, muss sie per Gruppenrichtlinie oder mit reagentc.exe einschalten und sollte vorher wissen, was dabei im Hintergrund passiert, welche Netzwerkvoraussetzungen gelten und warum WSUS-Umgebungen leer ausgehen.

Dieser Artikel geht die Microsoft-Dokumentation durch: Funktionsweise, Standardverhalten, die vier Gruppenrichtlinien-Einstellungen, die Kommandozeilenvariante, der Stand beim Recovery CSP und die Grenzen, die Microsoft selbst benennt.

Woher Quick Machine Recovery kommt

Die Vorgeschichte ist der 19. Juli 2024. Ein fehlerhaftes Update des CrowdStrike-Falcon-Sensors schickte weltweit Windows-Maschinen in eine Bluescreen-Schleife, und die Reparatur bestand meist darin, von Hand in WinRE zu booten und eine Datei zu löschen. Pro Gerät. Microsoft hat daraus im November 2024 die Windows Resiliency Initiative gemacht. David Weston, bei Microsoft für Enterprise- und OS-Sicherheit zuständig, nannte Quick Machine Recovery dort den ersten Schritt aus den Lehren des Juli-Vorfalls: gezielte Korrekturen aus Windows Update auf Maschinen bringen, die nicht mehr starten, ohne physischen Zugriff.

Der Weg zu Server war lang. Im März 2025 ging die Funktion für Windows 11 24H2 in den Beta-Kanal des Insider-Programms. Im Juli 2025 kam mit KB5062660 die allgemeine Verfügbarkeit für Windows 11, auf Home-Geräten standardmäßig aktiv, auf Pro, Education und Enterprise aus. Server 2025 folgte jetzt, 15 Monate später.

Wie die Wiederherstellung aus WinRE technisch abläuft

Quick Machine Recovery ist kein eigenes Betriebssystem-Modul, sondern eine Erweiterung der Windows Recovery Environment. WinRE ist das kleine, auf Windows PE basierende System, das auf einer eigenen Partition liegt und bei Startproblemen automatisch anspringt. Laut der technischen Referenz zu WinRE passiert das unter anderem nach zwei aufeinanderfolgenden fehlgeschlagenen Startversuchen oder zwei unerwarteten Abschaltungen innerhalb von zwei Minuten nach dem Boot.

Bislang konnte WinRE dort nur das reparieren, was in der Startup-Reparatur fest eingebaut war. Quick Machine Recovery gibt WinRE eine Netzwerkverbindung und einen Weg zu Windows Update. Microsoft beschreibt die Funktion über zwei getrennte Schalter:

Cloud Remediation ist der eigentliche Kern. Ist sie aktiv, verbindet sich WinRE mit dem Netzwerk und sucht bei Windows Update nach einer Korrektur. Ist sie aus, bleibt es bei der lokalen Startup-Reparatur wie bisher.

Auto Remediation steuert, ob das ohne Benutzereingriff passiert. Ist sie aktiv, läuft die Suche automatisch an. Findet der erste Durchlauf nichts, landet der Benutzer standardmäßig bei den anderen Wiederherstellungsoptionen; alternativ lässt sich ein Wiederholungsintervall konfigurieren, dann probiert das System es in Schleife weiter. Ist Auto Remediation aus oder nicht konfiguriert, muss jemand in WinRE von Hand auf die Option klicken.

Der dokumentierte Ablauf hat fünf Phasen:

Das Gerät scheitert wiederholt beim Booten, Windows erkennt das und leitet die Wiederherstellung ein.
Das Gerät startet in WinRE.
WinRE stellt eine Netzwerkverbindung her und fragt Windows Update nach Korrekturen ab.
Wird eine Korrektur gefunden, lädt WinRE sie herunter und wendet sie an. Wird nichts gefunden, entscheidet die Konfiguration: einmaliger Scan mit Weiterleitung zu den manuellen Optionen, oder Wiederholung nach Intervall und Gesamtzeitlimit.
Neustart. Bootet Windows durch, ist die Sache erledigt. Scheitert der Start erneut, geht es zurück zu Phase 2.

Was konkret als „Korrektur” ankommt, bestimmt Microsoft. Die Dokumentation spricht von gezielten Remediations aus Windows Update, und eine erfolgreich angewendete Korrektur taucht anschließend unter Einstellungen > Windows Update > Updateverlauf im Bereich Qualitätsupdates auf. Im CrowdStrike-Szenario wäre das ein Paket, das die defekte Kanaldatei entfernt. Welche Formate und Aktionen ein solches Paket sonst noch ausführen darf, dokumentiert Microsoft öffentlich nicht; die Microsoft-Seiten sagen nur, dass es sich um von Microsoft bereitgestellte Remediations handelt.

Ein Satz aus der Dokumentation, den man sich merken sollte: Microsoft stuft die Funktion ausdrücklich als Best-Effort ein. Sie findet nicht für jedes Problem eine Lösung, und sie findet überhaupt nur dann etwas, wenn Microsoft für genau dieses Problem eine Remediation veröffentlicht hat.

Standardverhalten: Warum die Funktion auf Windows Server 2025 aus ist

Microsoft unterscheidet bei den Voreinstellungen nach Verwaltungsstatus, nicht nach Produkt. Auf Systemen ohne Unternehmensverwaltung, also Windows Home und Pro-Geräten ohne Domänenbeitritt und ohne MDM-Registrierung, ist Cloud Remediation mit einmaligem Auto-Scan eingeschaltet. Auf verwalteten Systemen ist sie aus: Enterprise und Education, domänengebundene oder MDM-verwaltete Pro-Geräte und alle Editionen von Windows Server 2025.

Die Logik dahinter ist nachvollziehbar. Ein Server, der ohne Zutun des Admins aus WinRE heraus ins Internet geht und Pakete von Windows Update einspielt, ist in vielen Umgebungen nicht gewollt, und ein Admin soll die Entscheidung bewusst treffen. Eine Feinheit aus der Dokumentation: Solange Sie die Einstellung nicht anfassen, passt Windows das Standardverhalten automatisch an, wenn ein System zwischen verwaltet und unverwaltet wechselt. Sobald Sie explizit konfigurieren, bleibt Ihre Einstellung in beiden Zuständen bestehen.

Für Server heißt das: Wer nichts tut, hat nach dem Oktober-Update denselben Zustand wie vorher. Das Update installiert die Fähigkeit, nicht das Verhalten.

Quick Machine Recovery per Gruppenrichtlinie aktivieren

Microsoft hat für Server einen eigenen Support-Artikel zur Gruppenrichtlinie veröffentlicht, ebenfalls datiert auf den 13. Oktober 2026. Er trägt den Hinweis, dass er mit KI-Unterstützung erstellt wurde, deckt sich aber in allen Angaben mit der allgemeinen Dokumentation. Die Gruppenrichtlinie ist laut Microsoft derzeit nur für Windows Server 2025 verfügbar; auf Windows-11-Clients führt der Weg über den Recovery CSP oder die Einstellungen-App.

Voraussetzung ist eine Server-2025-Installation mit dem Oktober-2026-Sicherheitsupdate oder neuer, eine funktionierende WinRE-Konfiguration und Netzwerkzugriff aus der Wiederherstellungsumgebung auf die Dienste, die Cloud Remediation braucht. Die administrativen Vorlagen müssen die Einstellungen enthalten; wer einen zentralen Store für ADMX-Dateien pflegt, muss ihn also mit den Vorlagen vom aktualisierten Server befüllen.

Der Pfad lautet Computerkonfiguration > Administrative Vorlagen > System > Quick Machine Recovery. Es sind Computereinstellungen, Loopback-Verarbeitung ist nicht nötig. Vier Einstellungen gibt es:

Einstellung	Aktiviert	Deaktiviert	Nicht konfiguriert
Enable Cloud Remediation	WinRE darf Remediations aus Windows Update laden und anwenden	Keine Cloud-Remediation, nur lokale Ressourcen	Lokale Einstellung, sonst Editionsstandard (bei Server: aus)
Enable Auto Remediation	Bei Startfehler automatische Suche ohne Benutzerinteraktion	Suche nur nach manuellem Anstoß	Lokale Einstellung, sonst Editionsstandard
Set Recovery Retry Interval	Minuten zwischen Wiederholungsversuchen, 0 bis 4320; 0 bedeutet ein Versuch ohne Wiederholung	Lokale Einstellung, sonst 0 Minuten	Lokale Einstellung, sonst 0 Minuten
Set Total Recovery Wait Time	Maximale Gesamtzeit aller Versuche in Minuten, 1 bis 4320; danach normaler Boot oder Standard-WinRE	Lokale Einstellung, sonst 180 Minuten	Lokale Einstellung, sonst 180 Minuten

Die von Microsoft validierte Minimalkonfiguration besteht aus den ersten beiden Einstellungen auf „Aktiviert”. Für einen einzelnen Server geht das über gpedit.msc, für die Domäne empfiehlt Microsoft ein dediziertes GPO mit sprechendem Namen, verknüpft mit einer OU, die nur Server-2025-Computerkonten enthält, und einen Pilotkreis vor dem breiten Rollout.

Zwei Hinweise aus dem Artikel sind für Server wichtiger als für Clients. Erstens: Bei Headless-Systemen, an denen niemand vor einem Bildschirm sitzt, sollte das Retry-Intervall größer als 0 sein. Sonst macht das System pro Wartezeitraum genau einen Versuch, und wenn Microsoft die Remediation erst Stunden nach dem Ausfall veröffentlicht, verpasst der Server sie. Zweitens: „Nicht konfiguriert” ist kein Ausschalter. Wer sicherstellen will, dass ein Server nie aus WinRE ins Netz geht, setzt beide Schalter explizit auf „Deaktiviert”.

Die Kontrolle nach dem Rollout läuft klassisch: gpupdate /force, dann gpresult /scope computer /r für die Richtlinienzuordnung und reagentc /getrecoverysettings in einer erhöhten Eingabeaufforderung für die tatsächlich wirksame Konfiguration.

Konfiguration mit reagentc und XML

Ohne Gruppenrichtlinie, etwa auf einem Alleinstehenden oder in einem Skript, geht es über reagentc.exe. Die Einstellungen stehen in einer XML-Datei, die mit folgendem Befehl angewendet wird:

cmd

reagentc.exe /setrecoverysettings /path settings.xml

Das Beispiel aus der Microsoft-Dokumentation sieht so aus:

xml

<?xml version='1.0' encoding='utf-8'?>

<WindowsRE>
    <WifiCredential>
        <Wifi ssid="ContosoWiFi" password="ContosoWiFiPassword" />
    </WifiCredential>
    <CloudRemediation state="1" />
    <AutoRemediation state="1" totalwaittime="2400" waitinterval="120"/>
</WindowsRE>

state="1" schaltet die jeweilige Funktion ein. totalwaittime und waitinterval sind Minuten; im Beispiel wartet das System bis zu 40 Stunden und prüft alle zwei Stunden. Den WifiCredential-Block lassen Sie auf einem Server mit Kabelanschluss schlicht weg. Beachten Sie, dass ein WLAN-Passwort in dieser Datei im Klartext steht und reagentc /getrecoverysettings es auch im Klartext wieder ausgibt.

Zum Auslesen dient reagentc.exe /getrecoverysettings, zum Zurücksetzen reagentc.exe /clearrecoverysettings. Mit reagentc.exe /info sehen Sie nebenbei, ob WinRE überhaupt aktiviert ist und wo das Image liegt; ein deaktiviertes WinRE macht die ganze Funktion wirkungslos.

Dann gibt es noch den Testmodus mit reagentc.exe /SetRecoveryTestmode und reagentc.exe /BootToRe, der einen simulierten Absturz durchspielt, ohne dass etwas kaputt ist. Nur: Laut Dokumentation ist er derzeit auf Windows-Client-Geräte im Experimental-Kanal des Insider-Programms beschränkt. Auf einem produktiven Server 2025 gibt es damit keinen offiziellen Weg, die Kette vom Bootfehler bis zur Remediation ohne echten Fehler zu testen. Das ist aus meiner Sicht die größte Lücke der Server-Umsetzung.

Recovery CSP und Intune: Stand bei Server

Für MDM-verwaltete Geräte gibt es den Recovery CSP mit den Knoten unter ./Vendor/MSFT/Recovery/QuickMachineRecovery: EnableQuickMachineRecovery (bool), darunter AutoRemediationSettings/EnableAutoRemediation (bool), SetRetryInterval (0 bis 4320 Minuten) und SetTimeToReboot (1 bis 4320 Minuten). Die Abhängigkeiten sind streng: Auto Remediation setzt aktiviertes Quick Machine Recovery voraus, Intervall und Wartezeit setzen aktivierte Auto Remediation voraus, und das Intervall darf die Wartezeit nicht überschreiten.

Die Applicability-Tabellen des CSP nennen als Editionen Pro, Enterprise, Education und IoT Enterprise, als Betriebssystem Windows 11 24H2 ab Build 26100.8737 beziehungsweise 25H2 ab 26200.8737. Windows Server steht dort nicht, und die CSP-Seite wurde zuletzt am 23. September 2026 aktualisiert, also vor dem Server-Release. Ob der CSP auf Server 2025 funktioniert, lässt sich aus der Dokumentation nicht ableiten; Microsoft verweist für Server ausschließlich auf die Gruppenrichtlinie. Wer Server über Intune verwaltet, sollte das vor dem Rollout selbst prüfen oder bei der GPO bleiben.

Netzwerkanforderungen in WinRE

Der kritischste Punkt für Server steht in der WinRE-Referenz, nicht in der QMR-Dokumentation. WinRE hält standardmäßig keine Netzwerkverbindung; es baut sie nur auf, wenn ein Wiederherstellungsworkflow sie braucht. Dann versucht es der Reihe nach Ethernet, ein für WinRE vorkonfiguriertes WLAN-Profil, in Preview-Builds gespeicherte WLAN-Profile des Hauptsystems, und zuletzt die manuelle Auswahl.

Unterstützt werden laut Microsoft nur unauthentifiziertes Ethernet, WPA-Personal-Netze mit SSID und Passwort sowie bestimmte WPA-Enterprise-Varianten mit Maschinenzertifikaten, deren private Schlüssel im Software-KSP liegen; TPM-gebundene Schlüssel gehen derzeit nicht. Die QMR-Dokumentation selbst fasst es knapper: nur kabelgebunden und WPA/WPA2 mit Passwort.

Für Serverumgebungen ergeben sich daraus drei Prüfpunkte. Erstens: Hängt der Server-Port hinter 802.1X-Portauthentifizierung oder einer NAC-Lösung, bekommt WinRE keine Verbindung, denn „unauthentifiziertes Ethernet” ist die Bedingung. Zweitens: WinRE muss aus seinem Segment heraus Windows Update erreichen. Microsoft nennt keine eigene Endpunktliste für Quick Machine Recovery; wer Windows Update per Firewall nur über WSUS erlaubt, hat hier eine Lücke. Einen Proxy erwähnt die Dokumentation nicht, was in Umgebungen mit erzwungenem Proxy ein Problem sein dürfte. Drittens: Virtuelle Maschinen auf Hyper-V oder VMware haben in der Regel ein einfaches virtuelles Ethernet und sind damit die unkomplizierteste Zielgruppe, sofern das VLAN der VM nach außen darf.

WSUS und die Grenzen der Funktion

Microsoft schreibt im Troubleshooting-Teil des GPO-Artikels in aller Klarheit: Weder WSUS noch eine getrennte Update-Infrastruktur liefern Quick-Machine-Recovery-Remediations. Das Server-Design hängt ausschließlich von Windows Update ab. Für Betreiber, die ihre Server bewusst von Windows Update abgeschnitten haben und alles über WSUS fahren, ist die Funktion damit in der aktuellen Form nicht nutzbar, es sei denn, sie öffnen für WinRE einen separaten Pfad nach draußen. Das ist eine Architekturentscheidung, keine Richtlinieneinstellung.

Weitere Grenzen, die Microsoft selbst nennt: Die Remediation muss existieren und auf das Gerät passen. Ein Bootfehler durch einen kaputten Treiber eines Drittanbieters wird nur dann repariert, wenn Microsoft dafür ein Paket baut und per Windows Update ausliefert. Ein Hardwaredefekt, ein zerstörtes Dateisystem oder ein Problem mit dem Bootmanager bleiben außen vor. Und der Testmodus fehlt, wie beschrieben, auf Server.

Was ich in der Dokumentation vermisse: eine Angabe, wo WinRE auf Server protokolliert, welche Remediations es gefunden und angewendet hat, und wie ein Admin nachträglich nachvollzieht, was ein Server in WinRE getan hat. Der Updateverlauf in der Einstellungen-App ist auf einem Server Core nicht die erste Anlaufstelle. Bis Microsoft das dokumentiert, bleibt nur das Ausprobieren.

Fairerweise: Microsoft verspricht auch nichts anderes. Die Funktion ist als Werkzeug gegen flächige Ausfälle gebaut, bei denen tausende Maschinen dasselbe Problem haben und Microsoft eine Korrektur zentral verteilen kann. Für den Einzelfall, den ein Server mit einer eigenwilligen Konfiguration produziert, war sie nie gedacht.

Was das für den Serverbetrieb bedeutet

Die Entscheidung, ob Sie Quick Machine Recovery einschalten, hängt an zwei Fragen: Kann WinRE aus Ihrem Netz Windows Update erreichen, und wollen Sie, dass ein Server ohne Ihr Zutun Pakete von Microsoft einspielt?

Wer beide Fragen mit Ja beantwortet, sollte die Funktion mit allen vier Einstellungen konfigurieren, nicht nur mit den beiden Hauptschaltern. Ein Retry-Intervall von 0 bringt bei einem Server, der nachts um drei in die Bootschleife geht, wenig: Der einzige Versuch läuft, bevor Microsoft überhaupt reagieren konnte. Ein Intervall von 60 bis 120 Minuten bei einer Gesamtwartezeit von mehreren Stunden passt besser zu einem Gerät, das ohnehin niemand anschaut. Die Gesamtwartezeit sollte dabei zu Ihrem Wiederanlaufplan passen; ein Server, der 40 Stunden in WinRE auf Microsoft wartet, ist für diese Zeit genauso weg wie ohne die Funktion.

Wer eine der Fragen mit Nein beantwortet, sollte beide Hauptschalter explizit auf „Deaktiviert” setzen und das GPO trotzdem ausrollen, damit „Nicht konfiguriert” nicht irgendwann zu einem anderen Editionsstandard führt. Der Oktober-Artikel von Microsoft sagt ausdrücklich, dass nur „Deaktiviert” ein verlässlicher Aus-Zustand ist.

Unabhängig von der Entscheidung gilt: Quick Machine Recovery ersetzt kein Backup, keinen Wiederanlaufplan und keine getestete WinRE-Konfiguration. Prüfen Sie mit reagentc /info, ob WinRE auf Ihren Servern aktiv ist und auf einer eigenen Partition liegt, denn genau das wird nach Jahren von In-Place-Upgrades gern vergessen. Und noch ein Hinweis zum Update selbst: KB5126646 hat laut Microsoft ein bekanntes Problem mit Exchange Server, bei dem OWA-Anmeldungen und Mailversand scheitern können, weil der Endpoint Mapper ein Speicherlimit bekommen hat. Wer Exchange auf Server 2025 betreibt, liest vor der Installation den verlinkten Workaround.

Fazit

Quick Machine Recovery auf Windows Server 2025 ist technisch das, was Windows 11 seit gut einem Jahr hat: ein netzwerkfähiges WinRE, das bei Microsoft nach einer passenden Reparatur fragt. Die Konfiguration über vier Gruppenrichtlinien-Einstellungen ist sauber dokumentiert, die Kommandozeile über reagentc ebenso. Die eigentlichen Hürden liegen daneben: Es funktioniert nur mit direktem Zugriff auf Windows Update, nicht über WSUS, es braucht unauthentifiziertes Ethernet, und es gibt auf Server keinen Testmodus.

Meine Einschätzung: Für VMs mit einfacher Netzanbindung und Windows-Update-Zugriff ist die Funktion ein sinnvoller zusätzlicher Fallback gegen den nächsten CrowdStrike-Moment, mehr nicht. Für gehärtete Umgebungen mit WSUS und 802.1X ändert das Oktober-Update nichts außer der Notwendigkeit, die Schalter explizit auf „Deaktiviert” zu setzen.

Prüfen Sie diese Woche auf einem Pilotserver reagentc /info und reagentc /getrecoverysettings, entscheiden Sie bewusst, und rollen Sie das GPO in der einen oder der anderen Richtung aus.

Quellen: