Wie baue und pflege ich ein Notfall-Windows für Diagnose, Reparatur und Datenrettung?

Notfall-Windows selbst erstellen: vom leeren USB-Stick zum startfähigen Rettungsmedium

Bauen Sie Ihr Notfall-Windows in einer festen Reihenfolge. Erstellen Sie zuerst ein unverändertes WinPE, prüfen Sie den Start auf echter Hardware und erweitern Sie das Medium erst danach. Diese Reihenfolge wirkt langsam, spart aber im Ernstfall Zeit: Wenn ein später integrierter Storage-Treiber oder ein Startskript den Bootvorgang stört, können Sie auf ein geprüftes Basismedium zurückgehen.

Schritt 1: ADK, WinPE-Add-on und Arbeitsordner vorbereiten

Installieren Sie zuerst das Windows ADK mit der Komponente „Deployment Tools“. Installieren Sie danach das passende Windows-PE-Add-on. Starten Sie anschließend die „Umgebung für Bereitstellungs- und Imageerstellungstools“ als Administrator. Nutzen Sie nicht irgendeine normale Eingabeaufforderung, weil die ADK-Pfade dort oft nicht gesetzt sind.

• Legen Sie einen Arbeitsordner für das WinPE-Medium an, etwa C:\WinPE-Notfall.
• Legen Sie einen Treiberordner an, etwa C:\WinPE-Treiber. Speichern Sie dort nur entpackte Treiberpakete mit .inf-Dateien.
• Legen Sie einen Mountordner an, etwa C:\WinPE-Mount. In diesen Ordner wird das WinPE-Abbild später eingehängt.
• Verwenden Sie einen USB-Stick, dessen Inhalt vollständig gelöscht werden darf. Prüfen Sie vor jedem Formatierungsbefehl Größe und Laufwerksbuchstaben.

Schritt 2: ein unverändertes WinPE-Basismedium erzeugen

Erstellen Sie zuerst den WinPE-Arbeitssatz. Für aktuelle 64-Bit-PCs verwenden Sie in der Regel amd64. Der Befehl erzeugt noch keinen USB-Stick, sondern den lokalen Arbeitsordner mit Bootdateien, Medienstruktur und boot.wim.

copype amd64 C:\WinPE-Notfall

Schlägt dieser Schritt fehl, prüfen Sie zuerst zwei Punkte: Läuft die Deployment-Eingabeaufforderung wirklich als Administrator, und ist das Windows-PE-Add-on installiert? Ohne WinPE-Add-on fehlt die Basis für den Arbeitssatz.

Schritt 3: den richtigen USB-Stick eindeutig identifizieren

Bevor Sie den USB-Stick erstellen, identifizieren Sie das Zielmedium eindeutig. Verlassen Sie sich nicht nur auf einen Laufwerksbuchstaben, weil dieser nach dem Einstecken weiterer Datenträger wechseln kann. Prüfen Sie Größe, Laufwerksbuchstaben und Inhalt.

diskpart
list disk
list volume
exit

Notieren Sie den Laufwerksbuchstaben des USB-Sticks, etwa E:. Bestätigen Sie den nächsten Schritt nur, wenn Sie sicher sind, dass dieser Buchstabe zum USB-Stick gehört. Der Ziel-Datenträger wird formatiert; vorhandene Daten gehen verloren.

Schritt 4: den bootfähigen USB-Stick erstellen

Erstellen Sie nun das bootfähige WinPE-Medium. Ersetzen Sie E: durch den tatsächlich geprüften Laufwerksbuchstaben Ihres USB-Sticks.

MakeWinPEMedia /UFD C:\WinPE-Notfall E:

Starten Sie das Medium jetzt einmal unverändert. Ergänzen Sie noch keine Treiber, keine Zusatztools und kein eigenes Startskript. Wenn der Basis-Stick nicht startet, lösen Sie zuerst dieses Problem. Erst ein zuverlässig startendes Basismedium ist eine saubere Grundlage für weitere Anpassungen.

