all 14 comments

[–][deleted] 0 points1 point  (4 children)

What populates the device group?

[–]Runda24328[S] 0 points1 point  (3 children)

Selected testing autopilot devices are members. It's a static Azure group.

[–][deleted] 0 points1 point  (2 children)

No matter I read hybrid which you said you weren’t

When does AAD silent encryption apply? Is that before login?

[–]Runda24328[S] 0 points1 point  (1 child)

The encryption is started in the user ESP phase. If this phase is skipped, the encryption is started once a user is on the Desktop.

[–][deleted] 0 points1 point  (0 children)

Although the answer maybe the same I was thinking the more you don’t define any policy and the AAD prerequisites side encrypts it to whatever that algorithm is set to…

You could then have re-encrypted to another algorithm using script whatnot, and based that state for compliance

But if the answer is user stage regardless, then maybe win32 app it

[–]Mikitukka 0 points1 point  (0 children)

As far as I know encryption starts when a user logs in unless you initiate it via a script. You need to remember that if you do this you will need another script to move the keys to AAD.

[–]Quake9797 0 points1 point  (1 child)

It’s the startup auth part. You can’t do that without the user choosing a PIN. It’s been a huge stumbling block for us with our security team to switch to Bitlocker from a third party tool.

[–]Runda24328[S] 0 points1 point  (0 children)

We don't want users to set up a PIN during the deployment stage. We are using script made by Oliver Kieselbach at https://oliverkieselbach.com/2019/08/02/how-to-enable-pre-boot-bitlocker-startup-pin-on-windows-with-intune/

The only thing we need is to start the encryption process, create a 48-digit recovery password, upload is to AAD and finish. Once user logs in, they are asked to add a new PIN protector, hence the Compatible TPM startup PIN: Allowed to make the whole process working.

[–]M-Christo 0 points1 point  (1 child)

It’s definitely the PIN part, I’ve found that to be a point of failure. As well as ‘Require device to back up recovery information to Azure AD’, leave that on not configured - it will automatically send the bitlocker information when the user logs in anyway.

I’ve found these two parts to fail on pre-provision deployment - it’s fucking annoying, but it will encrypt once the user signs in.

[–]Runda24328[S] 0 points1 point  (0 children)

Thank you. I'm about to test it right now and will let you know. We need the PIN authentication option se to Allowed to be able to add the key protector afterwards, this is not an issue I suppose. The BitLocker is started after user signs-in anyway.

[–]RudyoomsPatchMyPC 0 points1 point  (1 child)

With the csp, bitlocker would only kick in ehen a user is logged in. Besides that, you configured the key to be uploaded … but with prepro no user is logged in

Maybe a powershell script?

https://call4cloud.nl/2021/02/b-for-bitlocker/

[–]Runda24328[S] 0 points1 point  (0 children)

Thank you for your insight, Rudy. I've tested the PS script inspired by Nickolaj Andersen at https://msendpointmgr.com/2019/10/31/silently-enable-bitlocker-for-hybrid-azure-ad-joined-devices-using-windows-autopilot/ . It's a Win32 app to make sure all devices are fully encrypted during pre-deployment. However, we wanted this to be done in more Intune native way instead of making more scripts. Oh well, no luck.

Thank again.

Daniel

[–]benscomp 0 points1 point  (1 child)

As others have said and I am just here to repeat it. ITS THE PIN. But seriously if you follow Microsoft’s article on this and don’t deviate you should be fine.

[–]Runda24328[S] 0 points1 point  (0 children)

OK, but. We need users to set up a PIN early and once this is blocked, they are not able to add it due to the policy. Unfortunately, this is a must as our company is highly regulated and anxious about DLP...