„Windows kann auf diesem Datenträger nicht installiert werden“: Ursachen bei GPT/MBR und UEFI/BIOS sowie Migration ohne Datenverlust

Die Meldung „Windows kann auf diesem Datenträger nicht installiert werden“ tritt häufig auf, wenn Firmware-Bootmodus und Partitionsschema nicht zusammenpassen oder wenn Installationsreste, inkonsistente Partitionstabellen oder mehrere angeschlossene Datenträger das Windows-Setup in eine falsche Zielauswahl treiben. In der Praxis betrifft das vor allem Systeme, die von älteren BIOS/MBR-Installationen auf UEFI/GPT umgestellt werden, etwa nach einem Mainboard-Wechsel, beim Umzug auf eine SSD/NVMe oder beim Wechsel auf Windows-Versionen, die bestimmte Firmware- und Sicherheitsfunktionen voraussetzen.

Zusätzlich verschärfen Secure Boot, BitLocker, OEM-Partitionen und herstellerspezifische Recovery-Layouts die Situation, weil sie die Partitionsstruktur und den Bootpfad beeinflussen. Entscheidend ist, die technische Ursache eindeutig zu bestimmen, bevor Maßnahmen wie Neuinitialisierung oder Konvertierung greifen, da falsche Schritte schnell zu nicht bootfähigen Systemen, Datenverlust oder schwer reparierbaren Boot-Konfigurationen führen.

Boot-Architektur verstehen: BIOS vs. UEFI, CSM, GPT vs. MBR, EFI-Systempartition und Abhängigkeiten

Die Fehlermeldung „Windows kann auf diesem Datenträger nicht installiert werden“ ist selten ein „Setup-Problem“, sondern fast immer ein Architektur-Mismatch: Firmware-Modus (BIOS/UEFI) und Partitionsschema (MBR/GPT) passen nicht zueinander oder die für den Bootvorgang nötigen Strukturen fehlen bzw. sind widersprüchlich. Eine saubere Einordnung erfordert, den Bootpfad moderner PCs (Firmware → Bootloader → Betriebssystem) und die Rolle der Partitionstabelle zu verstehen.

BIOS (Legacy) vs. UEFI: Was sich im Bootprozess technisch unterscheidet

Das klassische BIOS (Legacy) lädt den Bootcode aus dem ersten Sektor eines Datenträgers (Master Boot Record). Dieser Sektor enthält sowohl Partitionstabelle (MBR) als auch einen sehr kleinen Bootloader-Starter, der dann den weiteren Bootloader aus einer „aktiven“ primären Partition nachlädt. Grenzen: Der Bootpfad ist stark an den MBR gebunden, Erweiterungen sind historisch gewachsen, und Funktionen wie Secure Boot sind nicht Teil des Konzepts.

UEFI ist die moderne Firmware-Schnittstelle. Sie bootet nicht über „aktiven“ Partition-Bootcode, sondern lädt ausführbare Dateien im PE-Format (typisch \EFI\Microsoft\Boot\bootmgfw.efi) von einer speziellen FAT32-Partition, der EFI-Systempartition (ESP). Bootoptionen werden in NVRAM-Einträgen verwaltet; dadurch ist der Bootprozess unabhängiger von legacy-spezifischen Mechanismen und kompatibel mit Sicherheitsfunktionen wie Secure Boot.

• Legacy-Bootkette: Firmware (BIOS) → MBR-Bootcode → Volume Boot Record der aktiven Partition → Windows Boot Manager (z. B. \bootmgr) → BCD → Windows
• UEFI-Bootkette: Firmware (UEFI) → NVRAM-Bootoption → ESP (FAT32) → Windows Boot Manager (z. B. \EFI\Microsoft\Boot\bootmgfw.efi) → BCD → Windows
• Praktische Konsequenz: Ein Windows, das im UEFI-Modus installiert wurde, erwartet typischerweise eine ESP auf einem GPT-Datenträger; ein im Legacy-Modus installiertes Windows erwartet bootfähige Strukturen gemäß MBR/„aktive Partition“.

CSM (Compatibility Support Module): Brückentechnik mit Nebenwirkungen