Schritt 5: Boot, Tastatur, Laufwerke und Netzwerk prüfen

Starten Sie einen Test-PC vom USB-Stick. Öffnen Sie im Firmware-Bootmenü den USB-Eintrag, idealerweise im UEFI-Modus. Nach dem Start sollte eine WinPE-Eingabeaufforderung erscheinen. Prüfen Sie jetzt nicht nur, ob „irgendetwas startet“, sondern ob die Rettungsumgebung praktisch nutzbar ist.

wpeutil UpdateBootInfo
diskpart
list disk
list volume
exit
ipconfig /all

Schritt 6: Storage- und Netzwerktreiber in die Boot-WIM integrieren

Ergänzen Sie Treiber erst nach dem erfolgreichen Basistest. Beginnen Sie mit Storage- und Netzwerktreibern. Storage-Treiber sind entscheidend, wenn WinPE die interne SSD nicht sieht, etwa bei NVMe hinter Intel VMD/RST oder bei RAID-Konfigurationen. Netzwerktreiber sind wichtig, wenn Sie Logs, Images oder Tools über LAN erreichen müssen. Grafik- und Komforttreiber sind für ein Rettungsmedium meist nachrangig.

Legen Sie in C:\WinPE-Treiber nur entpackte Treiberpakete ab. DISM verarbeitet Treiber über INF-Dateien. Hersteller-Installer als .exe müssen Sie vorher entpacken oder durch ein geeignetes INF-Paket ersetzen.

md C:\WinPE-Mount
Dism /Mount-Image /ImageFile:C:\WinPE-Notfall\media\sources\boot.wim /Index:1 /MountDir:C:\WinPE-Mount
Dism /Image:C:\WinPE-Mount /Add-Driver /Driver:C:\WinPE-Treiber /Recurse
Dism /Unmount-Image /MountDir:C:\WinPE-Mount /Commit

Erstellen Sie den USB-Stick nach der Treiberintegration erneut oder aktualisieren Sie das Medium aus dem geänderten Arbeitsordner. Starten Sie danach wieder vom Stick und prüfen Sie mit diskpart, ob die zuvor fehlende SSD oder das Netzwerkgerät nun sichtbar ist. Nehmen Sie nicht mehrere unbekannte Treiberpakete auf einmal auf, wenn Sie ein konkretes Fehlerbild lösen möchten.

Schritt 7: Tools, Logs und Exportordner sauber strukturieren

Kopieren Sie Zusatzwerkzeuge nicht wahllos auf den Stick. Trennen Sie Programme, Treiber, Logdateien und Datenexporte. So finden Sie im Einsatz schneller die richtigen Dateien und vermeiden, dass Bootdateien, Einsatzprotokolle und gerettete Daten durcheinanderliegen.

C:\WinPE-Notfall\media\Tools
C:\WinPE-Notfall\media\Drivers
C:\WinPE-Notfall\media\Logs
C:\WinPE-Notfall\media\Export

Beachten Sie im gestarteten WinPE: Das USB-Medium muss nicht denselben Laufwerksbuchstaben tragen wie unter Ihrem Arbeits-Windows. Prüfen Sie deshalb im Einsatz die vorhandenen Laufwerke, statt starre Pfade vorauszusetzen.

dir C:\Tools
dir D:\Tools
dir E:\Tools
dir F:\Tools

Testen Sie jedes Zusatztool im gestarteten WinPE. Ein Programm, das unter normalem Windows läuft, muss in WinPE nicht automatisch funktionieren. Häufig fehlen Dienste, Laufzeitbibliotheken, grafische Komponenten oder Schreibrechte in erwarteten Profilpfaden. Nehmen Sie nur Werkzeuge in Ihr Standardmedium auf, die Sie wirklich gestartet und geprüft haben.

Schritt 8: Startskript und PowerShell nur bewusst ergänzen

