If you use Configuration Manager to enable and configure BitLocker during OSD, then chances are you have come across the dreaded Failed to CreateRecoveryPassword (0x80004005) at some point.
This does not happen often; however, my guess is that it happens 3% (or less) of the time. It has been a known problem in Current Branch 2303 and earlier (at the time of this writing, there is not enough information on Current Branch 2309).
Back in Current Branch 2203, Microsoft added the ability to escrow the BitLocker recovery information to the CM database during a task sequence (see Escrow BitLocker recovery password to the site during a task sequence).
This option is great since previously key needed to be escrowed to Active Directory or the CM Client needed to get the BitLocker Management policy after the task sequence was finished (NOTE: this policy and hardware inventory is still required for server-side reporting status, which is not great if it is needed in a timely manner). In addition, escrowing the recovery key to the CM database is now supported in a Provision TS starting in Current Branch 2309, as a result of a case we raised back in 2022 (see Enable BitLocker through ProvisionTS).
Until the ConfigMgr team gets around to fixing the issue, there are a few things we can do. There were two new task sequence variables that were introduced in Current Branch 2203: OSDRecoveryKeyPollingFrequency and OSDRecoveryKeyPollingTimeout.
The OSDRecoveryKeyPollingFrequency is how often it will poll the site database for the recovery key escrow status. The default is 300 seconds, the minimum is 15 seconds, and I configure this for 30 seconds. OSDRecoveryKeyPollingTimeout is the maximum number of seconds it will wait for the recovery key to be escrowed before timing out. The default is 1800 seconds, the minimum is 30 seconds, and I configure this for 60 seconds.
After reducing the timeout values for both settings, the next thing that can be done is configuring several retries after the step initially fails. At one customer, even without a reboot in between retry attempts, we did see a reduction in failures between each retry attempt. We now recommend adding a reboot and a timeout between each retry attempt to see if that reduces (or fingers crossed, eliminates) the issue.
Here is a task sequence module that you can start from and modify accordingly if you are experiencing this in your environment (you can download it here).
This can be used for both OSD and a Provision TS. The steps for each can now be combined now that escrowing of the recovery key to the CM database is supported for a Provision TS, however, for the Provision TS scenario I choose to wait for BitLocker to complete the encryption process before continuing. Also, you may be wondering why install the MBAM Client at the end of the task sequence. Yes, it is still used and gets installed as soon as the client gets the BitLocker Management policy. Since it is required before encryption status shows on the server-side, hopefully installing it ahead of time speeds up the inventory and reporting process.