Das CSM ist eine UEFI-Funktion, die Legacy-BIOS-Verhalten emuliert, um alte Betriebssysteme oder Bootloader zu starten. In der Praxis führt CSM häufig zu Installationsabbrüchen, weil das Setup abhängig von der Bootart des Installationsmediums entscheidet, welches Partitionsschema zulässig ist. Wird ein USB-Stick im Legacy/CSM-Modus gebootet, versucht Windows Setup entsprechend im BIOS-Modus zu installieren – und fordert MBR. Wird derselbe Stick im UEFI-Modus gebootet, fordert Setup GPT.

Besonders tückisch: Viele Mainboards zeigen im Bootmenü zwei Einträge für denselben Stick, etwa einmal mit Präfix „UEFI:“ und einmal ohne. Die Auswahl dieses Eintrags entscheidet über den Firmware-Modus der laufenden Setup-Umgebung – und damit über die Kompatibilitätsprüfung, die hinter der bekannten Fehlermeldung steht.

MBR vs. GPT: Partitionstabellen, Grenzen und Integrität

MBR (Master Boot Record) ist das klassische Partitionsschema. Es unterstützt maximal vier primäre Partitionen (oder drei plus eine erweiterte Partition mit logischen Laufwerken) und adressiert Datenträgergrößen nur bis rund 2 TiB (bei 512-Byte-Sektoren; die Praxis hängt von der tatsächlichen Sektorgröße und Emulation ab). Zudem ist die Partitionstabelle nur einmal vorhanden; Fehler im MBR können den Zugriff auf Partitionen erheblich erschweren.

GPT (GUID Partition Table) ist Teil des UEFI-Ökosystems und löst diese Einschränkungen: Es erlaubt sehr viele Partitionen (Windows typischerweise bis 128 ohne manuelle Anpassungen) und unterstützt große Datenträger. GPT speichert Redundanz (Header und Partitionseinträge am Anfang und am Ende des Datenträgers) und verwendet Prüfsummen (CRC32) zur Konsistenzprüfung. Zur Abwärtskompatibilität existiert ein „protective MBR“, der Legacy-Tools davon abhalten soll, GPT irrtümlich zu überschreiben.

EFI-Systempartition (ESP) und MSR: Welche Partitionen Windows im UEFI/GPT-Betrieb benötigt

Im UEFI/GPT-Betrieb liegt der Windows-Bootmanager auf der EFI-Systempartition. Diese Partition ist FAT32 formatiert, enthält üblicherweise den Ordner \EFI\Microsoft\Boot und wird von Windows als Systempartition genutzt, ohne einen Laufwerksbuchstaben zu erhalten. Daneben existiert auf GPT-Datenträgern meist eine Microsoft Reserved Partition (MSR). Die MSR dient Windows als Platzhalter für interne Verwaltungsaufgaben (z. B. spätere Metadaten-/Partitionierungsoperationen) und ist nicht formatiert.

Wichtig: Die ESP ist kein „optional schöner“ Zusatz, sondern ein funktionaler Bestandteil des Bootpfads. Fehlt sie, ist sie zu klein, falsch formatiert (nicht FAT32) oder liegt sie auf einem anderen Datenträger als erwartet, entstehen Bootprobleme oder Setup bricht ab, weil es keine konsistente Zielarchitektur herstellen kann. In der Praxis lohnt es sich, die ESP nicht knapp zu dimensionieren: Wenn Bootdateien und Update-Artefakte später wachsen, erzeugt eine zu kleine ESP unnötige Upgrade- und Reparaturrisiken.

• ESP (EFI-Systempartition): FAT32, ohne Laufwerksbuchstaben; enthält UEFI-Bootdateien wie \EFI\Microsoft\Boot\bootmgfw.efi.
• MSR (Microsoft Reserved): nicht formatiert; dient Windows als Reservierungsbereich auf GPT-Datenträgern.
• Windows-Partition: NTFS; enthält \Windows, Programme und Daten.
• Recovery-Partition (WinRE): typischerweise NTFS; enthält die Windows-Wiederherstellungsumgebung, relevant für Reparatur/Reset/BitLocker-Wiederherstellung.

Abhängigkeiten: Welche Kombinationen funktionieren – und warum Windows Setup sonst abbricht

Windows Setup richtet sich nach dem aktuell gebooteten Firmware-Modus des Installationsmediums. Im UEFI-Modus erwartet Setup ein GPT-Ziel (bzw. versucht, eines herzustellen). Im Legacy/CSM-Modus erwartet Setup MBR, weil der Bootcode und die „aktive Partition“-Logik dort verankert sind. Daraus ergeben sich die typischen, scheinbar widersprüchlichen Hinweise wie „Der ausgewählte Datenträger entspricht dem GPT-Partitionsstil“ oder „Auf EFI-Systemen kann Windows nur auf GPT-Datenträgern installiert werden“.

