Mit Bitlocker verschlüsselte System-SSD auf neues Mainboard mitnehmen/umziehen/einbauen – ohne Datenverlust möglich?

Der reicht auch. Wirkliche Argumente, warum er nicht reichen sollte, kamen ja auch keine.
Dennoch spricht auch nichts dagegen Bitlocker zu pausieren - das erspart dir dann das manuelle Eingeben des Schlüssels, weil wirklich scharf drauf war ich auch nie.
 
  • Gefällt mir
Reaktionen: me2u
@tollertyp ... sprichst du aus Erfahrung? Hast du das denn schon gemacht, was ich vorhabe?

SSD mit Bitlocker ausbauen -> neues Mainboard & neue CPU einbauen -> SSD wieder rein, Booten -> Bitlocker-Wiederherstellungsschlüssel eingeben, normal nutzen?

Eigentlich ist meine Frage ja recht simpel und ich fänd's voll cool, wenn jemand aus praktischer Erfahrung bestätigen oder dementieren kann, dass das funktioniert wie geplant. :)
 
Bob.Dig schrieb:
Und was passiert dann?
Das System startet bzw. lässt den Zugriff auf den Datenträger zu. Der Wiederherstellungsschlüssel ist genauso gut wieder jeder andere Schlüssel auch. Hat man den, kann man mit dem Laufwerk alles machen.
Ergänzung ()

me2u schrieb:
SSD mit Bitlocker ausbauen -> neues Mainboard & neue CPU einbauen -> SSD wieder rein, Booten -> Bitlocker-Wiederherstellungsschlüssel eingeben, normal nutzen?
Exakt! Alles andere wäre auch reichlich praxisfremd.
 
tollertyp schrieb:
Kann mir jemand erklären, warum es hier in einem Desaster enden kann, trotz Backup-Codes, wenn er Bitlocker weder pausiert noch deaktiviert?
In einem Fall von mir hatte ich vor, ein Laufwerk mittels Backup wiederherzustellen. Während der Wiederherstellung folgte ein Fehler, worin stand, dass nicht mehr auf das Laufwerk zugegriffen werden konnte. Im Bios gab es dann eine Bootschleife, wovon ich nicht mehr herauskam. Es wurde mir der Zugriff verweigert und selbst die Wiederstellungscodes konnten hier nicht mehr was bewirken.

Die Optionen, die mir hierzu angezeigt wurden, endeten immer in einem Fehler.

Mein Stick mit der Rettungsumgebung konnte auch nicht mehr gebootet werden, weil hier kein Zugriff auf dem Laufwerk möglich war. Das Laufwerk wurde während der Wiederherstellung gesperrt.

Mittels Windows Setup konnte ich auf das Laufwerk dann doch letztendlich zugreifen und die vorhandenen Partitionen löschen. Danach klappte es dann wieder mit der Rettungsumgebung (Stick) und das Wiederherstellen mit einem Backup.

Würde daher auch den BitLocker pausieren oder beenden und später wieder (falls erwünscht) aktivieren.
 
  • Gefällt mir
Reaktionen: me2u
Evil E-Lex schrieb:
Exakt! Alles andere wäre auch reichlich praxisfremd.
Blöd gefragt, aber Mutmassung oder Wissen (aus Erfahrung)?
Ich habe nämlich gelesen, dass Bitlocker irgendwie ans spezifische TPM Modul gebunden sei und weiss jetzt halt nicht ob das stimmt oder nicht . . .
 
me2u schrieb:
Ich habe nämlich gelesen, dass Bitlocker irgendwie ans spezifische TPM Modul gebunden sei und weiss jetzt halt nicht ob das stimmt oder nicht
Standardmäßig ja.
Wenn TPM nicht funktioniert, zurückgesetzt bzw. gelöscht wurde, ist die Entsperrung aber immer mittels des Bitlocker-Wiederherstellungsschlüssels möglich.

me2u schrieb:
praktischer Erfahrung bestätigen oder dementieren kann, dass das funktioniert wie geplant.
Das funktioniert.
 
Evil E-Lex schrieb:
Das System startet bzw. lässt den Zugriff auf den Datenträger zu. Der Wiederherstellungsschlüssel ist genauso gut wieder jeder andere Schlüssel auch. Hat man den, kann man mit dem Laufwerk alles machen.
Ist halt die Frage, wenn man das macht, ob dann ein ggf. neues TPM automatisch berücksichtigt wird.
 
  • Gefällt mir
Reaktionen: me2u
me2u schrieb:
SSD mit Bitlocker ausbauen -> neues Mainboard & neue CPU einbauen -> SSD wieder rein, Booten -> Bitlocker-Wiederherstellungsschlüssel eingeben, normal nutzen?
Das soll so funktionieren.
Allerdings kenne ich Threads wo dem nicht so war. Da wurde der vorher ausgedruckte Backup Code einfach nicht akzeptiert.

Ich persönlich deaktiviere Bitlocker wenn möglich vorher.

Anyway.
Soll jeder so machen wie ihm beliebt.
 
  • Gefällt mir
