[WARNING] Do not upgrade to 24h2 with the ISO if device encryption is on

Porthos

Well-Known Member
Reaction score
13,286
Location
San Antonio Tx
I had a brand new Dell go to crap using the ISO to upgrade. Went to BitLocker recovery and the recovery key did not help get me out of the loop.
1728429531087.jpeg
 
Interesting.

I've done the ISO update from 23H2 to 24H2 on three machines (two Pro, one Home) with BitLocker/Device Encryption disabled with no issue. I've also done one with BitLocker enabled that was 23H2 home, and it went without a hitch, too.

It's not that your warning is unappreciated, but it would take more than one instance of this kind of thing to even begin to determine if it's a bug versus something idiosyncratic to that machine (typically something corrupt prior to upgrade or a "burp" during the upgrade process).
 
The first thing I do with any computer that comes into the shop (after I've ruled out hardware failure) is turn off encryption. There are a million things that can trigger Bitlocker recovery mode and I don't want to be blamed if that happens and we can't find the Bitlocker recovery key. Even doing a simple BIOS update can trigger it. Don't do anything on that computer until you've turned this garbage off.
 
The first thing I do with any computer that comes into the shop (after I've ruled out hardware failure) is turn off encryption. There are a million things that can trigger Bitlocker recovery mode and I don't want to be blamed if that happens and we can't find the Bitlocker recovery key. Even doing a simple BIOS update can trigger it. Don't do anything on that computer until you've turned this garbage off.
This ^^
Turn this inane garbage off to save your sanity later.
 
Turn this inane garbage off to save your sanity later.

Well, as I've said before, that's what I do with all of my machines, and I encourage my clients to do the same.

That being said, even with SSDs, if they're of a substantial size with a substantial part of the space taken up, decrypting is a non-trivial time taker. I guess that's OK if you have a shop and can just put a machine aside and work on other things while it takes care of doing just that, but those of us who primarily do in-home or in-office service would have a very hard time convincing a client that sitting and waiting for this process to complete should be billable.

I really, really don't like BitLocker, but given that it's becoming the de facto standard configuration, I have to believe that Feature Updates are designed to complete successfully with it enabled under typical conditions. If it's not, that's PR suicide for Microsoft. Occasional errors will happen with Feature Updates, which is a good reason to take a full system image prior to doing one. [I'll admit, I didn't hew to that advice myself recently.]
 
Right now, Bitlocker requires TPM but TPM doesn't require Bitlocker. Let's hope it stays this way.
I would not trust enabling TPM to not expect Bitlocker to rear it's head, so be prepared before doing anything to request the users MSA upfront.
If they have no idea what you are talking about educate them before doing anything regarding the risks.
 
Code:
$BtVolumes = Get-BitLockerVolume
$BtVolumes | ForEach-Object {
$MountPoint = $_.MountPoint
$RecoveryKey = [string]($_.KeyProtector).RecoveryPassword
if ($RecoveryKey.Length -gt 0) {
    Write-Output ("Drive: $MountPoint RecoveryKey: $RecoveryKey.")
}
}

Document, learn, adapt, thrive.

For those advocating for disabling device encryption, I invite you to attempt to do so on an Android or iOS device... I'll wait.
 
If encryption was as "stable" on Windows as it were on Android and iOS - I wouldn't advocate for it!

Amen, amen, amen!! This is another case where Microsoft has screwed the pooch for a technology that works without a hitch, and has for many years, on other platforms.

I would not advocate for turning device encryption off were it not for the endless stream of reports of it creating much pain and loss, and there's been no shortage of those reports here.

I fear BitLocker, as things stand, far more than I fear leaving data unencrypted at rest on a PC.
 
If encryption was as "stable" on Windows as it were on Android and iOS - I wouldn't advocate for it!
The recovery key is baked into your Google or Apple account, and if you hook Windows 11 up to a Microsoft account AND USE IT, the exact same thing happens.

The only issue here is Microsoft allows you to make stupid decisions with how you run your equipment, and the more curated systems do not allow this freedom. If you take that freedom and hang yourself well... that's YOUR FAULT.
 
Back
Top