Zusätzlich spielen Mehrdatenträger-Szenarien hinein: Windows legt Bootdateien bevorzugt dort ab, wo Setup eine geeignete Systempartition (ESP/„System Reserved“) erkennt und wo die Firmware die Bootrolle plausibel zulässt. Ist bereits eine alte ESP/„System Reserved“-Partition vorhanden oder ist ein Datenträger für die Systemrolle ungeeignet (z. B. falsches Schema, offline, dynamisch), entstehen inkonsistente Zustände. Für eine reproduzierbare Installation muss daher klar sein, welcher Datenträger die Systemrolle (ESP/Bootmanager) und welcher die Datenrolle übernimmt.

Windows-Setup-Fehlermeldungen sauber einordnen: Bootmodus, Partitionsschema, Installationsreste, Datenträger- und Controller-Konflikte

Viele Abbrüche im Windows-Setup wirken auf den ersten Blick zufällig, sind aber in der Regel eindeutig einer von wenigen Klassen zuzuordnen: Firmware-Bootmodus passt nicht zum Partitionsschema, der Datenträger enthält widersprüchliche Metadaten, es existieren Reste früherer Installationen, oder mehrere Datenträger/Controller führen dazu, dass Setup Bootdateien auf dem „falschen“ Laufwerk anlegt. Eine saubere Einordnung reduziert die Fehlerbehebung auf wenige, reproduzierbare Prüfungen.

Bootmodus vs. Partitionsschema: typische Meldungen und die eindeutige Ursache

Windows-Setup prüft nicht nur, ob der Ziel-Datenträger grundsätzlich beschreibbar ist, sondern ob der aktuelle Bootpfad zur Partitionstabelle passt. UEFI erwartet für eine Standardinstallation einen GPT-Datenträger mit EFI-Systempartition (ESP). Im Legacy-/CSM-Modus erwartet Setup dagegen MBR. Wird von einem Installationsmedium im „falschen“ Modus gebootet (z. B. USB-Stick einmal als UEFI: … und einmal ohne UEFI-Präfix auswählbar), entstehen die bekanntesten Fehltexte.

• „Windows kann auf diesem Datenträger nicht installiert werden. Der ausgewählte Datenträger enthält eine MBR-Partitionstabelle“: Setup läuft im UEFI-Modus, der Zieldatenträger ist MBR; Lösung ist entweder UEFI→GPT (z. B. Konvertierung) oder konsequent Legacy/CSM booten (nur wenn das System das langfristig tatsächlich soll).
• „Windows kann auf diesem Datenträger nicht installiert werden. Der ausgewählte Datenträger hat einen GPT-Partitionsstil“: Setup läuft im Legacy-/CSM-Modus, der Zieldatenträger ist GPT; Ursache ist fast immer der falsche Boot-Eintrag des Installationsmediums (nicht UEFI:… gewählt) oder aktiviertes CSM.
• „Auf dem Datenträger konnte keine neue Partition erstellt oder eine vorhandene Partition gefunden werden“: häufig Folge eines Modus-/Schema-Mismatches, kann aber auch auftreten, wenn Setup keine geeignete Systempartition anlegen darf (z. B. durch gesperrte/geschützte Partitionen, inkonsistente Datenträgersignaturen oder Mehrplatten-Konstellationen).

Inkonsistente Partitionstabellen und Metadaten: wenn GPT/MBR „nicht sauber“ ist

Ein Datenträger kann formal als GPT oder MBR erkannt werden und dennoch intern widersprüchlich sein. Typisch sind Reste alter Layouts (z. B. „protective MBR“ ohne konsistente GPT-Header, oder alte dynamische Datenträger-/Storage-Spaces-Metadaten), fehlerhafte Offsets nach Klonvorgängen sowie nicht bereinigte Signaturen bei mehrfach verwendeten SSDs. Setup reagiert dann oft mit unklaren Partitionierungsfehlern oder der Unfähigkeit, Systempartitionen anzulegen.

