Dell Replaced Battery Laptop needs bitlocker key now

Velvis

Well-Known Member
Reaction score
44
Location
Medfield, MA
I had a customer have Dell service come in for a warranty repair and now the laptop is asking for a bitlocker key.

1) I don't think the bitlocker key was ever saved.
2) I am not concerned about the drive data as it was all saved on their M365 account.
3) I did try login into aka.ms/aadrecoverykey with their M365 work account but I don't see anything there with bitlocker info at all.
4) Why would swapping the battery cause this to trigger in the first place?
How can I just wipe it and reinstall Windows?
 
How can I just wipe it and reinstall Windows?

Is Doing a Completely Clean (Re)install of Windows 10 Using Media Creation Tool to Fetch the Win10 ISO File
(and I realize you may already have install media) any different in this case? I didn't think that BitLocker prevented you from wiping a drive completely and starting from scratch, but perhaps I'm wrong. I thought it's purpose was preventing unauthorized access to data on the drive, but not that it would actively prevent a drive from being low level reformatted and used again.

(P.S., and not meant as a dig, but this is yet another case where BitLocker has caused unnecessary complication and where lack of a Microsoft Account linked Windows account [or at least so it seems] has caused a BitLocker key that would have been automatically saved for the user to have drifted off into the ether)
 
I had a customer have Dell service come in for a warranty repair and now the laptop is asking for a bitlocker key.

1) I don't think the bitlocker key was ever saved.
2) I am not concerned about the drive data as it was all saved on their M365 account.
3) I did try login into aka.ms/aadrecoverykey with their M365 work account but I don't see anything there with bitlocker info at all.
4) Why would swapping the battery cause this to trigger in the first place?
How can I just wipe it and reinstall Windows?
Does the client also have a personal M$ account? Look there.
 
Does the client also have a personal M$ account? Look there.

True enough, if the Windows User Account was linked to the Microsoft Account at the time the machine was being initially configured.

I suspected this was not the case based on the original statement about an M365 account, which makes it sound separate, and if they used that account at setup of the machine the M365 Account and Microsoft Account are one and the same.

This is why I really don't understand setting up local accounts and then logging in to a Microsoft Account to use Microsoft services. You're not gaining anything whatsoever as far as "additional privacy" in doing that and you lose other things, such as automatic cloud storage of the BitLocker key.
 
True enough, if the Windows User Account was linked to the Microsoft Account at the time the machine was being initially configured.

I suspected this was not the case based on the original statement about an M365 account, which makes it sound separate, and if they used that account at setup of the machine the M365 Account and Microsoft Account are one and the same.

This is why I really don't understand setting up local accounts and then logging in to a Microsoft Account to use Microsoft services. You're not gaining anything whatsoever as far as "additional privacy" in doing that and you lose other things, such as automatic cloud storage of the BitLocker key.
Depends entirely if it is a personal computer being used for work or if it’s a work computer allowed to be taken home.
 
Depends entirely if it is a personal computer being used for work or if it’s a work computer allowed to be taken home.

You are correct. But how many of us here ever see "a work computer [that's] allowed to be taken home." They're the province of the company's IT department.

The comment about "warranty repair" also makes me think, instantly, "personally owned."

I could be wrong, but I don't play 20 questions when I think the implications are clear.
 
3) I did try login into aka.ms/aadrecoverykey with their M365 work account but I don't see anything there with bitlocker info at all.
If the device was AzureAD joined an admin should be able to get the recovery key from the admin portal.
 
You are correct. But how many of us here ever see "a work computer [that's] allowed to be taken home." They're the province of the company's IT department.

The comment about "warranty repair" also makes me think, instantly, "personally owned."

I could be wrong, but I don't play 20 questions when I think the implications are clear.
I see it all the time, and it's a huge issue. Because many SMBs will buy "home" edition equipped mobile devices that cannot be AzureAD joined. If they cannot be AzureAD joined, then Windows 10 and 11 will bug the user into integrating a PERSONAL Microsoft account. If the SMB is foolish enough to not afford a proper IT professional the time to service the machine BEFORE it's assigned. The first Microsoft account associated with the device will "own" it, and walk away with the recovery key.

To counter this I have a script in my RMM that records these keys, but I also maintain personal Microsoft accounts for each of my clients that I attach to the laptops as local admins during initial setup.

But I still have clients being impatient, or cheap, and handing out equipment before I can get to it. In response, I warn them of the device encryption feature. Sadly, far too many don't heed the call until a situation like this happens, then I tell them well... format C: time and watch the color drain from their faces. There is no fix for a lost recovery key, and there is no amount of after the fact work that can offset for this distinct lack of planning.

Device Encryption is here to stay, it's on by default, and a failure to plan for it will blow up in your face. This is reality, we're all going to be dealing with it.
 
Device Encryption is here to stay, it's on by default, and a failure to plan for it will blow up in your face.

Yep. And, for me, part of that planning is turning it OFF as part of initial setup. That, and making sure that initial setup uses *the appropriate* Microsoft Account to establish long term *correct* ownership of the hardware being linked to the first Windows account being created on the machine.

Belt and braces.
 
Yep. And, for me, part of that planning is turning it OFF as part of initial setup. That, and making sure that initial setup uses *the appropriate* Microsoft Account to establish long term *correct* ownership of the hardware being linked to the first Windows account being created on the machine.

Belt and braces.
I don't think disabling it has any value. Microsoft has shown a perfect willingness to muck with settings like that from time to time. The latter however is a permanent fix, and the only one available to the residential market.
 
Microsoft has shown a perfect willingness to muck with settings like that from time to time.

While I absolutely agree with you in general, I haven't yet seen any machine that was upgraded to Windows 10 or clean installed with Windows 10 (or 11 for that matter, but I have to check the machine I did that on later) ever have BitLocker/Device Encryption turned on when it was initially off.

Something to watch for, that's for sure. But I would be enraged were I someone who intentionally disabled device encryption on a huge drive only to have Microsoft turn it on during some random update and bring my machine to its knees while it attempts to encrypt the drive (if there was sufficient space left to accomplish that to begin with).
 
While I absolutely agree with you in general, I haven't yet seen any machine that was upgraded to Windows 10 or clean installed with Windows 10 (or 11 for that matter, but I have to check the machine I did that on later) ever have BitLocker/Device Encryption turned on when it was initially off.

Something to watch for, that's for sure. But I would be enraged were I someone who intentionally disabled device encryption on a huge drive only to have Microsoft turn it on during some random update and bring my machine to its knees while it attempts to encrypt the drive (if there was sufficient space left to accomplish that to begin with).

What you mean like this: https://www.bleepingcomputer.com/ne...authentication-breaks-after-november-updates/

Microsoft moved to remove support for RC4 encryption of Kerberos because it's ancient, broken, and crap. And instead of removing it, they "accidentally" made it the requirement. So RIGHT NOW, if you have a domain controller and it's fully patched, it's either not working at all, or running garbage encryption. The difference is if you sanely set a policy to deny the use of insecure ciphers.

I realize it's not quite the same problem, but it's a little too close for me!
 
Back
Top