Reaktionen: me2u
Bob.Dig schrieb:
Ist halt die Frage, wenn man das macht, ob dann ein ggf. neues TPM automatisch berücksichtigt wird.
Für den reinen Zugang ist das irrelevant. Der Wiederherstellungsschlüssel ist ein Zweitschlüssel der unabhängig von weiteren Schlüsseln funktioniert. Wenn man ein TPM in einer neuen CPU nutzen will, muss man natürlich neu verschlüsseln.
Ergänzung ()

BFF schrieb:
Da wurde der vorher ausgedruckte Backup Code einfach nicht akzeptiert.
Da wird man vermutlich irgendwann neu verschlüsselt haben und den falschen Wiederherstellungsschlüssel aufgehoben haben.
 
  • Gefällt mir
Reaktionen: me2u
Evil E-Lex schrieb:
Da wird man vermutlich irgendwann neu verschlüsselt haben und den falschen Wiederherstellungsschlüssel aufgehoben haben.
Nachweisbar nicht.
Wir konnten das sogar nach vollziehen.
Sprich Bitlocker aus, BL an, neuen Backup Code gedruckt, Datenträger in neues Gerät, starten, Code eingeben, Falscher Code.

Weil wir zu faul waren alle möglichen Beteiligten anzusprechen haben wir BL deaktiviert, Datenträger in neues Gerät, BL aktiviert und gut wars.

Wir vermuten das dies wirklich vom TPM verursacht war und es da „Inkompatibilitäten“ zwischen AMD/Intel auftraten. Wir wechselten damals von Intel nach AMD.
 
  • Gefällt mir
Reaktionen: me2u, wuselsurfer und Evil E-Lex
Evil E-Lex schrieb:
Wenn man ein TPM in einer neuen CPU nutzen will, muss man natürlich neu verschlüsseln.
Ich meine sogar gelesen zu haben: nein. Wenn Du den Wiederherstellungsschlüssel eingegeben hast, wird der Key sogar automatisch an das neue TPM angepasst. Nur sicher bin ich mir nicht. Und vor allem, ob das reine Pausieren der Verschlüsselung wirklich eine gute Idee ist, wenn man die CPU wechselt.

Aber es gibt sicher Leute hier, die machen das regelmäßig beruflich.
 
  • Gefällt mir
Reaktionen: me2u und Evil E-Lex
BFF schrieb:
Nachweisbar nicht.
Wir konnten das sogar nach vollziehen.
Sprich Bitlocker aus, BL an, neuen Backup Code gedruckt, Datenträger in neues Gerät, starten, Code eingeben, Falscher Code.
Interessant. Das klingt ja fast nach nem Bug. Ich arbeite ja nur mit forensischen Images und da hat der Wiederherstellungsschlüssel immer funktioniert. Wobei ich da natürlich einschränken muss, dass das natürlich niemals ein Bootdatenträger ist, sondern immer ein separater Datenträger bzw. Image. Die Hardware ist natürlich so gut wie immer abweichend vom Fremdsystem. Hatte ein solches Verhalten noch nicht. Muss ich mir für die Zukunft merken.
Ergänzung ()

Bob.Dig schrieb:
Ich meine sogar gelesen zu haben: nein. Wenn Du den Wiederherstellungsschlüssel eingegeben hast, wird der Key sogar automatisch an das neue TPM angepasst.
Das wäre sehr elegant. Wusste ich auch noch nicht.
 
LiniXXus schrieb:
In einem Fall von mir hatte ich vor, ein Laufwerk mittels Backup wiederherzustellen.
Was bedeutet das? Meinst du Backup-Codes? Bitte exakt formulieren.
LiniXXus schrieb:
Während der Wiederherstellung folgte ein Fehler, worin stand, dass nicht mehr auf das Laufwerk zugegriffen werden konnte.
Welcher Wiederherstellung?
LiniXXus schrieb:
Mein Stick mit der Rettungsumgebung konnte auch nicht mehr gebootet werden, weil hier kein Zugriff auf dem Laufwerk möglich war. Das Laufwerk wurde während der Wiederherstellung gesperrt.
Während welcher Wiederherstelltung?

Edit:
Ich glaube am Wochenende erlaube ich mir mal den Spaß, die SSDs eines Laptops im anderen zu booten versuchen mit Bitlocker.
 
Ich mache mit dem Paragon Festplattenmanager regelmäßig Backups und zum wiederherstellen des Systemlaufwerk wird ein bootbarer Stick erstellt. Damit wird das Programm mittels Windows PE gebootet und es lassen sich dann damit Laufwerke bearbeiten oder Backups wieder einspielen. Das klappt in der Regel auch sehr gut und habe es schon oft erfolgreich ausführen können.

Das nutze ich auch wenn ich was austesten möchte und danach meine System wiederhergestellt werden soll.

Aber in diesem Fall mit dem BitLocker wurde die SSD gesperrt, damit die Daten nicht gelöscht werden können. Es hatte sich auch ein Fehler damit ergeben weil die Wiederherstellung zum Teil bereits ausgeführt wurde.

