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

Porthos

Well-Known Member
Reaction score
13,697
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.
 
I use ESET Endpoint Encryption, which I resell to my customers.
I inadvertently tried the 24H2 upgrade hack-job on a non-compatible charity machine,.....still encrypted.

Long story short, nuke and pave (after managing to recover most of the data)

The procedure went fine on other machines following a decrypt.....then re-encrypt.

Joy.
 
It's almost as if, you have to follow the instructions: https://help.eset.com/eee_qsg/en-US/technical_details_window_feature_updates.html

So yes, you have to decrypt / upgrade / encrypt OR, you can build an appropriate configuration file to enable the feature update to complete on its own correctly.

It's never fun when we miss something basic.

I've been there and done that many times, that's certainly how I learn... face first, and full of pain. But this is also why I do not recommend 3rd party disk encryption software. You need full enterprise grade endpoint management and expertise to administrate it successfully. In short, it's too darned hands on!

And this risk repeats AT LEAST annually. Sometimes monthly update roll ups will bite you too. And no, this is NOT Microsoft's fault.
 
Last edited:
why I do not recommend 3rd party disk encryption software.

I don't see any of them being superior to BitLocker. One could also say that they're every bit as potentially problematic as BitLocker.

But BitLocker, like Quick Assist, comes with Windows and is probably the least potentially problematic of the encryption options available. It certainly doesn't prevent a successful Feature Update under typical circumstances or I'd have been toast on many occasions.
 
The overriding thing for me is the limited "protection" Bitlocker is designed to give you - it "Protects your data from offline access" So IF your computer is stolen and someone can log on normally to your computer - no protection. Only if someone removes the disk and tries to access it from a working machine does Bitlocker "do its thing". But what percentage of people really need protection against that? Almost every time I've explained what it actually does, people say "Just turn it off". My read: Low incidence of actual protection, plus the risk of data LOSS because the user doesn't have the key = TURN IT OFF.
 
The overriding thing for me is the limited "protection" Bitlocker is designed to give you - it "Protects your data from offline access" So IF your computer is stolen and someone can log on normally to your computer - no protection. Only if someone removes the disk and tries to access it from a working machine does Bitlocker "do its thing". But what percentage of people really need protection against that? Almost every time I've explained what it actually does, people say "Just turn it off". My read: Low incidence of actual protection, plus the risk of data LOSS because the user doesn't have the key = TURN IT OFF.
I'm confused...

You're saying that if an attacker has your machine, and your password, the encryption has no value. And yes, that's true because they have your machine (factor 1), and they have your password (factor 2), ergo... they have access.

But if they have your machine (factor 1), and they do NOT have your password. Now they have to try to brute force your password, or the encryption key to gain access. If the device isn't encrypted, access to the data can be obtained by simply pulling the drive. This renders the password to the machine, useless.

Device encryption makes passwords functional, it's an enforcement engine. So, no more passwords on machines at all? Because disabling device encryption means disabling passwords too. If you want this, that's perfectly fine. But I don't think most people are that open about their equipment.
 
So IF your computer is stolen and someone can log on normally to your computer - no protection.

And how is this different than any third party encryption?

The first rule of computer security is having control over physical access. As soon as you've ceded that you've already got a major problem on your hands. But, at least with a password, PIN, or biometric access, there's still a challenge that's not necessarily easy to get past. But if anyone happens to have BOTH, it's already GAME OVER.

Nothing is meant to protect against someone who has, from the computer's perspective, legitimate access. If you've got the machine and the login credentials, then you SHOULD be considered to have legitimate access.

Encryption is not, and never has been, about making access more difficult for those who can actually log in.
 
@HCHTech,

I so happen to agree with you about the overall value of drive encryption in the vast majority of cases, but that's a completely separate thing from what encryption is intended to guard against. BitLocker is no different than any other drive encryption in that regard. It's no different in concept than the encryption on mobile devices of all types as well (whether the computer is of a "mobile type" or not).
 
Back
Top