Event banner
Event details
We are using Autopilot in HAADJ mode. We see an issue during enrollment where the bitlocker recovery key is NOT being uploaded to Azure AD, but it does get uploaded to the onprem AD. Is there any way to enforce the key to upload to Azure AD? Maybe this is down to some timing issue during the bitlocker/enrollment process?
- Jason_Sandys
Microsoft
Going to be a broken record here, but A, begin exploring and using Azure AD join instead of hybrid Azure AD join. There are many caveats, nuances, and "headaches" with HAADJ particularly for new Windows endpoint provisioning. See aka.ms/cloudnativeendpoints. For the specific question, note that saving the key to AD and AAD is the responsibility of the OS and that it only attempts to do this at the time the recovery password is set on the endpoint. Also, on an HAADJ endpoint, if it succeeds in storing to one location or the other (AAD or AD), then it considers the operation successful and moves on. With HAADJ during Autopilot, the HAADJ process doesn't actually complete until the user logs on which is after BitLocker gets enabled and thus there's no path for it to actually store the password in AAD at that time. To address this, you can use a PowerScript (run via a proactive remediation) to store the password in AAD. There are lots of sample scripts on the web for this, but ultimately, it's a one or two line PowerShell command. As noted though, this is one of those "headaches" with attempting to use HAADJ for new endpoint provisioning. and choosing AADJ, while more work in the short run, offers a large number of advantages in the long run including that it aligns with our engineering direction.- Thanks for the response. Our customer is committed to sticking with HAADJ at the moment so we are where we are. And yep, I already identified all the other content you replied with so it seems our only fallback is the PS script to confirm/enforce the upload of the key. Thanks again.
- Jason_SandysSorry, broken record here again, but committing to HAAADJ for new endpoint provisioning is also committing to our non-preferred path and everything that goes along with it including known shortcomings that we have no plan to address as it doesn't align with our engineering direction. Probably not telling you anything new here, but it's worth reinforcing this message to the customer. They are free to choose, but they should understand the implications of their choice as well.