WinPE startet über startnet.cmd. Wenn Sie dieses Skript anpassen, lassen Sie wpeinit stehen. Der Befehl initialisiert wichtige WinPE-Funktionen, unter anderem Netzwerk- und Gerätebestandteile. Ohne diesen Schritt kann ein Medium scheinbar starten, im Einsatz aber Laufwerke oder Netzwerkfunktionen schlechter erkennen.

Dism /Mount-Image /ImageFile:C:\WinPE-Notfall\media\sources\boot.wim /Index:1 /MountDir:C:\WinPE-Mount
notepad C:\WinPE-Mount\Windows\System32\startnet.cmd

Ein minimalistisches Startskript kann so aussehen:

wpeinit
echo Notfall-Windows gestartet.
ipconfig
cmd

Dism /Unmount-Image /MountDir:C:\WinPE-Mount /Commit

PowerShell ist in einem einfachen WinPE nicht automatisch als vollwertige Skriptumgebung vorhanden. Rüsten Sie PowerShell nur nach, wenn Ihre Werkzeuge oder Skripte sie tatsächlich benötigen, und fügen Sie die passenden optionalen WinPE-Komponenten aus derselben ADK-/WinPE-Add-on-Version ein. Für viele Rettungsaufgaben reichen cmd, diskpart, robocopy, manage-bde, bcdboot und dism aus.

Basismedium richtig einordnen: WinPE, WinRE und portable Windows-Installation

Für die oben beschriebene Bauanleitung ist WinPE die Standardbasis. WinRE und portable Vollinstallationen haben andere Stärken, führen aber schneller in Abhängigkeiten, Lizenzfragen oder Wartungsaufwand. Die Abgrenzung ist wichtig, damit Sie nicht versehentlich ein dauerhaftes Arbeits-Windows bauen, obwohl Sie ein reproduzierbares Rettungsmedium brauchen.

WinPE: schlanke Basis für Diagnose, Reparatur und Datenrettung

Windows Preinstallation Environment ist eine reduzierte Windows-Laufzeitumgebung für Installation, Deployment, Offline-Wartung und Wiederherstellung. WinPE startet typischerweise in eine RAM-Disk und enthält nur einen begrenzten Werkzeugkasten. Genau das ist für ein Notfallmedium ein Vorteil: Sie kontrollieren, welche Treiber, Tools und Skripte in die boot.wim gelangen, und können das Ergebnis gezielt testen.

Planen Sie WinPE nicht als allgemeines portables Betriebssystem. Es eignet sich für Rettungs- und Wartungsaufgaben, nicht für normalen Dauerbetrieb. Wenn Sie diese Grenze akzeptieren, erhalten Sie eine kleine, reproduzierbare Umgebung, die sich besser versionieren, dokumentieren und auf neue Hardware anpassen lässt als eine vollwertige externe Windows-Installation.

WinRE: lokale Wiederherstellung statt universelles Rettungsmedium

Windows Recovery Environment basiert technisch auf WinPE, ist aber näher an der lokalen Windows-Installation. Es liegt typischerweise auf einer Recovery-Partition und stellt Funktionen wie Starthilfe, Systemwiederherstellung, Eingabeaufforderung oder „Diesen PC zurücksetzen“ bereit. Umfang und Anpassungen hängen von Windows-Build, Edition, Herstellerabbild und lokalen Komponenten ab.

Nutzen Sie WinRE vor allem für installationsnahe Wiederherstellung. Für ein externes Medium, das auf unterschiedlichen PCs starten und unabhängig vom lokalen Recovery-Zustand funktionieren soll, ist ein separat gebautes WinPE besser kontrollierbar.

Portable Windows-Installation: nur als Sonderfall planen

Windows To Go ist nicht mehr offiziell unterstützt. Technisch lassen sich vollständige Windows-Umgebungen weiterhin auf externe Datenträger bringen, für ein Notfallmedium sind sie aber selten der beste Standardweg. Treiberinstallation, Updates, Benutzerprofile, persistente Änderungen, Sicherheitsstatus und Lizenzfragen machen die Umgebung schwerer kontrollierbar.

