BitLocker recovery key escrow failing silently for computer in Azure AD DS Standard tier, standalone domain

Question

BitLocker recovery key escrow failing silently for computer in Azure AD DS Standard tier, standalone domain

Zsolt Farkas 0

We have AD DS for Windows servers in our infrastructure. There is a domain group policy in place to allow Bitlocker key to be stored in AD. The policy is effective, and Bitlocker is successfully activated on the server.

When saving the key to AD, the command is executed seemingly successfully. However, the key never gets into the domain.

Azure AD DS Standard tier, standalone
BitLocker recovery key escrow failing silently
Event 513 fires but msFVE-RecoveryInformation object not found on either DC
ACL verified correct including ea715d30-... CreateChild entry
Reproducible on computer object

Is this some known limitation or do we have a problem in our Azure AD DS instance?

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-12T09:27:11.6+00:00
Hello Zsolt Farkas,

In a typical Active Directory setup, BitLocker stores recovery information in AD by creating an msFVE-RecoveryInformation child object under the computer account. This object contains the recovery password and other related details. You can read more about this here: https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan#bitlocker-recovery-information-stored-in-ad-ds

Since the command completes successfully and Event 513 is logged, but the msFVE-RecoveryInformation object is not present, this behavior may be related to how Azure AD Domain Services (Microsoft Entra Domain Services) works.

Azure AD Domain Services is a managed domain service, so some directory operations may behave differently compared to a traditional on-premises Active Directory.

For more details, please refer to: https://learn.microsoft.com/azure/active-directory-domain-services/overview

To help understand the scenario better, could you please confirm:

Whether the server is only joined to Azure AD DS or part of a hybrid AD setup

The command used to back up the BitLocker recovery key

This information will help investigate the issue further.
Zsolt Farkas 0 Reputation points

2026-03-12T15:20:07.15+00:00

Hi Sridevi Machavarapu,

Thank you for investigating this. The command I used was this:

$keyId = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |

Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } |

Select-Object -ExpandProperty KeyProtectorId

Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $keyId

We are not hybrid, the server is only joined to Azure AD DS. However, years ago, chances are it used to belong to a traditional Windows AD that has been closed since. Might there be some remnants causing problem?

Thank you
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-12T15:45:04.44+00:00

Hello Zsolt Farkas,

Thank you for sharing the command and the additional details.

The command you used looks correct and is typically used to back up the BitLocker recovery key to Active Directory. In a standard AD environment, this would create the msFVE-RecoveryInformation object under the computer account.

Since the server is joined only to Azure AD Domain Services and not part of a hybrid setup, the behavior may be related to how Azure AD DS handles certain directory operations. Azure AD DS is a managed domain service, so some actions may behave differently compared to a traditional on-premises Active Directory.

Previous membership in another domain usually should not cause issues once the server has been properly joined to the current domain, but it would still be good to confirm that the computer object exists normally in Azure AD DS.

It may also help to try the same command on another server joined to the same Azure AD DS domain. This can help determine whether the issue is specific to that machine or related to the domain environment.

Hope this helps!
Zsolt Farkas 0 Reputation points

2026-03-12T16:27:05.8466667+00:00

Thank you, I continue checking on another machine.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-13T19:00:54.2033333+00:00

Hello Zsolt Farkas,

Please confirm if you have any further queries on this or good to close this question.
Sina Salam 31,456 Reputation points Volunteer Moderator

2026-03-15T11:30:09.6966667+00:00
Hello Zsolt Farkas,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your BitLocker recovery key escrow failing silently for computer in Azure AD DS Standard tier, standalone domain.

What you can do in step by step:

Record the Recovery Key ID displayed on the BitLocker recovery screen, then later match it with stored keys in recovery portals as documented in Microsoft’s BitLocker recovery guidance - https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide.

Determine the device registration type by running dsregcmd /status in Command Prompt to confirm whether the device is AzureADJoined, DomainJoined, or neither, which identifies where the recovery key should be stored https://learn.microsoft.com/entra/identity/devices/troubleshoot-device-dsregcmd.

If the device is associated with a personal account, retrieve the key from the Microsoft account recovery portal at https://account.microsoft.com/devices/recoverykey as described in Microsoft’s BitLocker key backup documentation.

If the device is joined to an organization, locate the key in Microsoft Entra ID via the admin recovery portal https://aka.ms/aadrecoverykey or through Active Directory computer object attributes when domain-based escrow policies are enabled https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-password-viewer.

If the recovery key cannot be found in any escrow location or backup record, the encrypted volume protected by Microsoft BitLocker cannot be decrypted and the only remaining option is disk reinitialization or OS reinstallation per Microsoft BitLocker recovery documentation https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-16T09:32:54.3266667+00:00

Hello Zsolt Farkas,

Please confirm if you have any further queries on this? Feel free to reach out!

Your answer

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-12T09:27:11.6+00:00

Hello Zsolt Farkas,

In a typical Active Directory setup, BitLocker stores recovery information in AD by creating an msFVE-RecoveryInformation child object under the computer account. This object contains the recovery password and other related details. You can read more about this here: https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan#bitlocker-recovery-information-stored-in-ad-ds

Since the command completes successfully and Event 513 is logged, but the msFVE-RecoveryInformation object is not present, this behavior may be related to how Azure AD Domain Services (Microsoft Entra Domain Services) works.

Azure AD Domain Services is a managed domain service, so some directory operations may behave differently compared to a traditional on-premises Active Directory.

For more details, please refer to: https://learn.microsoft.com/azure/active-directory-domain-services/overview

To help understand the scenario better, could you please confirm:

Whether the server is only joined to Azure AD DS or part of a hybrid AD setup

The command used to back up the BitLocker recovery key

This information will help investigate the issue further.
Zsolt Farkas 0 Reputation points

2026-03-12T15:20:07.15+00:00

Hi Sridevi Machavarapu,

Thank you for investigating this. The command I used was this:

$keyId = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |

Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } |

Select-Object -ExpandProperty KeyProtectorId

Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $keyId

We are not hybrid, the server is only joined to Azure AD DS. However, years ago, chances are it used to belong to a traditional Windows AD that has been closed since. Might there be some remnants causing problem?

Thank you
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-12T15:45:04.44+00:00

Hello Zsolt Farkas,

Thank you for sharing the command and the additional details.

The command you used looks correct and is typically used to back up the BitLocker recovery key to Active Directory. In a standard AD environment, this would create the msFVE-RecoveryInformation object under the computer account.

Since the server is joined only to Azure AD Domain Services and not part of a hybrid setup, the behavior may be related to how Azure AD DS handles certain directory operations. Azure AD DS is a managed domain service, so some actions may behave differently compared to a traditional on-premises Active Directory.

Previous membership in another domain usually should not cause issues once the server has been properly joined to the current domain, but it would still be good to confirm that the computer object exists normally in Azure AD DS.

It may also help to try the same command on another server joined to the same Azure AD DS domain. This can help determine whether the issue is specific to that machine or related to the domain environment.

Hope this helps!
Zsolt Farkas 0 Reputation points

2026-03-12T16:27:05.8466667+00:00

Thank you, I continue checking on another machine.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-13T19:00:54.2033333+00:00

Hello Zsolt Farkas,

Please confirm if you have any further queries on this or good to close this question.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-16T09:32:54.3266667+00:00

Hello Zsolt Farkas,

Please confirm if you have any further queries on this? Feel free to reach out!