• Symptom: Setup zeigt Partitionen „doppelt“ oder Größen wirken falsch: häufig inkonsistente GPT-Header/Backup-Header oder Reste von OEM-/Recovery-Layouts nach Imaging; Diagnose außerhalb von Setup ist belastbarer (z. B. diskpart mit list disk, list partition).
• Symptom: „Datenträger ist schreibgeschützt“ bzw. Partitionen lassen sich nicht löschen: möglich sind gesetzte Schreibschutz-Flags, SAN-Policies oder Controller-/Treiberprobleme; Prüfpunkte sind diskpart mit attributes disk und ggf. attributes disk clear readonly (nur wenn der Schreibschutz nicht hardwareseitig ist).
• Symptom: Setup bricht nach dem Kopieren ab oder findet nach Neustart das System nicht: Bootdateien wurden auf einen anderen Datenträger geschrieben oder die Firmware bootet weiter vom falschen Gerät; Mehrplatten-Konflikte sind hier häufig wahrscheinlicher als ein defektes Installationsmedium.

Installationsreste: alte EFI-/Recovery-Partitionen und widersprüchliche Boot-Einträge

Besonders bei wiederholten Installationsversuchen oder nach einem Wechsel zwischen Legacy und UEFI bleiben häufig Bootfragmente zurück: eine alte EFI-Systempartition auf einem anderen Laufwerk, ein liegengebliebener \EFI\Microsoft\Boot-Ordner oder mehrere BCD-Stores. Setup kann dann zwar Windows installieren, legt die Startumgebung aber nicht dort ab, wo sie erwartet wird. Das Problem zeigt sich oft erst nach dem ersten Neustart, wenn die Firmware einen anderen Datenträger priorisiert.

• Erkennungsmerkmal: „Systemreserviert“/EFI liegt auf einem anderen Datenträger als C:: typischer Effekt früherer Mehrplatten-Installationen; Windows startet nur, solange der „falsche“ Datenträger angeschlossen bleibt.
• Erkennungsmerkmal: mehrere UEFI-Bootoptionen für „Windows Boot Manager“: Firmware hat Einträge für verschiedene ESPs; bei Datenträgerwechsel oder BIOS-Reset startet dann das falsche Windows oder gar keines.
• Pragmatische Abhilfe bei Neuinstallation: während der Installation nur den Ziel-Datenträger angeschlossen lassen; so erzwingt Setup, dass ESP/MSR/Recovery auf dem vorgesehenen Laufwerk entstehen.

Mehrere Datenträger: warum Setup „die falsche Platte“ für Bootdateien auswählt

Windows-Setup folgt bei der Platzierung von Bootdateien nicht immer der intuitiven Erwartung „Systempartition auf demselben Datenträger wie Windows“. In der Praxis entscheidet eine Kombination aus Firmware-Bootlogik, Datenträgerreihenfolge und vorhandenen, wiederverwendbaren Systempartitionen. Liegt beispielsweise bereits eine nutzbare ESP auf einem anderen Datenträger, kann Setup diese wiederverwenden, auch wenn Windows auf dem Ziel-Datenträger installiert werden soll. Das führt zu Installationen, die beim Entfernen eines scheinbar „unbeteiligten“ Laufwerks nicht mehr booten.

• Best Practice während Setup: alle nicht benötigten SATA/NVMe-Datenträger physisch trennen oder im UEFI/BIOS deaktivieren, bis Windows vollständig installiert und gestartet ist.
• Wenn Trennen nicht möglich ist: Reihenfolge prüfen (Firmware und ggf. Controller-BIOS), und in Setup konsequent nur nicht zugeordneten Speicherplatz auf dem Ziel-Datenträger auswählen, damit Setup seine benötigten Partitionen dort anlegt.
• Diagnose nach einer „schiefen“ Installation: unter Windows prüfen, auf welchem Datenträger die ESP liegt (Datenträgerverwaltung; technisch via mountvol und BCD-Analyse), bevor Datenträger ausgebaut oder neu formatiert werden.

Controller- und Treiberkonflikte: RAID/VMD, AHCI, USB und NVMe

Wenn Datenträger im Setup gar nicht erscheinen oder Installationen mit I/O-Fehlern abbrechen, liegt die Ursache oft nicht in GPT/MBR, sondern in der Storage-Anbindung. Typisch sind aktivierte RAID-/VMD-Modi (z. B. Intel RST/Intel VMD), für die im Setup ein Treiber fehlt, oder eine Umstellung zwischen AHCI und RAID, die ein bereits vorhandenes Windows ohne vorbereitete Treiber nicht mehr starten lässt. Auch USB-Installationsmedien an problematischen Ports (manche Frontpanel-Hubs) können zu sporadischen Leseabbrüchen führen, die als Datenträgerproblem missverstanden werden.