Nach dem Neustart bekam ich einen Fehler mit ein paar Lösungen, die alle nicht funktionieren. Ich kam daher nicht mehr auf Windows und überhaupt konnte nichts mehr unternommen werden. Der Stick hängte sich beim booten fest. Das kenne ich wenn das Programm nicht auf Laufwerke zugreifen kann.

Selbst das Löschen per BIOS Funktion ging nicht und es wurde ausgsagt, dass kein Zugriff möglich sei.

Ein Backup hatte ich ja, ich musste nur die Wiederherstellung mit dem Programm aus dem Uefi mit dem Stick irgendwie wieder zum laufen bekommen.

Die Lösung war letztendlich dann ein Windows Setup und dessen Seite mit den Laufwerke. Darin konnte ich die Partition löschen und ich kam dann auch mit dem Stick mit der Rettungsumgebung von Paragon wieder drauf. Damit lief dann die Wiederherstellung problemlos durch.

Mit dem ersten Vorgang hatte ich die Partition nicht gelöscht, denn diese werden normalerweise beim wiederherstellen überschrieben. Hätte ich die Partition zuvor gelöscht oder die SSD mittels BIOS Funktion gelöscht, hätte es dieses Problem nicht gegeben.

Damals hatte ich Windows 24h2 testen wollen und danach sollte mein Backup wieder eingespielt werden. Windows 24H2 hatte mir aber unbewusst den BitLocker mit dem Setup mit aktiviert. Windows 24H2 hatte ich in der Testphase installiert.
 
Zuletzt bearbeitet:
Update

Ich habe mich schlussendlich aus Sicherheits-/Bequemlichkeitsgründen dazu entschieden, Bitlocker auszuschalten um es später nach dem Umbau wieder einzuschalten. Das ging auch viel schneller als erwartet (trotz gut 1TB an Daten auf der SSD) und hat knappe 10-15min gedauert bis die Entschlüsselung abgeschlossen war, hätte gedacht, dass das deutlich länger dauern würde.

Nun, ich war wirklich erstaunt, wie problemlos Windows den Hardware-Tausch mitgemacht hat. Das System hat OOTB gebootet und lief dann einwandfrei. Getauscht wurde von einem MSI X470 auf ein ASUS X570 Board und die bisherige Ryzen 5600 CPU wurde durch eine 5700X ersetzt; der Rest des Systems ist gleich geblieben. Hatte mich eigentlich auf eine notwendige Reparatur-Installation eingestellt. Aber die war nicht nötig. :)
 
  • Gefällt mir
Reaktionen: Evil E-Lex, tollertyp, LiniXXus und eine weitere Person
War zu erwarten das ein Windows das so tut.

Anyway.
Schoen das es geklappt hat. 👍
 
  • Gefällt mir
Reaktionen: tollertyp und me2u
Ich wuerde Dir antworten: "Weil ich es kann". 😉 @tollertyp

Am Ende bleibt es einem Jeden seine eigene Entscheidung.
Und! Wie wir wissen, wissen manche garnicht das sie mit Bitlocker beglueckt sind.
 
  • Gefällt mir
Reaktionen: me2u
Ja, gerade wenn man es nutzt ohne es zu wissen stellt sich die Frage um so mehr.
Aber hier weiß er es ja, und nutzt es, also dürfte es ja auch einen Grund geben?

Also Laptops, die ich auch mal mitnehme, bei denen aktiviere ich auch die Bitlocker-Verschlüsselung, so ist es nicht. Man muss einem potentiellen Dieb ja nicht auch noch gleich seine Daten anvertrauen. Zuhause sehe ich das etwas weniger kritisch, deshalb habe ich sie auf den Desktops i.d.R. nicht aktiviert.

Aber klar: Kann jeder ja für sich entscheiden. Und vermutlich würde ich meistens gar nicht merken, ob mein Desktop Bitlocker-verschlüsselt ist.
 
tollertyp schrieb:
@me2u:
Die Frage sei dennoch einfach mal gestellt: Wozu verwendest du auf deinem Desktop überhaupt Bitlocker?
Eigentlich aus dem gleichen Grund, wie die meisten, die es bewusst mobil nutzen: Zwecks Datensicherheit im Falle eines Diebstahls (hier: Einbruchs). Und, weil es keinen merklichen Performance-Verlust bringt während die Datensicherheit erhöht wird.

Kurzum könnte man sagen wie schon @BFF meinte: Weil ich es kann. 😎

😉

BFF schrieb:
Und! Wie wir wissen, wissen manche garnicht das sie mit Bitlocker beglueckt sind.
Phuuu, sag nichts! Hatte so einen Fall letztens im Freundes-/Familienumfeld mit einem Surface Notebook, das der Kundin gewissermassen abgeschmiert ist. Gott sei Dank war dann doch noch ein Booten ins System ohne Eingabe des Wiederherstellungsschlüssels möglich, der dann umgehend (extern) gesichert und nochmals ausgedruckt wrude! 😵
 
  • Gefällt mir
Reaktionen: tollertyp
Zurück
Oben