What is the correct process to transplant an encrypted drive to an identical system?

thecomputerguy

Well-Known Member
Reaction score
1,326
Client had a 13 month old $1500 laptop die 1 month out of warranty. I keep a spare on hand for this client for situations like this so they don't have an employee out of work until I can get another one. This dead one will be the new spare as I extended the warranty through Dell for a couple hundred and then I'm going to have them replace the motherboard on it (no power).

I though oh great! no problem I'll just swap the drive! Of course the drive is encrypted. I login to the users O365 account and extract the BitLocker key and get it to boot. I now realized that the BL key was required every time. So I came up with the bright idea of decrypting the drive and leaving it decrypted (it's not necessary here).

After decrypted it would boot normally but now none of her services worked (this is my first experience with this). They use OneDrive, Teams, Sharepoint, Outlook ... the whole suite. I brute forced the removal of her account out of the system (Accounts > Work and School > Remove) and then started brute forcing re-logins to OneDrive, Teams, Outlook etc.

When logging into these services I get TPM errors every time I logged back in but despite the TPM errors the accounts seemed to work fine and the computer seems to operate normally for now.

I know this is not the correct way to do this ... am I supposed to transplant the drive, decrypt it, then go in to the BIOS and reset TPM? Then logins should happen as normal?
 
You're not going to like this...

But there ISN'T a way to transplant drives anymore in many systems. And this is by design!

To do this properly you need to transplant not only the drive, but the TPM module as well. If you cannot transplant the TPM module, but still issue the decryption the drive still knows it belongs to a different system, and more importantly M365 does too! This causes other issues.

That being said, your process of using the recovery key to boot the system, and then decrypt the drive is correct and it should not have resulted in the symptoms you're seeing.

If you want to solve the TPM errors you need to reset the TPM inside Windows, then reset it inside the BIOS so the OS and the BIOS can realign, and finally you may want to rename the computer too so it can rejoin whatever directories it's attached to under a new name. Things will go much smoother then. But please note this is a destructive process and anything dependent on the TPM that's reset will be locked forever. But then again... that's already true!
 
You're not going to like this...

But there ISN'T a way to transplant drives anymore in many systems. And this is by design!

To do this properly you need to transplant not only the drive, but the TPM module as well. If you cannot transplant the TPM module, but still issue the decryption the drive still knows it belongs to a different system, and more importantly M365 does too! This causes other issues.

That being said, your process of using the recovery key to boot the system, and then decrypt the drive is correct and it should not have resulted in the symptoms you're seeing.

If you want to solve the TPM errors you need to reset the TPM inside Windows, then reset it inside the BIOS so the OS and the BIOS can realign, and finally you may want to rename the computer too so it can rejoin whatever directories it's attached to under a new name. Things will go much smoother then. But please note this is a destructive process and anything dependent on the TPM that's reset will be locked forever. But then again... that's already true!
So basically nuke and pave the system or there will always be underlying issues?

What if I would have booted the drive using the bitlocker key and then image it to a new drive?

Does encryption and/or all these issues follow that?
 
So basically nuke and pave the system or there will always be underlying issues?

What if I would have booted the drive using the bitlocker key and then image it to a new drive?

Does encryption and/or all these issues follow that?
It follows, the entire point of the encryption locks buried in TPM is that this sort of transaction is always visible somewhere.

Fortunately, it's not an "always issue" at least not quite as you're thinking about it.

The OS knows the TPM doesn't match right now, and that's why you're getting the errors you're getting. You can use tpm.msc and the BIOS to reset that and get things happy again. From there, the only systems that will pitch a flaming fit are systems that had this device enrolled in them. M365 is one such platform, but there could be more. Again after a full TPM reset, and a machine rename that platform is free to rejoin any of those systems without issue, but it will need to be told to rejoin them all. And this is the rub, you can't do that... the user must do that!

There's no way for any of us gear heads to know what systems these new platforms are a part of. So the best we can do is reset things and tell the customer this unit is now "new" and will need to be treated as such with anything that cares.
 
