For a modern workplace these days, Microsoft is enabling provisioning of devices without the need of managing the image that resides on the devices. With this new way of managing devices from a provisioning perspective, previous methods that administrators used to leverage to get a device into a desired state become obsolete. For provisioning a device today with the help of Windows Autopilot and have it being managed by Microsoft Intune supports two types of join scenarios, Azure AD join and Hybrid Azure AD join. The latter being recently added as a supported method to provision a device directly from a out of the box state and have it joined to an existing Active Directory domain but also registered in Azure AD at the same time, enabling all the benefits that comes along with such a hybrid scenario. Even though that an Azure AD joined device provides better management of new capabilities and features such as Windows Hello for Business or silently encrypting the hard disk on a device for standard users (users that are not a local administrator), not all organizations are able to make the switch to only Azure AD joined devices today for various reasons.
For whatever reason an organization decides to make use of a Hybrid Azure AD joined device provisioned using Windows Autopilot in their environment when moving away from traditional imaging based management, a huge disadvantage with this scenario is that there’s currently no way, as of today when writing this post, to silently enable BitLocker on the operating system volume. However, this is supported for standard users when you Azure AD join the device, and can easily be configured in an Endpoint Protection device configuration policy assigned to Autopilot enabled devices, as shown in the image below:
Standard users on a Hybrid Azure AD joined device would instead be prompted after they’ve logged on to start the encryption of the drive, which to some may be good enough, but for others won’t be an acceptable approach. For the past few years, many in the community have shared different approaches to solve this issue, or more specifically the issue of silently encrypt a volume with BitLocker when the device is managed by Microsoft Intune.
This post will provide all necessary information required to silently enable BitLocker for Hybrid Azure AD joined devices provisioned through Windows Autopilot. The solution is based on a PowerShell script that’s been created to perform the necessary actions such as enabling BitLocker on the current operating system drive with two key protectors (TPM and Recovery Password), escrowing the recovery password to the Azure AD device object, all being delivered as a Win32 application. Below is a high-level description of the steps this blog post will outline in order to accomplish the desired end result:
- Configure PowerShell script with desired encryption options
- Package the PowerShell script as a Win32 application
- Create the Win32 application in Microsoft Intune
- Configure Enrollment Status Page to track the Win32 application
Let’s dig into how we can configure all of this. But before that, grab the required PowerShell scripts for this solution from our GitHub repository:
Enable-BitLockerEncryption.ps1 script is the main script that will enable BitLocker and configure desired key protectors. This script will also wait for encryption to complete, once it has successfully been started. All of the main functions within this script is being logged to a file named Enable-BitLockerEncryption.log located in the C:\Windows\Temp folder.
Get-BitLockerEncryptionDetection.ps1 is a rather simple PowerShell script that’s going to tell the Intune Management Extension that the Win32 application was installed successfully or not. Since there’s no file being left on the system after the Enable-BitLockerEncryption.ps1 script has executed, or folders for that matter, not even a registry key being created to be used as a detection method, the detection script simply checks if the VolumeStatus property returned from Get-BitLockerVolume cmdlet is set as FullyEncrypted and if two key protectors (TPM and recovery password) are present.
Prepare PowerShell script before packaging
As the first task in this solution, the Enable-BitLockerEncryption.ps1 script needs some simply preparation. It’s been design to work without passing any parameters on the command, but it’s recommended that you make a decision if you want the script to enable BitLocker using the XTS-AES 256 encryption method, as that’s the default selection, or if you wish to use another method. These are the supported encryption methods that you can choose from:
- AES 128
- AES 256
- XTS-AES 128
- XTS-AES 256
Modify the param block of the script in a preferred editor, specifically the $EncryptionMethod parameter’s value, as shown below:
Save the script and with that there’s no further changes are required.
Package the script as content for a Win32 application
If this is the first time packaging a Win32 application, don’t worry, all steps required will be covered and the overall process if fairly simple. First of all, ensure that you have the latest version of the IntuneWinAppUtil.exe application, as that is the tool that will prepare the Win32 application package. You can grab the tool from the following URL:
Secondly, with the tool downloaded, create the following folder structure in a folder called IntuneWinAppUtil placed e.g. under C:\Tools. After that create two folder inside of the IntuneWinAppUtil folder named Source and Output. At this point the following file and folder structure should now have been created:
Place the downloaded and perhaps also the modified version of the Enable-BitLockerEncryption.ps1 script inside the Source folder. After that, open up an elevated command prompt and run the following command:
IntuneWinAppUtil.exe -c C:\Tools\IntuneWinAppUtil\Source -s Enable-BitLockerEncryption.ps1 -o C:\Tools\IntuneWinAppUtil\Output
Once the tool completes the content packaging, something similar to the following is shown:
Inside the Output folder, a new Enable-BitLockerEncryption.intunewim file has now been generated. This is the file that should be uploaded to Microsoft Intune in the next part of this blog post when the Win32 application is created.
Create the Win32 application in Microsoft Intune
Now that the script has been downloaded, potentially modified if to fit your organizations requirements, packaged as content for a Win32 application, it’s time to create the application in Microsoft Intune.
- Begin by logging into the Azure portal and locate the Intune blade.
- In the Client Apps blade, select Apps, click Add and select the Windows app (Win32) as the app type.
- Configure the App package file by browsing to the C:\Tools\IntuneWinAppUtil\Output folder and select the Enable-BitLockerEncryption.intunewim file.
- Click OK.
- Click on the App information section and configure accordingly. Enter a name, the description and publisher. A recommended name for the Win32 application would be Enable BitLocker Encryption. Optionally, locate a logo image for better aesthetics.
- Click OK.
- Click on the Program section and configure the following as the Install command:
- powershell.exe -ExecutionPolicy Bypass -File .\Enable-BitLockerEncryption.ps1
- For the Uninstall command, enter cmd.exe /c as we don’t really want this application to be uninstalled. Install behavior is important that it’s set as System, as a standard user will not have the required permissions to enable BitLocker when the script is executed. Configure the Device restart behavior with No specific action.
- Click OK.
- Click on the Requirements section and specify 64-bit as the Operating system architecture and select Windows 10 1607 as the Minimum operating system.
- Click OK.
- Click on the Detection rules section. This is where the second script, more specifically the Get-BitLockerEncryptionDetection.ps1, mentioned above in this blog post comes into play. Under Rules format, select Use a custom detection script and browse for the Get-BitLockerEncryptionDetection.ps1 script. Leave the two bottom configuration both set as No.
- Click OK.
- Click Add to complete the creation of the Win32 application.
Since this is a rather small application in terms of content size, the upload of the Enable-BitLockerEncryption.intunewim file should go fairly quick.
Before you continue to the next step in this post, remember to assign the newly created Win32 application with an assignment type of Required to your Azure AD dynamic group that contains all of your Autopilot devices.
Configure Enrollment Status Page to track the Win32 application
Next and the final required configuration for this solution to silently enable BitLocker on Hybrid Azure AD joined devices, is to configure the Enrollment Status Page so that it will track the Win32 application and not let the provisioning continue until it has been installed.
- From within the Intune blade of the Azure portal, go to Device enrollment and select Windows enrollment.
- Click on the Enrollment Status Page.
- Depending on if you’ve created a different profile here, select your custom one, but if not select the Default profile associated with All users and all devices.
- Select Settings and ensure that Block device use until these required apps are installed if they’re assigned to the user/device is configured with Selected.
- Click the Select apps button and select the Enable BitLocker Encryption application.
- Save the configuration changes.
Let’s recap what we’ve actually gone through in this blog post. The goal was to silently enable BitLocker on Hybrid Azure AD joined devices provisioned using Windows Autopilot. This is accomplished by using a script named Enable-BitLockerEncryption.ps1 that was packaged as a content file for a Win32 application to be deployed to Autopilot registered devices from Microsoft Intune.
Now that’s all sweet, but how would I know that this solution has worked as expected and how can it be verified? Locally on each device that was provisioned and targeted for the Win32 application created in this blog post, a log file is created. This has already been mentioned, but the contents of this log file should resemble something similar to this when this solution has successfully enabled BitLocker:
Hopefully this method of enabling BitLocker for standard users in the Hybrid Azure AD joined device scenario will not be required in the future, but as for now, there’s a solution available that gets the job done.