Klassiker bei Intel-Plattformen: Ist im UEFI/BIOS VMD oder Intel RST (IRST) aktiv, erkennt Windows Setup NVMe-SSDs oder RAID-Volumes in der Laufwerksauswahl oft nicht – es wirkt dann so, als sei „keine SSD verbaut“. In diesem Fall ist eine Konvertierung (GPT/MBR) der falsche Reflex: Es fehlt schlicht der passende Storage-Treiber für den Controller-Modus.

• Symptom sicher erkennen: Im Schritt „Wo möchten Sie Windows installieren?“ erscheint keine interne SSD/HDD, obwohl sie im UEFI/BIOS sichtbar ist → hoher Treffer für RST/VMD/RAID-Treiberproblem.
• Lösung im Setup: „Treiber laden“ wählen und den passenden Intel RST/RSTe/VMD (F6)-Treiber von einem zweiten USB-Stick nachladen; anschließend taucht das Laufwerk/Array in der Liste auf und kann normal partitioniert werden.
• Treiberquelle (Best Practice): In der Regel bietet der Fertiggerätehersteller (OEM) den korrekten IRST/VMD-Treiber modellbezogen auf der Support-Seite an (weil BIOS-Optionen, Controller-Modus und Paketvarianten zusammenpassen müssen). Alternativ stellt Intel IRST-Pakete für bestimmte Plattformgenerationen bereit; entscheidend ist, dass der Treiber zum Controller-Modus (VMD vs. ohne VMD) und zur Plattform passt.
• Praxisdetail: Manche IRST-Downloads liegen als Installer vor; für „Treiber laden“ im Setup braucht es die extrahierten Treiberdateien (INF/ SYS/ CAT). OEM-Pakete liefern diese oft direkt als „F6“-Archiv; andernfalls muss das Paket vorab entpackt werden, bevor Windows Setup es akzeptiert.
• „Laufwerke werden nicht angezeigt“: häufig fehlender Storage-Treiber; im Setup „Treiber laden“ verwenden und herstellerspezifische INF-Pakete bereitstellen (z. B. für RST/VMD), statt blind zu konvertieren oder zu löschen.
• „Windows kann auf diesem Laufwerk nicht installiert werden“ bei NVMe hinter Add-on-Controller: im UEFI muss Boot von NVMe/PCIe-Storage unterstützt und aktiviert sein; bei älterer Firmware ist das ein Hard-Limit und kein Partitionierungsproblem.
• Abbrüche beim Kopieren/Expandieren: Installationsmedium an einem anderen Port testen (direkt am Mainboard), zusätzlich Integrität des ISO/USB-Sticks prüfen; wiederholbare Fehler an derselben Prozentzahl deuten eher auf Lesefehler als auf GPT/MBR.

MBR→GPT ohne Neuinstallation: mbr2gpt reproduzierbar anwenden (Voraussetzungen, Checks, Secure Boot/BitLocker, OEM-Layouts, Mehrdatenträger, Fehlerbehebung) und wann stattdessen eine strukturierte Neuinstallation nötig ist

mbr2gpt.exe ist das von Microsoft bereitgestellte Offline-/Online-Migrationswerkzeug, um einen Systemdatenträger von MBR nach GPT zu konvertieren, ohne Windows neu zu installieren. Dabei werden (falls möglich) eine EFI-Systempartition (ESP) und die erforderlichen UEFI-Bootdateien angelegt, die vorhandenen Windows-Partitionen bleiben grundsätzlich erhalten. Entscheidend für einen reproduzierbaren Ablauf ist, die Vorbedingungen vorab sauber zu prüfen, Störquellen (BitLocker, Mehrdatenträger, ungünstige Partitionlayouts) zu kontrollieren und nach der Konvertierung den Firmware-Modus konsequent auf UEFI umzustellen.

Vorbedingungen und harte Grenzen (was mbr2gpt kann – und was nicht)

