One of the great features of AzureAD is that when a device is joined it can be automatically encrypted with Bitlocker and the recovery key can be stored against the device within AzureAD. However this is only true for devices which support ‘InstantGo’ which is low power state found in a very small number of devices, such as Surface Pro 3 and 4.
What you don’t want to happen is find that other mobile devices are connected to your AzureAD but not encrypted. Fortunately Jan Van Meirvenne reverse engineered the process and has posted a PowerShell script which will enable the TPM, invoke Bitlocker and store the key to AzureAD.
You can find his blogpost and the script here.
However, how are you going to automate the running of this script? If you are enrolling Windows 10 devices into AzureAD and then into Intune using the MDM channel you will find that you cannot deploy scripts via Intune. Not only that, you cannot even deploy an .exe file (you could easily convert the .ps1 to .exe) so that method is out the picture. At present all you can deploy is .msi files and MDM based policy.
Fortunately in my organisation we use DesktopNow from Ivanti (formerly AppSense). Environment Manager is able to execute scripts of any kind at any trigger point and can use logic to determine if the script needs to be run.
First we can create a custom condition to check if Bitlocker is not yet enabled. Environment Manager expects a return code of zero for success (condition evaluates true) so we’ll test for protection in a state of “Off”.
If this condition determines that Bitlocker is not enabled we simply run the script provided by Jan Van Meirvenne to enable it by using a custom action which runs in the System context:
In this configuration I’ve added the test and the action to the Desktop Created node but you can of course use any available trigger. By running it regularly either at logon/startup or on a schedule you can ensure that if the user disables Bitlocker (AzureAD only users will have admin rights by default) it will become re-enabled next time the condition runs.
The Environment Manager agent and Environment Manager configuration can both be deployed via MSI so these will work nicely with MDM only Windows 10 Intune devices. By utilizing the Environment Manager engine you pretty much get back a level of control which you had with classic domain join devices such as applying ADMX policies, setting registry keys etc.
In the future I will cover how the Application Manager agent can be used on AzureAD devices to restrict local administrators from doing things they shouldn’t.
Alex Pooley EUC Blog 