Yeah, that error pops up right when you're trying to enable BitLocker or after a domain join, and it's annoying because everything else seems fine. The short version: BitLocker wants to stash a copy of its recovery key in Active Directory, but it can't find the right place to put it. The fix is usually one command or a small Group Policy tweak.
The Fix: Point BitLocker to the Right AD Attribute
First thing I do when I see FVE_E_AD_NOT_FOUND is check if the computer object in AD has the msFVE-RecoveryInformation attribute in its schema. That attribute is what holds the recovery key. If it's missing, BitLocker throws 0X8031000F because it literally can't find the slot.
Step 1: Check the schema (if you have AD admin rights)
On a domain controller, run this in an elevated PowerShell:
Get-ADObject -Filter {objectClass -eq 'computer'} -Properties msFVE-RecoveryInformation
If that returns nothing for your machine, the attribute might not be in the schema. But honestly, on a modern AD (2008 R2 and up), it's there by default. What's more common is the computer account doesn't have the attribute populated because BitLocker never got the chance to write to it.
Step 2: Force BitLocker to retry the backup
Open an elevated command prompt on the affected machine and run:
manage-bde -protectors -adbackup C:
That tells BitLocker to write the recovery key for the C: drive to AD right now. If that succeeds, you're done. If it fails with the same error, you've got a deeper issue.
Step 3: Check Group Policy
Sometimes the policy that says "store BitLocker recovery info in AD" is set to "off" or "do not allow". On the problem machine, run gpresult /h gp.html and look under BitLocker Drive Encryption. You want to see "Require BitLocker backup to AD DS" set to Enabled. If it's not, that's your culprit.
Push that policy from your domain controller. Computer Config > Policies > Admin Templates > Windows Components > BitLocker Drive Encryption. Set "Store BitLocker recovery information in Active Directory Domain Services" to Enabled. Also make sure "Require BitLocker backup to AD DS" is Enabled.
Then run gpupdate /force and try the backup again.
Why This Works
The error code 0X8031000F translates to FVE_E_AD_NOT_FOUND, which literally means "The specified object could not be found in Active Directory." BitLocker's recovery key backup mechanism looks for a specific container under the computer object—usually CN=BitLocker Recovery, OU=Computers, DC=yourdomain—and if that container doesn't exist or the computer object lacks the right permissions, the backup fails.
The manage-bde -protectors -adbackup command forces BitLocker to create the container on the fly if it can, or at least gives you a clearer error. And the Group Policy setting ensures the backup is required, so BitLocker won't skip it.
I had a client last month whose laptop couldn't join the domain properly and the computer object got created with a stripped-down ACL. That laptop threw 0X8031000F every time. Fixing the permissions on the computer object and running the backup command cleared it in five minutes.
Less Common Variations
Sometimes the issue isn't the attribute or policy—it's the delegation. Here are a few other things I've seen:
- Wrong partition letter: If your system partition isn't C: (maybe you've got a recovery partition), you need to specify the correct drive letter. Check with
manage-bde -statusand use the right volume. - BitLocker not fully enabled: If encryption is in progress or paused, you might get this error. Wait until it's done, then try the backup.
- AD schema not extended: On a really old domain (2003 or early 2008), the BitLocker attributes might not exist. You'd need to extend the schema using
adprep /forestprepandadprep /domainprep—but that's a bigger project. - Read-only DC communication: If your machine is contacting a read-only domain controller (RODC), it can't write to AD. The backup fails saying not found. Make sure you're hitting a writable DC—check with
nltest /dsgetdc:yourdomain.
Prevention
To stop this from happening again, do two things:
- Set the Group Policy to require AD backup before allowing BitLocker to enable. That way any machine that can't back up won't even start encryption, so you catch the problem early.
- Verify computer objects are healthy after domain join. If you auto-create computer accounts with a script, make sure they get the msFVE-RecoveryInformation attribute. PowerShell can add it if it's missing:
Get-ADComputer -Filter * | ForEach-Object {
if (-not ($_.msFVE-RecoveryInformation)) {
Set-ADComputer -Identity $_ -Add @{msFVE-RecoveryInformation=""}
}
}
That's a blunt tool, so be careful in a big environment, but it's saved me a few headaches.
Bottom line—when you see 0X8031000F, don't panic. Check Group Policy, run the backup command, and if that fails, look at the AD object. Nine times out of ten it's a five-minute fix.