mbr2gpt ist für Windows 10/11 vorgesehen und wird typischerweise aus Windows selbst oder aus der Windows-Wiederherstellungsumgebung (WinRE/Windows Setup) gestartet. Die Konvertierung setzt voraus, dass Windows auf dem zu konvertierenden Datenträger konsistent genug ist, um die Tool-Prüfungen zu bestehen. Außerdem benötigt das Tool freien, zusammenhängenden Platz für die neue EFI-Systempartition, sofern noch keine geeignete ESP existiert. In der Praxis scheitern Konvertierungen meist nicht an GPT an sich, sondern an Partitionierungs-Altlasten (zu viele Partitionen, ungünstige Anordnung, zu wenig freier Platz), an Verschlüsselung oder an Mehrplatten-Konstellationen.

Vorab-Checks: Datenträger identifizieren, Boot-Status prüfen, WinRE bereitstellen

Vor jeder Konvertierung sollten Systemzustand, Datenträgerzuordnung und Boot-Konfiguration eindeutig erfasst werden. Besonders bei mehreren eingebauten Laufwerken ist es wichtig, den tatsächlichen Systemdatenträger (mit Windows-Installation) von Datenträgern zu trennen, auf denen zufällig eine alte „System Reserved“-Partition oder Bootdateien liegen. Ziel ist: genau ein erwartbares Bootlaufwerk, klare Disk-Nummer, keine Überraschungen durch Fremd-ESP oder alte BCD-Reste.

• Datenträger und Partitionsschema prüfen: diskpart
list disk
select disk 0
detail disk
• Windows- und Startmodus verifizieren: msinfo32 (Feld „BIOS-Modus“ zeigt „Vorgängerversion/Legacy“ oder „UEFI“; bei Legacy ist die Konvertierung überhaupt erst relevant).
• WinRE-Status prüfen (für Offline-Szenarien hilfreich): reagentc /info (WinRE aktiviert vereinfacht Reparaturen; bei deaktiviertem WinRE vorab aktivieren, sofern möglich).
• Dateisystem konsistent machen: chkdsk C: /scan (bei Befunden Wartungsfenster einplanen und ggf. chkdsk C: /f mit Neustart).
• Bootdateien-Lage prüfen (Mehrdatenträger-Falle): bcdedit /enum all (Pfad-/Device-Zuordnung plausibilisieren) und unter UEFI zusätzlich bcdedit /enum firmware (Bootoptionen im NVRAM anzeigen).

Wenn erkennbar ist, dass Bootdateien auf einem anderen Datenträger liegen als die Windows-Partition, sollte vor der Konvertierung eine Bereinigung eingeplant werden (z. B. spätere Neu-Erstellung der Bootdateien auf dem Ziel-Datenträger). Andernfalls kann die Konvertierung zwar formal gelingen, der anschließende UEFI-Start aber auf das falsche Laufwerk zeigen.

BitLocker, Secure Boot und Geräteschutz: sauberer Zustand vor der Konvertierung

BitLocker ist ein häufiger Grund für Recovery-Abfragen nach einer erfolgreichen Konvertierung, weil sich Bootpfad und Partitionierung ändern und damit die Messwerte, die das TPM für die Integritätsprüfung heranzieht. Empfohlen ist, BitLocker vor der Konvertierung kontrolliert zu suspendieren (Schutz temporär aussetzen), den Recovery-Key zuverlässig verfügbar zu halten und den Schutz erst wieder zu aktivieren, wenn der erste UEFI-Start stabil gelingt. In verwalteten Umgebungen entscheiden Policies und Key-Management (AD/Azure AD/Intune/MBAM), wie Protectoren zu behandeln sind; deshalb gehört der Recovery-Key organisatorisch vor die Technik.

• BitLocker-Status prüfen: manage-bde -status
• BitLocker für Neustarts aussetzen (typisch): manage-bde -protectors -disable C: (nach erfolgreichem UEFI-Start wieder aktivieren: manage-bde -protectors -enable C:).
• Wiederherstellungsschlüssel sicherstellen: Der Key muss vorab verfügbar sein (z. B. in AD/Azure AD/Intune/MBAM oder sicher abgelegt), falls die Firmware-Umstellung eine Recovery auslöst.
• Secure Boot Reihenfolge: Erst Konvertierung, dann Firmware auf UEFI umstellen und Boot-Eintrag prüfen; Secure Boot anschließend aktivieren, wenn der Start stabil ist und signierte Bootkette verwendet wird.

Schritt-für-Schritt: mbr2gpt validieren, konvertieren, UEFI-Boot herstellen