Eine portable Vollinstallation kann sinnvoll sein, wenn Sie eine vollständige grafische Arbeitsumgebung, komplexe Forensik-Suiten, VPN-Clients oder Management-Agenten benötigen. Für die meisten Rettungsaufgaben ist ein geprüftes WinPE stabiler, kleiner und nachvollziehbarer.

Bootkette, Secure Boot und Treiber: das fertige Medium belastbar prüfen

UEFI-Bootpfad prüfen: nicht nur starten, sondern nachvollziehen

Ein Notfall-Windows muss auf aktueller Hardware zuverlässig starten. Der kritischste Teil ist die frühe Bootkette: Firmwaremodus, Bootloader, WinPE-Start und Erkennung von Storage- und Netzwerkhardware. Prüfen Sie deshalb nicht nur, ob der Stick an einem bekannten PC funktioniert. Testen Sie mindestens ein UEFI-System mit aktivem Secure Boot, ein Notebook mit NVMe-SSD und ein Gerät, das Netzwerk über USB-C-Dock oder USB-Ethernet nutzt.

Für UEFI-Medien ist der Fallback-Pfad \EFI\Boot\bootx64.efi entscheidend. Ein sauber erstelltes WinPE-Medium nutzt diesen Pfad, sodass die Firmware das Medium auch ohne individuellen NVRAM-Eintrag starten kann. Wenn ein PC den Stick nicht anzeigt, prüfen Sie zuerst Bootmodus, Secure Boot, USB-Port, Stick-Erstellung und Firmware-Menü, bevor Sie das WinPE-Image verändern.

• Boot-Konfiguration prüfen: bcdedit /enum all
• Datenträgerlayout anzeigen: diskpart, danach list disk und list volume
• UEFI-Dateien inventarisieren: Binden Sie die EFI-Systempartition nur gezielt ein und prüfen Sie dann den Ordner \EFI.

Secure Boot: Startfähigkeit ohne unsichere Umwege erhalten

Ein Rettungsmedium sollte auf Standard-UEFI-Systemen mit aktivem Secure Boot starten, ohne dass Sie die Firmware-Sicherheit im Ernstfall dauerhaft herabsetzen müssen. Verwenden Sie deshalb aktuelle Microsoft-Bootkomponenten aus einer gepflegten ADK-/WinPE-Basis und vermeiden Sie improvisierte Pre-Boot-Loader. Dokumentieren Sie bei jedem Test, ob Secure Boot aktiv war oder ob Sie nur in einem weniger strengen Firmwaremodus getestet haben.

• Secure-Boot-Status prüfen, falls PowerShell-Komponenten verfügbar sind: powershell -NoProfile -Command "Confirm-SecureBootUEFI"
• Alternativ im Firmware-Menü dokumentieren: Notieren Sie Bootmodus, Secure-Boot-Status, USB-Bootoption und getestetes Gerät.
• Nicht als Erfolg werten: Ein Test mit deaktiviertem Secure Boot ersetzt keinen Test mit aktivem Secure Boot, wenn das Medium später auf produktiven Geräten funktionieren soll.

Storage-Treiber: fehlende SSDs, VMD/RST und RAID sauber behandeln

Ein häufiges Fehlerbild lautet: Das Notfall-Windows startet, aber die interne Systemplatte fehlt. Moderne Plattformen nutzen NVMe, teils hinter Intel VMD/RST oder in RAID-Konfigurationen. Ohne passenden Treiber zeigt diskpart dann nicht die erwartete SSD oder nur unbrauchbare Volumes. In diesem Fall integrieren Sie den passenden INF-Treiber offline in die boot.wim oder laden ihn im Einsatz testweise nach.

drvload X:\Drivers\Storage\Beispieltreiber.inf
diskpart
list disk
exit