If this topic is not the textbook example of why you need to think, and think carefully, about whether you really need or want full drive encryption on your PC, I don't know what would be.

Now that it's "opt-out" that needs to be considered at initial system setup, not much later where decrypting can take an inordinate amount of time even on modern SSDs.

Even OneDrive has it right with the Personal Vault feature, as it forces one to think about what belongs there, and why. Device-level encryption on Windows PCs has caused way more grief than it would ever have been worth to those who have had to suffer that grief. Talk to your clients about whether they really want or need it when you're setting up new machines.
 
If this topic is not the textbook example of why you need to think, and think carefully, about whether you really need or want full drive encryption on your PC, I don't know what would be.

Now that it's "opt-out" that needs to be considered at initial system setup, not much later where decrypting can take an inordinate amount of time even on modern SSDs.

Even OneDrive has it right with the Personal Vault feature, as it forces one to think about what belongs there, and why. Device-level encryption on Windows PCs has caused way more grief than it would ever have been worth to those who have had to suffer that grief. Talk to your clients about whether they really want or need it when you're setting up new machines.
Yeah I'm not a fan at all of encryption, I can see it's use case absolutely but it completely botches any old school attempt at recovery like slaving the drive, mirroring it, or transplanting it. Just a right to repair kind of thing I guess.

Thing is ... none of these laptop had bitlocker turned in by me or the client and my guess is that they are all encrypted, and encryption is turned on at the factory and it's just waiting to attach to a Microsoft account to unload that bitlocker recovery key somewhere.
 
Windows 11 has had device encryption (Home)/Bitlocker (Pro, etc.) enabled by default if set up with a Microsoft Account since day one. I think the later versions of Windows 10 do the same. Earlier Windows 10 it was off by default, and you had to opt-in, regardless of the Windows account type.

I simply presume that any PC with Windows set up "as Microsoft suggests" is going to have device encryption/Bitlocker enabled by default. Hence the reason this command is always at the ready:

manage-bde -off C:

If you want to check whether encryption is active or not, first: manage-bde -status
 
@thecomputerguy What are you trying to repair?

With the recovery key, the data is recovered. This process isn't designed to break things, it's designed to make things visible. If you have a laptop stolen, you might want your cloud services to be able to know that. TPM and this process enables that process. Otherwise, someone has an access token into your cloud space you cannot revoke, and they can do damage for however long the token is valid. This can be weeks, or months!

But yes, it's additional complexity for home users that are already price adverse to repairs. Not a great situation. But being "solved" by hardware manufacturers building devices that have no replaceable components. This issue because a non-issue when you crack into that laptop to find the SSD is part of the mainboard. A reality that's becoming more common than less every day!
 
Windows 11 has had device encryption (Home)/Bitlocker (Pro, etc.) enabled by default if set up with a Microsoft Account since day one. I think the later versions of Windows 10 do the same.
Actually whether or not Bitlocker gets turned on by default depends on the CPU. If you have an 8th gen or newer CPU (and TPM and Secure Boot enabled), Microsoft enables Bitlocker when you first set up Windows, even if you don't use a Microsoft account. This is the real reason why Microsoft requires an 8th gen or newer CPU to run Windows 11. They want to make sure EVERYONE is on a Microsoft account and has all their data encrypted so they can push their stupid Microsoft 365 subscription.

I'm sure I'm not the only one whose clients never remember their Microsoft account password thanks to Microsoft's stupid PIN number feature. Even worse is the fact that people change phones so often nowadays that by the time they need to sign into their Microsoft account again years later in order to get their Bitlocker recovery key, that phone is long gone and so is the authentication app that's required to get into their Microsoft account even if they remember their password. So far Microsoft still allows SMS based 2FA but that's not going to be around much longer.
 
So far Microsoft still allows SMS based 2FA but that's not going to be around much longer.

And it's not going to be around much longer, period. And it's a grand PITA for a number of venues that require it. If it weren't for 2FAS and its associated browser add-in, that allows you to snag the 6-digit code from 2FAS and it enters it for you, I (and a number of my clients) would have been driven mad by now.
 