Für eine reproduzierbare Durchführung empfiehlt sich ein zweistufiges Vorgehen: erst Validierung, dann Konvertierung. Die Validierung zeigt, ob das aktuelle Layout grundsätzlich konvertierbar ist, ohne bereits Änderungen zu schreiben. Die Konvertierung kann aus dem laufenden Windows („Full OS“) oder aus WinPE/Windows Setup erfolgen. In kritischen Fällen (ungewöhnliche Filtertreiber, atypische Controller, instabile Drittsoftware) ist der Offline-Weg stabiler, weil weniger Komponenten eingreifen.

• Validierung (schreibt nichts): mbr2gpt /validate /disk:0 /allowFullOS
• Konvertierung starten: mbr2gpt /convert /disk:0 /allowFullOS
• Firmware umstellen: Nach erfolgreicher Meldung im Tool: im Firmware-Setup CSM/Legacy deaktivieren (sofern möglich) und Bootmodus auf UEFI setzen; anschließend den neuen Windows Boot Manager als erste Boot-Option auswählen.
• Nach dem ersten Start Bootkette prüfen: msinfo32 (BIOS-Modus jetzt „UEFI“), und bei Bedarf BitLocker-Schutz wieder aktivieren: manage-bde -protectors -enable C:.

Wenn das System nach der Konvertierung nicht bootet, liegt die Ursache häufig in der Firmware-Konfiguration (UEFI/CSM-Mischbetrieb, falsche Bootreihenfolge) oder in Bootdateien, die nicht auf dem erwarteten Datenträger liegen. In solchen Fällen sollte zuerst die Firmware-Bootliste bereinigt werden, bevor Partitionen manuell verändert werden.

OEM-Layouts und „zu viele Partitionen“: typische Stolpersteine vor der Konvertierung

Viele OEM-Systeme nutzen mehrere kleine Partitionen (Recovery, Tools, Diagnostics). Auf MBR sind vier primäre Partitionen die harte Grenze – für mbr2gpt ist das jedoch praktisch schon „zu viel“, weil das Tool in der Regel eine zusätzliche ESP anlegt und dafür ein Partitions-Slot frei sein muss. Wenn das Layout bereits dicht ist oder eine erweiterte Partition existiert, bricht die Validierung ab. Eine „schnelle“ Lösung durch Löschen von OEM-Recovery-Partitionen ist technisch möglich, aber nur vertretbar, wenn ein alternatives Recovery-Konzept existiert (z. B. aktuelles Systemabbild, Hersteller-USB, dokumentierter Wiederherstellungsweg). In verwalteten Umgebungen sollte eine Recovery-Strategie vor dem Entfernen von OEM-Partitionen verbindlich geklärt sein.

• Partitionlayout analysieren:
  diskpart
select disk 0
list partition
• Freien Platz für ESP schaffen: Systempartition am Ende verkleinern (Datenträgerverwaltung oder offline via Setup), sodass zusammenhängender, nicht zugeordneter Speicher entsteht; anschließend erneut mbr2gpt /validate.
• OEM-Partitionen nicht „blind“ löschen: Vorher prüfen, ob WinRE verfügbar ist (reagentc /info) und ob ein aktuelles Backup existiert; bei Unternehmensgeräten zusätzlich den Wiederherstellungsprozess (z. B. Autopilot/MDT/SCCM) berücksichtigen.

Mehrdatenträger und externe Medien: Konflikte vermeiden, Bootdateien gezielt platzieren

Bei mehreren internen Datenträgern oder angeschlossenen USB-Laufwerken entstehen die meisten „Phantomfehler“: Bootdateien werden auf dem falschen Laufwerk gesucht, oder die Firmware bevorzugt eine andere EFI-Partition. Für eine planbare Migration sollten nicht benötigte Datenträger nach Möglichkeit vorübergehend getrennt werden (physisch oder im UEFI deaktivieren). Wenn das nicht möglich ist, muss die Bootreihenfolge nach der Konvertierung gezielt auf den Windows Boot Manager des richtigen Laufwerks gesetzt werden.

• USB-/Zweitlaufwerke vorübergehend entfernen: Während Validierung/Konvertierung und beim ersten UEFI-Start keine zusätzlichen Bootmedien angeschlossen lassen, um falsche Bootpfade zu vermeiden.
• Disk-Nummern nicht raten: Vor jedem Lauf diskpart nutzen und den Systemdatenträger eindeutig per Größe/Modell identifizieren (list disk, detail disk).
• Bootreihenfolge prüfen: Nach der Umstellung auf UEFI in der Firmware den Eintrag „Windows Boot Manager“ des Ziel-Datenträgers priorisieren; bei weiterhin falschem Bootlaufwerk die übrigen UEFI-Bootoptionen temporär deaktivieren.

