How to fix BitLocker error 0x80070057 backing up the recovery key to AD
During automated deployment the drive encrypts but the Enable BitLocker step fails backing up the recovery password to Active Directory. This is common on Windows 11 24H2 and is fixed on the deployment and AD side. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~8 min Updated Jun 2026 85% found this helpful
Error message
Failed to save the recovery password to Active Directory. An error occurred (code 0x80070057): The parameter is incorrect.
Summary
This 0x80070057 (the parameter is incorrect) appears during automated Windows deployment, an SCCM/MECM or MDT task sequence, when the Enable BitLocker step encrypts the drive successfully but then fails to back up the numerical recovery password to Active Directory Domain Services. It became prevalent on Windows 11 24H2, where the built-in step tries the Entra ID (Azure AD) backup path first by design, and the on-premises AD DS backup is left without a recovery object (no ms-FVE-RecoveryInformation under the computer account). The usual root causes are the deployment trying AAD backup when you want AD DS, the AD schema not being extended with the BitLocker attributes, or the backup GPO not being applied before the Enable BitLocker step. The fix is on the deployment and directory side: set the task-sequence variable OSDBitLockerBackupToAAD=False for AD DS, apply the GPO early, confirm the schema is extended, and verify the policy is linked. The encryption itself is fine; only the escrow failed.
What this error means
A deployment task sequence encrypts the drive and then escrows the recovery password to the directory so admins can recover the device later. 0x80070057 here means the encryption worked but the escrow call was rejected as having an invalid parameter, so no recovery object was written.
On Windows 11 24H2 the built-in step now favours the Entra ID backup path, so when you actually want on-premises AD DS, the on-prem backup is skipped or fails. Add an un-extended schema or a GPO that has not applied yet, and the escrow cannot complete. Pointing the step at AD DS and making sure the directory is ready resolves it.
Common causes
The step attempts Entra ID (AAD) backup when you want AD DS (24H2 default).
The AD schema is not extended with the BitLocker (ms-FVE) attributes.
The backup GPO has not been applied before the Enable BitLocker step.
Hybrid Azure AD Join has not completed yet.
OU-level permissions or replication prevent writing the recovery object.
The built-in OSDBitLocker step passed an unsupported argument.
Expert insight
“This one trips up a lot of admins after 24H2. The drive encrypts fine, but the recovery key never lands in AD and the task sequence dies with 0x80070057. The reason is the new build tries the Entra ID backup first, so if you are an on-prem AD DS shop, you point it back with OSDBitLockerBackupToAAD set to False. Then make sure the schema is extended and the backup GPO has actually applied before the BitLocker step, because timing is the other classic cause. Get those right and the key escrows cleanly.”
2Run it as a Run Command Line or PowerShell step in the task sequence.
3This bypasses an argument issue in the built-in step.
Method 6
Ensure hybrid join completes first (for AAD)
1If you intend Entra ID backup, make sure Hybrid Azure AD Join completes before the Enable BitLocker step.
2Also confirm OU permissions and replication allow writing the recovery object.
3Then the escrow can succeed.
This 0x80070057 is a deployment escrow failure, not an encryption fault: the drive encrypts but the recovery key does not reach the directory. For on-prem AD DS, set OSDBitLockerBackupToAAD=False, apply the backup GPO before the BitLocker step, and confirm the schema is extended and the GPO is linked. Use a manual manage-bde adbackup step if the built-in one keeps failing.
Frequently asked questions
Why does BitLocker fail with 0x80070057 during deployment?
The task sequence encrypts the drive but cannot back up the numerical recovery password to Active Directory. On Windows 11 24H2 the built-in step favours the Entra ID path, so the on-prem AD DS escrow is skipped or fails.
How do I fix it for on-premises AD?
Set the task-sequence variable OSDBitLockerBackupToAAD=False before the Enable BitLocker step, apply the backup GPO early, and confirm the AD schema is extended and the Store-in-AD-DS GPO is linked to the OU.
Is the drive still encrypted?
Yes. The encryption succeeds, you can see the Numerical Password protector with manage-bde -protectors -get C:. Only the recovery-key backup to the directory failed, so the fix is about escrow, not encryption.
How do I check the AD schema is extended?
Look at a computer object's attributes for ms-FVE-RecoveryInformation, ms-FVE-RecoveryPassword and ms-FVE-KeyPackage. These exist in AD from Windows Server 2012; if missing on an older schema, extend it.
Why does GPO timing matter?
The BitLocker AD backup policy must be active before the Enable BitLocker step runs. Add a Restart and gpupdate /force ahead of it, or the escrow policy is not in effect when encryption starts and the backup fails.
Can I back up the key manually instead?
Yes. Replace the built-in step with manage-bde -protectors -add C: -adbackup -RecoveryPassword as a command-line step, which escrows the recovery password explicitly and avoids an argument issue in the built-in step.
Still not working?
If the escrow still fails with the schema extended and the GPO applied, capture smsts.log and search for BackupToAAD and 0x80070057 to see which path the step took, and check OU permissions and AD replication for the recovery object. You can also submit your error to us for a tailored fix.