Ersetzen Sie den Beispielpfad durch die tatsächliche INF-Datei. Funktioniert ein nachgeladener Treiber zuverlässig, integrieren Sie ihn anschließend sauber per DISM in die Boot-WIM und dokumentieren Sie Hersteller, Version, Quelle, Datum und betroffene Geräteklasse.

Netzwerk: LAN als Rettungsweg bevorzugen, WLAN nur getestet einsetzen

Für Rettungsszenarien ist Netzwerkzugriff hilfreich, aber nicht selbstverständlich. Kabelgebundenes Ethernet ist in WinPE meist robuster als WLAN, weil weniger Dienste, Profile, Zertifikate und Authentifizierungsdetails zusammenspielen. Planen Sie LAN, USB-Ethernet oder ein getestetes Dock als Standardweg. WLAN eignet sich nur, wenn Treiber, Profile und Authentifizierung vorher erfolgreich geprüft wurden.

wpeutil InitializeNetwork
ipconfig /all
ping <gateway-ip>

Wenn ipconfig /all keinen Adapter zeigt, fehlt meist der Treiber. Wenn ein Adapter sichtbar ist, aber keine Adresse erhält, prüfen Sie DHCP, Kabel, Switch, VLAN, Dockingstation und Firewallregeln. Vermeiden Sie im Rettungsmedium fest hinterlegte WLAN- oder Domänenzugangsdaten, wenn der Stick von mehreren Personen genutzt wird.

Testmatrix: wann Ihr Notfall-Windows einsatzbereit ist

Ein Rettungsmedium ist erst einsatzbereit, wenn es den Standardtest nach jeder Änderung besteht. Einzeltests auf einem vertrauten Desktop reichen nicht aus. Testen Sie Hardwareklassen, die im Ernstfall tatsächlich vorkommen: Notebook, Desktop, Workstation, USB-C-Dock, NVMe-System, BitLocker-Gerät und mindestens ein UEFI-System mit aktivem Secure Boot.

Notfall-Windows im Einsatz: Diagnose, Datenrettung und Startreparatur Schritt für Schritt

Vor jeder Reparatur: erst prüfen, dann sichern, dann schreiben

Trennen Sie konsequent zwischen Diagnose und Veränderung. Lesen, Inventarisieren und Kopieren sollten am Anfang stehen. Schreibende Eingriffe wie chkdsk /f, Registry-Änderungen oder bcdboot folgen erst, wenn Sie das Zielsystem korrekt identifiziert und wichtige Daten gesichert haben. Diese Reihenfolge schützt vor vermeidbaren Folgeschäden.

Windows-Partition und Zielmedium sicher finden

In WinPE können Laufwerksbuchstaben anders aussehen als im installierten Windows. Die Windows-Partition muss nicht C: heißen. Suchen Sie deshalb zuerst die Partition mit dem Windows-Ordner und prüfen Sie anschließend das externe Zielmedium für die Datensicherung.

diskpart
list disk
list volume
exit

dir C:\Windows
dir D:\Windows
dir E:\Windows
dir F:\Windows

Prüfen Sie das Zielmedium genauso bewusst. Es sollte genug freien Speicher bieten und große Dateien unterstützen. Für umfangreiche Benutzerprofile ist NTFS meist die robustere Wahl als FAT32, weil FAT32 einzelne Dateien auf 4 GB begrenzt.

dir F:\
md F:\Export
md F:\Export\Logs

BitLocker-Volume entsperren, bevor Sie Daten kopieren

Prüfen Sie zuerst den Verschlüsselungsstatus. Verwenden Sie den 48-stelligen BitLocker-Wiederherstellungsschlüssel nur für das tatsächlich betroffene Volume. Dokumentieren Sie keine Schlüssel im Klartext in allgemein zugänglichen Logdateien.

manage-bde -status
manage-bde -unlock E: -rp 111111-222222-333333-444444-555555-666666-777777-888888

