FVE_E_AD_SCHEMA_NOT_INSTALLED (0X8031000A) on Windows 10/11

You're setting up BitLocker on a domain-joined Windows 10 or 11 machine and you get this error right when BitLocker tries to finalize encryption. The exact error code is 0X8031000A, and it shows up as FVE_E_AD_SCHEMA_NOT_INSTALLED. The error triggers when BitLocker attempts to save its recovery password to Active Directory — either during initial encryption or after a group policy change forces AD backup. I've seen this most often in organizations that recently upgraded their domain functional level or are using a fresh 2012 R2 domain controller that never had BitLocker schema extensions applied.

Root cause

BitLocker needs specific attributes in Active Directory to store recovery keys. These attributes live in the msFVE-RecoveryInformation and msFVE-RecoveryPassword classes. If your AD schema hasn't been extended with the BitLocker schema extensions (included in adprep.exe since Windows Server 2008), the 0X8031000A error is what you get. The machine tells you "I can't store this key — the schema doesn't have the right containers."

What's actually happening here is that the Group Policy setting "Choose how BitLocker-protected operating system drives can be recovered" is configured to "Do not enable BitLocker until recovery information is stored in AD DS" or "Require BitLocker backup to AD DS". When BitLocker hits that checkpoint and AD says "I don't know what that is," it throws the error and refuses to proceed.

The fix

You have two real solutions: extend the AD schema, or disable the AD backup requirement. The first is the right fix for production domains. The second is for test environments or when you can't touch the schema.

Fix 1: Extend the AD schema with BitLocker attributes

This needs a user who's a member of Schema Admins. Do it from a domain controller or a machine with the RSAT tools installed.

1. Log on to a domain controller with Schema Admin credentials.
2. Open an elevated command prompt — right-click Command Prompt, choose Run as administrator.
3. Run this command:
   adprep /forestprep — this prepares the forest schema.
4. Wait for it to finish. It may take a minute or two depending on domain size.
5. Then run:
   adprep /domainprep /gpprep — this updates the domain.
6. Reboot the domain controller.
7. On the client machine, run gpupdate /force and try BitLocker again.

The reason step 3 works is that adprep /forestprep adds the msFVE-RevoveryInformation and related attributes to the schema. Without it, no attribute can be created, no matter what group policy says.

Fix 2: Disable AD backup requirement (quick workaround)

Use this if you don't have Schema Admin access or you're in a test lab.

1. Open Group Policy Management Console on the domain controller.
2. Edit the GPO that applies to the affected machines.
3. Navigate to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.
4. Find "Choose how BitLocker-protected operating system drives can be recovered" and set it to "Not Configured".
5. Alternatively, set it to "Enabled" but uncheck "Do not enable BitLocker until recovery information is stored in AD DS".
6. Run gpupdate /force on the client and retry BitLocker.

This doesn't fix the schema gap — it just tells BitLocker it's okay to proceed without AD backup. That's fine for testing, but in a real domain you want the keys backed up.

What to check if it still fails

• Schema replication delay: After running adprep, the schema changes need to replicate to all domain controllers. Wait 15-30 minutes or force replication with repadmin /syncall.
• Multiple group policies: A higher-priority GPO might still force AD backup. Run gpresult /h report.html to see the applied policies and look for conflicting settings.
• BitLocker WMI namespace: On the client, verify that the BitLocker WMI provider is registered. Run mofcomp C:\Windows\System32\Win32_EncryptableVolume.mof as admin to be sure.
• Event logs: Check Applications and Services Logs > Microsoft > Windows > BitLocker-API > Admin for additional error details.

One last thing — if you're running a Windows Server 2003 domain controller, you need to upgrade the domain functional level before BitLocker schema attributes will work. That's a bigger project but it's the root cause in many legacy environments.