The 30-Second Fix: Reboot and Retry
I know this error is infuriating, especially when you're mid-deployment. But before you touch Group Policy or ADSI Edit, try the dumbest thing first: reboot the machine and retry the BitLocker enable operation.
This error often pops up right after a domain join or when the TPM was just cleared. A reboot forces the machine to refresh its Kerberos ticket and re-read the AD schema. I've seen it clear up on Windows 10 21H2 and Windows 11 22H2 builds without any other changes.
If you're in a VM, also try a cold restart (shut down, then start) — not just a guest reboot. Hyper-V and VMware guests sometimes hold onto stale AD connections.
The 5-Minute Fix: Check Group Policy Settings
Still stuck? The real culprit is usually a misconfigured Group Policy. BitLocker needs to be told to store recovery info in AD, and if that policy isn't set — or set to "off" — you'll get this exact code when the drive tries to back up its key.
Here's what to check:
- Open gpedit.msc on the affected machine (or edit the relevant GPO in your domain).
- Go to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption.
- Open "Choose how BitLower recovery information is stored" (or "Store BitLocker recovery information in Active Directory Domain Services" on older builds).
- Set it to Enabled and tick "Require BitLocker backup to AD DS" (or "Do not enable BitLocker until recovery information is stored in AD DS").
Then run gpupdate /force and try again.
A subtle gotcha: the policy name changed between Windows 10 1809 and 1903. On older builds, it's "Store BitLocker recovery information...". On newer builds, it's "Choose how BitLocker recovery information is stored". If you're mixing domain controllers, check both locations.
The 15-Minute Fix: Clear Stale AD Attributes or Re-Djoin
If policies are correct and you still get FVE_E_AD_NO_VALUES, the problem might be that the computer account in AD already has a BitLocker recovery attribute, but it's empty (zero values). This happens when a previous BitLocker enable was interrupted or when the attribute gets mangled by a third-party management tool.
You'll need to clean up the AD object.
Step 1: Find the Computer Account
On a domain controller, open ADSI Edit (or use PowerShell). Connect to the default naming context, then locate the computer object under CN=Computers or wherever your machines live.
Step 2: Inspect the BitLocker Attributes
Right-click the computer object, go to Properties, and filter by "BitLocker". You'll see attributes like:
msFVE-RecoveryInformationmsFVE-KeyPackagemsFVE-RecoveryPassword
If any of these exist but have a count of zero (check the "Attribute Values" pane), that's your smoking gun.
Step 3: Delete the Empty Attributes
Select those empty attributes and click Remove. Don't delete the whole computer object unless you're okay with re-joining the domain.
Alternatively, use PowerShell on a DC with the AD module:
Get-ADComputer "YOURPC" -Properties * | Select-Object msFVE*If you see $null or empty strings, clear them with Set-ADComputer.
After cleaning, force replication (repadmin /syncall /AdeP), then reboot the client and try BitLocker again.
When to Skip the Advanced Fix and Do a Re-Djoin
Honestly, if your domain has a lot of stale attributes, cleaning them one by one is a pain. In a test environment, I'd just unjoin the machine from the domain and rejoin it. That forces AD to recreate the computer object with fresh attributes.
But in production, that's disruptive — you'll need to remove the machine from the domain, reboot, rejoin, and reboot again. Takes 10 minutes but it's guaranteed to be clean. Only do this if the attribute cleanup didn't work, because re-djoin often breaks other things like stored local profiles.
One More Thing: Check the AD Schema Version
If you're running a mixed environment with old Windows Server 2008 R2 DCs, the BitLocker schema extensions might not be present. You'll see this same error because AD doesn't even have the attribute defined.
To check, run adsiedit.msc on a DC, expand the schema, and look for msFVE-RecoveryInformation. If it's missing, you need to run adprep /forestprep and adprep /domainprep from the newer server media. This is rare in 2024, but it still happens in smaller SMBs.
Quick tip: If you're using BitLocker with a TPM + PIN and you get this error, it's almost always the GPO policy, not AD corruption. The AD attribute only gets written after BitLocker starts, so a fresh machine with no prior BitLocker history shouldn't have empty attributes.
Hope this helps you get past this one. It tripped me up the first time too, and it's frustrating because the error message gives you almost no context. But the fix is usually one of these three things — start with the reboot, then the policy, then the AD cleanup. You won't need all three very often.