SMS based MFA is not leaving M365. Nor will the voice call options.

There is an authentication migration going on that ends Sept of 2024 that enforces enrollment in the new system. But the "new" system supports:

FIDO2 Keys
Microsoft Authenticator
SMS
Temporary Access Pass (Not available on personal accounts)
Hardware OATH tokens
Third-Party Software OATH Tokens (this is your password managers, bitwarden, 3rd party authenticators, etcs)
Voice Calls
Email OTP
Certificate-based Authentication

These aren't changing, from my perspective ever. And given all the advanced MITM going on stealing auth tokens via browser proxy I'm not seeing a security benefit of one vs the other anymore. SMS based MFA is "bad", but in this ecosystem it's just as bad as the rest now. The only thing it does is open the door for someone to clone your SIM card, which while trivial... is still relatively unlikely.
 
open the door for someone to clone your SIM card, which while trivial... is still relatively unlikely.

Which I've been saying for many months, and you've been grossly overblowing for just as long. It's always been a low probability occurrence. Why the change of mind?
 
Which I've been saying for many months, and you've been grossly overblowing for just as long. It's always been a low probability occurrence. Why the change of mind?
It's a low probability outcome for anyone that isn't a business stake holder. As soon as you have your name on a corporate document, which should apply to a great many on this board... you ARE a target. Particularly tech stake holders are among the highest of priority targets regardless of market size.

WE HERE are the threat vectors...

Also anyone that's ever been hit with ID theft, they also have to be forever extra careful.
 
Last edited:
It's a low probability outcome for anyone that isn't a business stake holder.

It's a low probability outcome for the vast majority of the populace, period. If you are a very high profile businessperson, then you are at increased risk for a number of things that "most of us" would likely never, in a million years, experience. And even some of those are relatively rare for higher-profile targets.

The persons I work with who own local LLCs are virtually certain never to have their SIM cloned/compromised. The juice ain't worth the squeeze. Everyone is not a likely target. Most people are not likely targets, and most significant compromises come from very careful targeting of an individual or entity, not "drive-by, smash and grab serendipity."
 
It's a low probability outcome for the vast majority of the populace, period. If you are a very high profile businessperson, then you are at increased risk for a number of things that "most of us" would likely never, in a million years, experience. And even some of those are relatively rare for higher-profile targets.

The persons I work with who own local LLCs are virtually certain never to have their SIM cloned/compromised. The juice ain't worth the squeeze. Everyone is not a likely target. Most people are not likely targets, and most significant compromises come from very careful targeting of an individual or entity, not "drive-by, smash and grab serendipity."

ML allows all of the above to be victims of drive-by smash and grab, that's the part you don't understand and refuse to accept.

If your records are known, which means they're on public documents... you ARE a target, because your exploitation is a matter of time for the script to decide it's your turn.
 
I have learnt just this the hard way, a customer had a laptop which had failed. So I removed the m.2 cards thinking I could transplant them. Issue when booting had bitlocker. Customer did not have key, his account which signed into the ms account was blocked as well.

Not ultimately my issue, though things like this get to me.

So in future no matter what the issue, I am backing up with FABS and Image incase of these issues, lesson learnt moving on.
 
As cyber-insurance is spreading throughout the SMB universe, Bitlocker will be enabled as part of that review. Every insurance questionnaire I've seen has something about "Is data encrypted while at rest?". I don't know the impact encryption has on the premium other than the general adage of 'The more yes answers you have on our questionnaire, the lower risk you represent, so the lower your premium as a result.
 
As cyber-insurance is spreading throughout the SMB universe, Bitlocker will be enabled as part of that review. Every insurance questionnaire I've seen has something about "Is data encrypted while at rest?". I don't know the impact encryption has on the premium other than the general adage of 'The more yes answers you have on our questionnaire, the lower risk you represent, so the lower your premium as a result.
Yep, you will encrypt everything or you won't have insurance. General liability policies are starting to demand it too!
 
Back
Top