BitLocker Recovery Information Is Not Backed Up After Domain Join

Check these areas in order:

1. Confirm BitLocker was enabled only after domain join and policy application
   • If BitLocker is enabled before the computer joins the domain, the recovery information is not automatically backed up to AD DS when the device later joins the domain or when policy is applied afterward.
   • For new organizational devices, domain join should happen first. With the appropriate policy enabled, storing the BitLocker recovery key to AD DS is automatic.
2. Review the BitLocker recovery Group Policy settings
   • Verify the relevant recovery policies are configured for the drive type:
     • Choose how BitLocker-protected operating system drives can be recovered
     • Choose how BitLocker-protected fixed drives can be recovered
     • Choose how BitLocker-protected removable drives can be recovered
   • In those policies, enable Save BitLocker recovery information to Active Directory Domain Services.
   • To prevent handoff without escrow, enable Do not enable BitLocker until recovery information is stored in AD DS. This blocks BitLocker from being enabled unless the device is connected to the domain and backup to AD DS succeeds.
3. Check for policy conflicts
   • Conflicting recovery policies can block BitLocker configuration. One documented example is requiring storage to AD DS while not permitting generation of recovery passwords.
   • If conflicting Group Policy settings exist, resolve the GPO conflict before retrying.
4. Verify domain connectivity at the time BitLocker is enabled
   • If the initial backup fails, such as when a domain controller is unreachable during BitLocker setup, BitLocker does not retry automatically.
   • If the enforcement setting in step 2 is not enabled, BitLocker can complete encryption without a successful AD DS backup.
   • During provisioning, ensure the workstation has working domain connectivity before BitLocker is turned on.
5. Check whether AD DS backup was actually required in the build process
   • By default, recovery information is not backed up to AD DS or Microsoft Entra ID. Backup must be explicitly enabled by policy for each drive type.
   • If the build allows BitLocker to start without the enforced backup requirement, escrow can be missed silently.
6. Verify AD DS permissions if backup is failing with access-related errors
   • In environments enforcing Do not enable BitLocker until recovery information is stored in AD DS, an access failure can prevent BitLocker from turning on.
   • A known cause is insufficient permissions on the TPM devices container in AD DS.
   • To validate this scenario:
     1. Temporarily disable the enforcement policy or remove the computer from the domain, then try enabling BitLocker again. If it succeeds, the policy-backed AD DS write path is the likely issue.
     2. Use LDAP and network tracing to inspect the client-to-domain-controller exchange for Access Denied or Insufficient Rights, especially when accessing CN=TPM Devices,DC=<domain>,DC=com.
     3. In an elevated Windows PowerShell session, review TPM information for the affected computer:

                Get-ADComputer -Filter {Name -like "ComputerName"} -Property * | Format-Table name,msTPM-TPMInformationForComputer
        

     4. Check the ACL on msTPM-TPMInformationForComputer and ensure NTAUTHORITY/SELF has both Read and Write permissions.
   • This documented permission issue is noted as limited to computers running versions of Windows earlier than Windows 10.
7. Confirm what should be stored in AD DS
   • AD DS can store the BitLocker recovery password and optionally the BitLocker key package.
   • The key package is not saved by default. If it is required, enable the policy option to back up both the recovery password and key package.
8. Set the provisioning standard to prevent recurrence
   • Join the device to the domain first.
   • Apply the BitLocker recovery policies.
   • Require Save BitLocker recovery information to Active Directory Domain Services.
   • Require Do not enable BitLocker until recovery information is stored in AD DS.
   • Then enable BitLocker.

The most likely root causes in this scenario are:

• BitLocker was enabled before domain join.
• The AD DS backup policy was not enabled for the relevant drive type.
• The device lacked domain controller connectivity when BitLocker was enabled.
• The environment allowed BitLocker to proceed even though backup failed.
• AD DS permissions blocked the backup operation.

References:

• BitLocker FAQ
• BitLocker recovery overview
• BitLocker cannot encrypt a drive: known TPM issues
• BitLocker planning guide
• Enforcing BitLocker policies by using Intune: known issues