SOLVED

Bitlocker recovery keys not syncing on OnPrem devices

Frequent Contributor

Steps U do.

 

Move devices in SCCM into a collection where Intune controls everything, devices are on-prem.
All policy's work, but the Bitlocker recovery keys does not sync from AD to Intune.

 

If I manually go to the device I can trigger a Bitlocker key rotation and one key shows up. Fully AAD devices that went thru Autopilot has two recover keys in Intune.

 

Not sure how everyone is handling this but I did find a remediation script.
https://call4cloud.nl/2021/02/b-for-bitlocker/

But is there any other way of handling this and why is it happening?

 

 

13 Replies

@JimmyWork 

 

The following option is not present in a Bitlocker policy, but present in a Endpoint protection policy template. Would this actually solve it? And do i have to delete the Bitlocker policy or is there anyway of me setting only that option?

JimmyWork_0-1654290315236.png

 

best response confirmed by JimmyWork (Frequent Contributor)
Solution

Hi @JimmyWork 

 

Do you have on premise GPO? If you do, bear in mind it will always win, so make sure its disabled on devices that scoped in Intune policy.
I would also use Intune Endpoint Protection Template (like you mentioned above) and make sure the setting you attached is selected and also the one I attached.

I have used the script below last year to migrate the keys into AAD, hope it helps as well

https://msendpointmgr.com/2021/01/12/migrate-bitlocker-to-azure-ad/

 

 

Moe

Thank you for answering, i do have on premise GPO but I also have set the policy for MDM wins over GPO

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict

@Moe_Kinani 

 

Also in your image you are using a Endpoint protection policy template, I have configure Bitlocker policy with a Bitlocker policy template, the option

"Store recovery information in Azure Active Directory before enabling BitLocker" is not available in my config, I do however have "Require device to back up recovery information to Azure AD"

Got it, thanks for the clarification!

I still think disabling GPO policy would remove some complexity in your case. There are multiple places for Bitlocker in MEM and I would stay on one policy from MEM. 

Moe

Thank you, I'm testing a script and later on I'm uninstalling the SCCM client making the device Intune only, this should also result in bitlocker keys synced to Intune right?
Yes, if the policy applied to the hybrid join device from Intune only.
Azure AD devices should be fine.

Moe
Still having issues on some devices.
I did uninstall the SCCM client, the device has the Bitlocker policy applied from Intune, fully managed by Intune now. No bitlocker key still
Hi Jimmy,

Not surprised by this behavior as the bitlocker policy applied and the device is already encrypted. You can use the powershell to escrow the keys in Azure AD or disable bilocker manually and let the policy encrypt them again.

Moe

@Moe_Kinani 

 

Thank you again for answering.
What I'm currently trying is that I used the following PS script.
Window- Devices -PowerShell scripts.

Assigned it to a Device, but for some reason it has yet run, after 4 hours.

 

$BitLocker = Get-BitLockerVolume -MountPoint $env:SystemDrive
$RecoveryProtector = $BitLocker.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }

BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $RecoveryProtector.KeyProtectorID


 

It should be executed within an hour (or at least after restarting). How did you determine it wasn't executed? Could you also please tell me what settings you used for the script?
Not sure if the device was restarted.

PowerShell script
Run this script using the logged on credentials
No
Enforce script signature check
No
Run script in 64 bit PowerShell Host
Yes

Assigned to a device group.
Checked the Device status report on the Script and if any keys actually showed up.
Will check the device tomorrow, maybe ASR rules are blocking the script from running?
Working now, thank you for your help.
For some reason it was not triggered yesterday, but today it ran when i re-created the powershell script and it's working :)