This is a post about enabling BitLocker on non-HSTI devices with Windows 10 version 1809 and standard user permissions.
First of all a little background on HSTI. HSTI is a Hardware Security Testability Interface. It is an interface to report the results of security-related self-tests. Its purpose is to provide high assurance validation of proper security configuration.
The enhancement with Windows 10 version 1809 is that we are able to activate BitLocker with a MDM policy (Intune), even for non-HSTI devices and on Windows 10 Pro Edition. This was not working with Windows 10 version 1803 or lower and the community came up with custom solutions to handle this like custom PowerShell scripts deployed via Intune Management Extension. If we wanted to use Intune native MDM policies via the BitLocker CSP we needed HSTI compliant devices like the Surface devices or newer hardware devices which are mostly delivered as HSTI compliant devices now. To successful start the encryption as a standard user, a Windows 10 version 1803 was the minimum as the feature was introduced with this version.
The prerequisites for Intune BitLocker configuration are:
Windows 10 version 1809 Enterprise and Pro
Azure Active Directory joined devices
Older devices can be protected by Intune BitLocker policy now?
Yes, as long as they are running Windows 10 version 1809. The most common problem is that we do not replace all devices in every Windows 10 project to have only latest HSTI compliant devices in the environment. We have to support older devices purchased maybe not long ago but not HSTI compliant. These devices can now be managed by an Intune device configuration policy to turn on BitLocker silently without administrative permissions as long as the device is a Windows 10 version 1809 device.
What do we need to do?
Currently at the time of writing we need two configuration policies. One endpoint protection profile and a custom profile.
The endpoint protection profile configures the silent BitLocker enforcement and other parameters like encryption strength. Go to Microsoft Intune > Device configuration – Profiles > yourpolicyname – Properties > Endpoint protection > Windows Encryption
Set Encrypt devices to Require Set Warning for other disk encryption to Block
Sure you can set other parameters like encryption methods as well, but for a functional test this is enough.
These two settings make sure the encryption starts and it starts silently as we block the warning dialog for other disk encryption software.
Example shown below:
The second profile is a custom profile (at time of writing it was not available in the UI) and it configures the ability to enforce the BitLocker encryption even when standard users are logging in. For example when the Windows 10 device is enrolled with an Autopilot profile where the user account type is set to standard user. AllowStandardUserEncryption is a new setting introduced with Windows 10 version 1809 BitLocker CSP and must be used in conjunction with the setting “Warning for other disk encryption set to Block” otherwise it is not functional!
The custom OMA-URI configuration must be configured like this:
Data type: integer
Example shown below:
See the Update section below for a new UI setting available in Intune 1901 release.
The two policies must be assigned to a user group or device group to test the new policies. To force the user type to a standard user after enrollment we need an Autopilot profile and assign it to our device.
If we now enroll a new Windows 10 version 1809 non-HSTI device it must be encrypted silently and the recovery key must be backed up to Azure AD.
How can I easily verify this?
I used a Hyper-V VM Generation 2 with an enabled TPM module:
During my test I had to make sure that after the first restart, the Windows 10 version 1809 ISO is ejected, otherwise silent BitLocker encryption will fail. This is because the system does not have the normal start parameters during the BitLocker and TPM provisioning. The platform would take into account the additional media as the normal platform verification parameter. Which means after ejecting the ISO it would have prompted us for the recovery key. Microsoft takes care of this situation and does not start the BitLocker provisioning process at all. So, the generation of the platform default configuration parameters for later verification to unlock the TPM is prevented, as long as a removable media is inserted. See the failure event here:
Without an ISO it will successfully starts the encryption and key backup to Azure AD. A success event is shown below:
The BitLocker state can be verified with the PowerShell command on the client:
Get-BitLockerVolume | fl
In the Intune portal we can see the recovery key appended to the AAD device object:
Since Intune January 21th 2019 Release (aka 1901) we are able to configure the BitLocker Allow Standard User setting via UI element:
Microsoft made it finally happen and provides an integrated way to deploy Win32 Apps via the Intune Management Extension. This is by far the biggest step forward in the Modern Management field. Until now the community came up with lots of ways to utilize PowerShell scripts to finally install some Win32 Apps. By doing this you need to take care of the content location, availability, distribution, the app install, and verification logic. All this is now available in the enhanced Intune Management Extension. As a short refresh regarding Intune Management Extension, I recommend to read my blog articles about it, where you find a lot of information regarding the architecture, the inner workings, and troubleshooting advises:
Both articles are very relevant to this new feature as they all describe the architecture and technical details regarding the Intune Management Extension itself. Exactly this Intune Management Extension is used now for deploying Win32 apps packaged as .intunewin file format. It’s even better, the new functionality can be used to basically transport everything in a package and trigger a certain command line for execution. This is not a end to end walk-through how to use the feature in regards of the Intune portal or on the client itself. For this check out other great articles found in my last section End to end usage walk-throughs?. This is an article all about the inner workings of this new capability, a deep dive into the new technology itself.
To get a Win32 apps deployed via the Intune Management Extension we first need to package the content we want to distribute. Microsoft decided to use the same approach like they did for the macOS world, where they provide a small tool to create the packages – Microsoft Intune App Wrapping Tool for macOS. A similar tool to create these packages is available for the Windows world now. This tool is called:
For all of you with ConfigMgr experience, the new feature to deploy Win32 apps with Intune can be compared a little bit with the Packages and Programs functionality within ConfigMgr, but with some additions.
The usage of the Microsoft Intune Win32 App Packaging Tool (IntuneWinAppUtil.exe) is quite simple. We specify a folder and the executable and create then an yourappname.intunewin file. This is our packaged app which we then can upload to the Intune service. The command line of the tool is this:
IntuneWinAppUtil -c -s -o <-q>
To dig a little deeper we inspect the resulting package in detail now. After successful execution it will generate the .intunewin file from the specified source folder and setup file. For MSI setup files, this tool will retrieve required information for later usage in the Intune portal. To explore this a little bit I captured the output and highlighted some important facts there, to gain understanding how the tool is working.
As seen the tool is executed with the necessary parameters to create a package for Google Chrome Enterprise Edition Browser, which is provided as a .msi file. A sub folder called Chrome is in the same folder as the IntuneWinAppUtil. The command line then is:
A detailed review shows us the file and encryption information and in addition the MSI file information. This information is used by the Intune portal to pre-populate some Intune app definitions for us.
The MSI information is only available when a msi file is packaged. If we package a setup.exe for example you will not see the entire section in the detection.xml file.
This is pretty simple to explain. The portal and the Intune service gets all necessary information to deal with the app (in this case Google Chrome). The msi information listed in the detection.xml is used to simplify the setup within the Intune UI by pre-filling the app form during creation. For example by adding the install and uninstall commands for the msi automatically:
The EncryptionInfo is used to store it with your Intune tenant to gain access to the uploaded .intunewin package. The encrtypted .intunewin (located in the content folder) can be distributed safely to the Intune back-end services responsible for content distribution without getting exposed to others, only the tenant who uploaded the file has the EncryptionInfo and can decrypt the file.
Where can I find details of the Win32 App deployment?
The Intune Management Extension tracks some details of the Win32 apps in the registry at: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Apps\
The yellow highlighted names provide us the execution commands for install and uninstall and the attempts and results of it.
If we look at the green highlighted GUID at HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\73d664e4-0886-4a…we can see it matches my Azure AD user object ID. To compare it I got the details via Azure AD PowerShell:
The red highlighted GUID (b0f62b79-e464-4f95-afe2-ed99eb612fe5) is the application GUID which is assigned by the Intune service back-end. This can be easily traced by looking at the graph data with the Graph Explorer from Microsoft:
In my example I used this to retrieve the details of my uploaded app:
we can find some interesting folders where the agent is downloading the content and detection scripts and stores the actual MSI log files:
Agent execution context when processing .intunewin files?
The agent is bound to the same restrictions during execution like we know them for PowerShell scripts, meaning the calling process (the Intune Management Extension agent) is a 32-bit process. This can result in some unexpected behavior. For example when trying to package a simple .ps1 file within a .intunewin and trying to execute cmdlets in this scripts which are only available in a 64-bit environment. We then have to use a technique to restart the PowerShell script as a 64-bit process. This is described in my previous articles and I have built a Intune PowerShell script template to simplify the start for this, which can be found on my GitHub here https://github.com/okieselbach/Intune/blob/master/ManagementExtension-Samples/IntunePSTemplate.ps1. This can also affect installers packaged as .intunewin when they assume a 64-bit environment! For PowerShell execution Intune added a UI element to control 64-bit execution, but this is not available for Win32 apps and therefore the re-start technique must still be used here.
If no restart technique is used keep in mind that environment variables must be handled with care from 32-bit processes. For example if you like to target the %windir%\System32 environment from a 32-bit process you have to use %windir%\Sysnative otherwise you will land in %windir%\SysWOW64. Visit the linkt to read more about the file system redirector: https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector
What are the retry and execution intervals?
The agent has default values for retry and execution: