Windows: Falsches Datenträger-Layout bringt Ärger bei Updates und Feature-Upgrades

[English]Stimmt das Datenträgerlayout bei Windows-Maschinen nicht mit den Microsoft-Vorgaben überein, kann das schnell Ärger geben. Bei der Update-Installation kommt es zu Rollbacks und die Installation der Feature-Updates scheitert an einer Fehlermeldung. Hier eine Zusammenfassung, was man beachten und wissen sollte.

Blog-Leser Martin Feuerstein hat mich Mitte November 2020 per Mail kontaktiert und über zwei Problemfälle bei der Installation von Updates und Funktionsupdates berichtet. Beide ließen sich auf das Partitionslayout (verursacht beim Wechsel vom BIOS- zum UEFI-Boot) zurückführen.

• Beim ersten Fall schrieb Martin: hab die Tage einen Fall bearbeitet, bei dem ein älterer Laptop (offiziell nicht mal für Win10 unterstützt) Probleme beim Feature-Update von 1809 auf 1909 hatte. Ursache: Partitionslayout (installiert für MBR – aber das BIOS unterstützt doch UEFI).
• Zwei Tage danach ein schon länger schwelendes Problem mit regulären Windows-Updates an zwei Servern (2012 R2 und 2016) gelöst. Ursache: Partitionslayout (UEFI). Die Server wurden vorher von ESX auf Hyper-V migriert.

Also unterschiedliche Probleme, aber gleiche Ursache. Lösung ist eigentlich „nur" die Umsetzung von einem – immerhin bootfähigen – MBR-Layout  zu einem UEFI-konformen Layout. In der Theorie gibt's da schon Werkzeuge (MBR2GPT, GPTGen) für eine geschmeidige Umsetzung, in der Praxis hat aber nur die Keule (Backup + Partitionen löschen + Wiederherstellen) funktioniert.

Fall 1: Das Setup steigt beim Upgrade aus

Beim ersten Fall sollte ein Notebook von Windows 10 Version 1809 auf eine neuere Windows 10-Build aktualisiert werden. Das Notebook ist ein Fujitsu Lifebook E752, ist ca. 8 Jahre alt. Im BIOS/UEFI gibt es keine Einstellmöglichkeiten bzgl. Secure Boot oder CSM (Compatibility Support Module). Beim Windows-Start wird, wie bei anderen Nicht-UEFI-Geräten, die Windows-Flagge eingeblendet und kein Hersteller-Logo, wie es bei UEFI üblich wäre. Kein Hinweis auf UEFI.

Problem bei diesem Gerät ist, dass das Setup bereits beim Start den Fehler Windows kann nicht installiert werden, weil dieser PC ein nicht unterstütztes Datenträgerlayout für die UEFI-Firmware aufweist meldet.

Was ist die Ursache? Das Partitionslayout ist nicht wie aus dem Microsoft-Handbuch angelegt. Hier die Auflistung der Daten in der Eingabeaufforderung.

Ein eigentlich offensichtliches Problem aber ärgerlich, weil dort ja ein Windows 10 läuft und nur ein Upgrade ausgeführt werden soll. Die Lösung: Das Layout der Festplatte auf die Anforderungen Microsofts umstellen und dann installieren.

Fall 2: Windows-Server rollen Updates zurück

Der zweite Fall betraf zwei Windows-Server, eine VM mit Server 2012 R2, eine VM mit Server 2016. Diese rollen nach der Installation die kumulativen Updates in der Boot-Phase zurück, während andere Updates (z. B. Office) ohne Fehlermeldung installiert werden. Die VMs wurden zuvor von VMWare ESX zu Hyper-V migriert. Andere Server in derselben Domäne zeigen keine Auffälligkeiten, bis vor der Migration gab es auch mit den Updates keine Probleme.

Im Eventlog kein Hinweis auf einen Fehler, abgesehen davon, dass die Updates nicht installiert werden können. Ein Fehler zeigt sich aber in den CBS-Logs (Component-Based Servicing) in c:\Windows\Logs\CBS, dass die Boot-Partition nicht gefunden wurde:

(CBS-Log, Zum Vergrößern klicken)

In der Log-Datei finden sich Einträge der Art:

Microsoft-Windows-BootEnvironment-Core-BootManager-PCAT
Installer name: 'Boot File Servicing (BFSVC) Installer'
BFSVC: 'Failed to get system partition! Last Error = 0x3bc3'
Boot File Servicing (BFSVC) Installer ({c5f0e9d7-e844-4507-89e4-701b5a747221}) with HRESULT HRESULT_FROM_WIN32(15299)

Damit war klar, dass auch hier das Partitionslayout mit reinspielt. Martin schreibt:

Die VMs wurden vorher vorher als BIOS-Maschine mit MBR-Layout betrieben, nach der Konvertierung aber als Gen2/UEFI-VM unter Hyper-V. Der Einfachheit halber wurde auf einen MBR-Datenträger eine FAT32-Partition für den Bootloader geschrieben und das Betriebssystem auf eine NTFS-Partition.

Hintergrundwissen zum Partitionslayout

Früher wurde das MBR-Layout als Standard für Festplatten definiert – d.h. auf einem Datenträger können bis zu vier primäre Partitionen angelegt werden, die Boot-Partition (die Partition mit dem Boot-Manager) wird „aktiv" gesetzt. Funktioniert so seit der Markteinführung von MS-DOS. Um mehr als die vorgesehenen vier Partitionen pro Datenträger anzulegen, kann eine erweiterte Partition eingerichtet werden, die ihrerseits logische Partition enthält.

• Klassische BIOS-Installation mit Windows Vista aufwärts mit MBR-Datenträger-Layout sehen so aus: Es wird eine Partition für den Boot-Manager angelegt, diese wird aktiv gesetzt, das Betriebssystem wird auf eine separate Partition installiert. Bei BIOS-Installationen kann die Boot-Partition wahlweise mit FAT32 oder NTFS formatiert sein, dem BIOS ist das egal. Die Windows-Partition muss mit NTFS formatiert sein (ob durch die Vista/7-Installation nun eine NTFS- oder FAT32-Partition angelegt wurde weiß ich heute auch nicht mehr).
• UEFI-Installation: Es wird eine Partition für den Boot-Manager angelegt, diese *muss* mit FAT32 formatiert sein, sonst kann das UEFI den Boot-Manager nicht starten. Die Betriebssystem-Partition ist wie für Windows üblich mit NTFS formatiert. UEFI ist dabei für die Verwendung mit einem GPT-Datenträger-Layout vorgesehen, das keine aktiv gesetzte Partition kennt – Im UEFI wird durch das Betriebssystem der Pfad zum Boot-Manager auf einer FAT32-Partition eingetragen. Das Auslesen des Boot-Managers aus der ersten FAT32-Partition ist m.M.n eher als Fallback-Lösung zu betrachten.

Windows startet, unabhängig ob nun ein BIOS oder UEFI (mit oder ohne CSM) vorliegt, sofern der Boot-Manager von einer Partition gelesen werden kann. Für das BIOS (MBR-Layout) ist die aktive gesetzte Partition maßgeblich, für UEFI der eingetragene Pfad zum Boot-Manager. Alternativ lädt UEFI auch Boot-Loader von einer FAT32-Partition, ohne dass diese im UEFI eingetragen ist.

Mit einem MBR-Layout, der FAT32-Boot-Partition (für MBR aktiv gesetzt) und der Betriebssystem-Partition haben wir nun also einen Datenträger, der prinzipiell auf einem BIOS-Computer und einem UEFI-Computer starten kann. Also alles bestens, oder nicht?

BCD-Einträge mit bcdboot reparieren, Zum Vergrößern klicken

Hinweis: Bei der Einrichtung des Boot-Managers mittels BCDBoot kann angegeben werden, welche Boot-Methode eingerichtet werden soll: entweder BIOS (/f BIOS), UEFI (/f UEFI) oder ein Hybrid (/f ALL), der beides kann.

Ausweg für die Update- und Feature-Update-Installation

Martin schrieb mir dazu: Grundlegend muss das Datenträgerlayout für den UEFI-Boot auf GPT umgestellt werden und ein entsprechender Boot-Manager geschrieben werden. Die Windows-Datenträgerverwaltung lässt die nachträgliche Konvertierung des Systemdatenträgers nicht zu, der Datenträger müsste also erst mit dem GPT-Layout neu initalisiert und das Betriebssystem neu installiert werden.

Für die Konvertierung gibt es aber z. B. das Bordmittel MBR2GPT (hat bei mir nicht funktioniert) oder GPTGen (hat auch nicht funktioniert, oder ich habe nicht die richtigen Parameter verwendet). Andere Partitionierungsprogramme (meist kostenpflichtig, zumindest für Geschäftskunden) mögen die MBR-GPT-Partitionierung beherrschen, diese habe ich aber nicht ausprobiert.

Martin hat dann folgende Lösungsschritte ausgeführt:

1. Betriebssystempartition sichern

Dies kann zum Beispiel mit DISM, also einem Bordmittel von Microsoft, in einer Wiederherstellungsumgebung geschehen

DISM /Capture-Image /CaptureDir:"c:\" /ImageFile:"d:\os.wim" /Name:"Betriebssystem"

Für zusätzliche Partitionen auf dem Datenträger muss DISM entsprechend nochmal ausgeführt werden

2. Datenträger neu initialisieren

Der Datenträger wird entsprechend diesem MS-Dokument neu initialisiert: Im Folgenden wird von diesen Laufwerksbuchstaben ausgegangen:

c:\ – Betriebssystem-Partition
d:\ – Datenträger, der die Sicherung des Betriebssystems enthält
z:\ – Boot-Partition

3. Betriebssystem wiederherstellen und Boot-Manager erstellen

Das Betriebssystem wird auf die neu eingerichtete Partition wiederhergestellt

DISM /Apply-Image /ImageFile:"d:\os.wim" /Index:1 /ApplyDir:c:\

Anschließend wird der Boot-Manager auf den neu initialisierten Datenträger geschrieben, um das Betriebssystem bootfähig zu machen:

BCDBoot c:\windows /l de-de /s z:\ /f UEFI

Nach diesen Schritten sollte das System dann wieder wie gewohnt Updates oder Funktionsupdates installieren können. Danke an Martin für die Aufbereitung dieses Sachverhalts. Vielleicht hilft es mal jemanden weiter.