Ersetzen Sie E: durch das verschlüsselte Volume und den Beispielschlüssel durch den echten Recovery-Key. Prüfen Sie anschließend erneut mit manage-bde -status, ob das Volume entsperrt ist.

Datenrettung mit Robocopy: Benutzerprofile strukturiert sichern

Für eine schnelle Dateisicherung ist robocopy robuster als Drag-and-drop im Explorer, weil es Wiederholungen, Protokolle und definierte Kopieroptionen unterstützt. Kopieren Sie nicht blind von C:\Users. Verwenden Sie den Laufwerksbuchstaben, auf dem Sie den echten Windows-Ordner gefunden haben.

robocopy "E:\Users" "F:\Export\Users" /E /COPY:DAT /DCOPY:DAT /R:2 /W:2 /XJ /TEE /LOG:"F:\Export\Logs\robocopy-users.log"

/E kopiert Unterordner einschließlich leerer Ordner. /COPY:DAT übernimmt Daten, Attribute und Zeitstempel, aber keine Besitzer- oder ACL-Informationen. /XJ überspringt Junctions und vermeidet typische Kopierschleifen in Benutzerprofilen. /LOG schreibt ein Protokoll, das Sie nach dem Lauf prüfen sollten.

Dateisystem und Systemdateien prüfen: erst diagnostisch, dann reparierend

Nutzen Sie zuerst möglichst schonende Prüfungen. Ein Dateisystemfehler, ein defekter Datenträger oder ein beschädigter Komponentenstore erfordern unterschiedliche Maßnahmen. Wenn Sie sofort schreibend reparieren, können Sie einen instabilen Datenträger zusätzlich belasten.

chkdsk E: /scan
sfc /scannow /offbootdir=E:\ /offwindir=E:\Windows
Dism /Image:E:\ /Cleanup-Image /RestoreHealth

Ersetzen Sie E: durch die tatsächlich gefundene Windows-Partition. Bei DISM kann eine passende Quelle erforderlich sein, wenn der Komponentenstore stark beschädigt ist. Die Quelle muss zur installierten Windows-Version und Edition passen; eine beliebige ISO ist dafür nicht zuverlässig genug.

Startreparatur bei UEFI-Systemen: ESP und Windows-Pfad sicher zuordnen

Bei modernen UEFI-Systemen ist bcdboot oft der sauberste Weg, Bootdateien neu zu schreiben, sofern die Windows-Installation intakt ist. Führen Sie den Befehl aber erst aus, wenn zwei Dinge eindeutig feststehen: der richtige Windows-Pfad und die richtige EFI-Systempartition. Sonst schreiben Sie Bootdateien an die falsche Stelle oder beschädigen eine Mehrfachboot-Konfiguration.

dir C:\Windows
dir D:\Windows
dir E:\Windows

diskpart
list disk
sel disk 0
list partition
list volume
exit

Binden Sie die EFI-Systempartition bewusst ein. Auf vielen Systemen funktioniert dafür:

mountvol S: /S
dir S:\EFI

Schreiben Sie die Bootdateien erst, wenn S: wirklich die EFI-Systempartition ist und der Windows-Ordner eindeutig gefunden wurde. Im Beispiel liegt Windows auf E::

bcdboot E:\Windows /s S: /f UEFI /l de-de
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all

bootrec kann in bestimmten Szenarien weiterhin nützlich sein, ist bei aktuellen UEFI-Installationen aber nicht automatisch der erste oder beste Reparaturweg. Arbeiten Sie bei UEFI-Systemen bevorzugt mit korrekt eingebundener ESP und explizitem bcdboot-Ziel.

Offline-Malwareprüfung: nur mit getesteten Werkzeugen

Offline-Scans können hilfreich sein, weil Schadsoftware im gestarteten Zielsystem nicht aktiv eingreifen kann. Verlassen Sie sich aber nicht darauf, dass Microsoft Defender oder ein anderes Antimalware-Werkzeug in jeder selbstgebauten WinPE-Umgebung vollständig verfügbar ist. Prüfen Sie vorab, ob das Werkzeug startet, welche Signaturen vorhanden sind, ob Netzwerkupdates funktionieren und wohin Funde protokolliert werden.