Fehlerbehebung: häufige mbr2gpt-Fehlerbilder und konkrete Reparaturpfade

mbr2gpt protokolliert detailliert; die schnelle Diagnose beginnt mit der Unterscheidung „Validierung scheitert“ vs. „Konvertierung erfolgreich, aber Boot scheitert“. Validierungsfehler weisen meist auf Layout-/Platzprobleme hin. Bootfehler nach erfolgreicher Konvertierung sind typischerweise Firmware- oder BCD/Bootdatei-Probleme. Reparaturen sollten bevorzugt aus der Windows-Wiederherstellungsumgebung erfolgen, um sicherzustellen, dass die EFI-Partition eingebunden und die Startumgebung korrekt adressiert wird.

• Validierung schlägt fehl (Layout/Platz): Erneut Partitionen prüfen (diskpart → list partition), Layoutbedingungen erfüllen (max. 3 primäre, keine erweiterten/logischen), freien Platz schaffen und wiederholen: mbr2gpt /validate /disk:0 /allowFullOS.
• Konvertierung erfolgreich, aber kein UEFI-Boot: Firmware auf reines UEFI stellen (CSM aus), Bootreihenfolge auf „Windows Boot Manager“; wenn weiterhin kein Start: aus WinRE Bootdateien neu schreiben: bcdboot C:\Windows /f UEFI.
• EFI-Partition fehlt/ist nicht nutzbar: In WinRE prüfen, ob eine FAT32-ESP existiert und korrekt erkannt wird (Datenträger-/Partitionsanzeige in diskpart); danach ggf. Bootdateien mit bcdboot erneut erstellen.
• BitLocker-Recovery nach Umstellung: Wiederherstellungsschlüssel eingeben, Windows starten, Schutz gezielt reaktivieren: manage-bde -protectors -enable C:; bei wiederkehrender Recovery Firmware-Einstellungen (TPM/Secure Boot/Bootreihenfolge) stabilisieren.

Wann Konvertierung nicht sinnvoll ist: Kriterien für eine strukturierte Neuinstallation ohne Datenverlust

Eine Konvertierung ist nicht der richtige Weg, wenn die Firmware keinen stabilen UEFI-Betrieb unterstützt, wenn der Datenträger in einem Layout steckt, das nur mit riskanten Eingriffen (OEM-/Recovery-Partitionen ohne Backup/Recovery-Plan) konvertierbar wäre, oder wenn der Ist-Zustand bereits technische Schulden trägt (mehrfach „reparierte“ Bootstrukturen, gemischte Bootdateien auf mehreren Datenträgern, Dateisystemfehler). In diesen Fällen führt eine strukturierte Neuinstallation oft schneller zu einem verlässlichen, updatefesten System — ohne Datenverlust, sofern die Daten- und Schlüsselmaterialien vorher sauber gesichert werden.

• Neuinstallation statt Konvertierung bei fehlendem UEFI: Wenn nur Legacy-Boot möglich ist oder UEFI instabil arbeitet, bringt GPT auf dem Bootlaufwerk keinen Nutzen und erzeugt unnötige Komplexität.
• Neuinstallation bei nicht konvertierbarem Layout: Wenn das MBR-Layout die Tool-Bedingungen nicht erfüllt (z. B. erweiterte/logische Partitionen oder kein Partitions-Slot frei), ist ein Neuaufbau mit sauberem GPT-Layout planbarer als riskante Umbauten ohne belastbares Recovery-Konzept.
• Neuinstallation bei Mehrplatten-Bootchaos: Wenn Bootdateien historisch auf verschiedenen Datenträgern verteilt sind und eine Konsolidierung nicht eindeutig möglich ist, ist ein kontrollierter Neuaufbau (mit nur angeschlossenem Ziel-Laufwerk) oft die sicherste Variante.
• Datenverlust vermeiden (Mindest-Checkliste): Vorher vollständiges Backup der Nutzdaten, Export/Recovery von BitLocker-Keys, Notieren von Lizenz-/Gerätezertifikaten (wo relevant) und Verfügbarkeit von Treibern/Netzwerkzugang sicherstellen.