Löschen Sie verdächtige Dateien nicht vorschnell. Bei kritischen Vorfällen sichern Sie Artefakte, Pfade, Zeitstempel und Logs zuerst, damit eine spätere Analyse möglich bleibt. Quarantäne oder Entfernung ist ein bewusster Reparaturschritt, nicht die erste Diagnosehandlung.

Notfall-Windows pflegen: Updates, Treiberstände und Testläufe versionieren

Ein Notfall-Windows altert. Neue Notebook-Plattformen, NVMe-Controller, VMD/RST-Konfigurationen, USB-C-Docks, LAN-Chips und Sicherheitswerkzeuge können Anpassungen erfordern. Pflege bedeutet aber nicht, ständig neue Tools aufzunehmen. Aktualisieren Sie gezielt, dokumentieren Sie jede Änderung und testen Sie danach denselben Standardablauf wie beim ersten Bau.

Versionen sauber benennen und alte Stände nicht sofort löschen

Benennen Sie jede freigegebene Version eindeutig, etwa Notfall-Windows-2026-06. Notieren Sie ADK-Version, WinPE-Add-on, integrierte Treiber, Toolstände und Testdatum. Behalten Sie mindestens eine funktionierende Vorgängerversion, bis die neue Version auf Ihrer Testmatrix bestanden hat. So können Sie zurückgehen, wenn ein neuer Treiber ein Gerät unterstützt, aber ein anderes stört.

Standardtest nach jeder Änderung

Nach jeder Änderung am Image oder am Toolordner durchläuft das Medium denselben Mindesttest. Führen Sie den Test nicht nur in einer virtuellen Maschine aus. Eine VM erkennt viele reale Probleme mit Secure Boot, USB, Docks, WLAN, VMD/RST oder externen Datenträgern nicht.

• Starten Sie den Stick auf einem UEFI-System mit aktivem Secure Boot.
• Prüfen Sie mit diskpart, ob interne Laufwerke und externe Zielmedien sichtbar sind.
• Prüfen Sie mit ipconfig /all, ob der geplante LAN- oder Docking-Adapter funktioniert.
• Prüfen Sie mit manage-bde -status, ob BitLocker-Volumes korrekt erkannt werden.
• Führen Sie einen kleinen robocopy-Testlauf auf ein externes Ziel mit Logdatei aus.
• Starten Sie zentrale Zusatztools direkt aus dem WinPE und prüfen Sie, ob sie ohne Installer laufen.

diskpart
list disk
list volume
exit
ipconfig /all
manage-bde -status

Einsatzprotokoll: im Notfall nachvollziehbar arbeiten

Dokumentieren Sie jeden realen Einsatz. Notieren Sie Ausgangslage, Gerät, Firmwaremodus, Secure-Boot-Status, erkannte Datenträger, BitLocker-Status, durchgeführte Schritte, Logpfade und Ergebnis. Das klingt formal, verhindert aber Wiederholungsfehler und macht sichtbar, welche Treiber oder Werkzeuge im nächsten Release ergänzt werden müssen.

md F:\Export\Logs
notepad F:\Export\Logs\einsatzprotokoll.txt
robocopy "E:\Users" "F:\Export\Users" /E /COPY:DAT /DCOPY:DAT /R:2 /W:2 /XJ /TEE /LOG:"F:\Export\Logs\robocopy-users.log"

Ein gutes Notfall-Windows ist kein einmal gebastelter USB-Stick, sondern ein gepflegtes Werkzeug. Bauen Sie es in kleinen Schritten, testen Sie jeden Schritt auf echter Hardware und dokumentieren Sie jede Änderung. So haben Sie im Ernstfall nicht nur ein startfähiges Medium, sondern einen überprüften Ablauf für Diagnose, Reparatur und Datenrettung.