Managing Windows Bitlocker Compliance Policy Using Intune | MS Graph | Grace Period

Today’s topic is managing Windows Bitlocker compliance policy using Intune and MS Graph. In this post, I will detail how I currently manage the enforcement of Bitlocker encryption via Intune compliance policy. 

I am not going to cover how to implement or troubleshoot Bitlocker with Intune/AutoPilot as there are already many very good guides on how to do that:

• Encrypt Windows devices with BitLocker in Intune – Microsoft Intune | Microsoft Docs
• Bitlocker Unlocked With Joy – Behind The Scenes Windows 10 – Part 1 HTMD Blog (anoopcnair.com)
• Enabling BitLocker on non-HSTI devices with Intune – Modern IT – Cloud – Workplace (oliverkieselbach.com)

For the purposes of this post, I am going to assume you already have Bitlocker deployed and working.

Bitlocker Compliance Policy Settings in Intune | MEM

So why am I writing about Intune compliance for Bitlocker and how can that be problematic? As you may already know there are currently two different mechanisms for evaluating Bitlocker encryption as part of an Intune compliance policy. 

These settings are “Require Bitlocker” under Device Health and “Require encryption of data storage on device” under System Security.

The “Require Bitlocker” setting uses the Windows Health Attestation Service to evaluate Bitlocker compliance.  One of the advantages of this setting is that a device is evaluated as compliant whilst the drive is still being encrypted.  There is no need to wait for that process to complete in order for the device to be marked as compliant in AAD/Intune. 

It is also considered more secure. However, the downside of this setting is that it relies on boot-time evaluation and therefore a reboot is required after AutoPilot enrolment in order for the device to be marked as compliant.

The advantage of the “Require encryption of data storage on device” setting is that it does not require a reboot to evaluate Bitlocker compliance. However, the downside is that devices are not evaluated as compliant until the drive is fully encrypted.  If you are using device compliance as part of a conditional access policy then users can be blocked from accessing corporate resources such as Office 365 or VPN until the encryption process has been completed.  Whilst this usually completes in around 20-30 mins I have seen some instances where the process hangs for long periods of time.  This then causes extended delays in users being able to access corporate resources resulting in calls to the helpdesk.

If you want more details on how the compliance evaluation works under the hood for both of these settings take a look at Joy’s deep dive post here: Intune compliance evaluation for Bitlocker – How it works? (joymalya.com)

So neither option really provides a great user experience, one forces a reboot and the other can cause significant delays in users being fully productive (when combined with conditional access).  So I did some research on this to try and find a way of implementing Bitlocker without the need for a reboot but also allowing users to start accessing corporate resources as soon as they land on the desktop after AutoPilot enrolment had completed.

Intune Actions For Noncompliance and Grace period

I stumbled across a potential solution for this whilst looking into using MS graph for managing compliance policy.  As you probably already know Intune has an “Actions for noncompliance” feature which allows you to configure actions to take x days after noncompliance. 

The default is to mark devices as noncompliant immediately but you can also use this feature to send a notification to users warning them and then mark the device as noncompliant a few days later.  This is commonly referred to as a “grace period” – giving users a period of time to remediate their device before their access to corporate resources is blocked.

However, this is what I spotted in the MS graph docs 😉.

The grace period is stored within the service in hours, not days.  When I first discovered this a couple of years ago it wasn’t possible to set the grace period to a decimal fraction of a day via the Intune portal.  You could only set the grace period to whole days so the minimum period was 1 day. However, this has since changed (not quite sure when) and the Intune docs now reflect that.

Configuring the Intune Compliance Policy Grace Period in Hours

So this gave me an idea about how to handle the Bitlocker use case.  Whilst the “Require Bitlocker” setting is considered a little more robust I wanted to avoid the reboot requirement.  However, using the “Require encryption of data storage on device” setting combined with a short grace period would provide a seamless experience for end-users.  As the device will be in the grace period the user would not be blocked from accessing corp resources by a require compliant device conditional access rule.

The short grace period would be just enough time to allow Bitlocker encryption to complete.  This would allow users to be fully productive as soon as enrolment has been completed whilst Bitlocker encryption continues in the background.  A 1 day grace period was not acceptable from a security perspective but 1 or 2 hours seemed to strike the right balance between security and user experience.

I did some testing with this and found that I could create a compliance policy via MS graph with a 1 hour grace period.  In fact, when I first implemented this a couple of years ago the Intune portal showed the grace period in minutes/hours even though back then you could only enter whole days when creating/editing a policy.

This changed a while ago (probably at the same time that the Intune portal started to support decimal fractions of a day) and it now displays it in days.

As I mentioned above the Intune portal now does allow you to enter decimal fractions but only specific values are supported.  If you enter 0.04 days (1 hour) then you will get an error when trying to save the policy.

Using MS Graph to Configure BitLocker Compliance Policy Grace Period in Hours

So to configure 1 hour you need to use MS Graph.

Here is a sample PowerShell script (uses Intune PowerShell SDK) you can use to create a compliance policy for Bitlocker with a 1 hour grace period.  You can change this value to any number of hours but 1 is usually sufficient. Just change the -gracePeriodHours value from 1 to 2 if you need to increase it to 2 hours.

Connect-MSGraph
$Win10Compliance = New-IntuneDeviceCompliancePolicy `
    -windows10CompliancePolicy `
    -displayName "Win10-Compliance-Bitlocker" `
    -storageRequireEncryption $True `
    -scheduledActionsForRule `
    (New-DeviceComplianceScheduledActionForRuleObject `
        -ruleName PasswordRequired `
        -scheduledActionConfigurations `
        (New-DeviceComplianceActionItemObject `
            -gracePeriodHours 1 `
            -actionType block `
            -notificationTemplateId "" `
        ) `
    )

If you want to test this out just run the PowerShell script to create the policy and then assign it to a user/device group.  After creating the policy you will see the grace period as a decimal fraction in the Intune portal. You can also check via MS Graph that the grace period is definitely set to 1hr.  The easiest way is to just run the following query in MS Graph Explorer:

deviceManagement/deviceCompliancePolicies/{replace with your compliance policy id}?$expand=assignments,scheduledActionsForRule($expand=scheduledActionConfigurations)

Just make sure that if you are currently using “Require Bitlocker” to remove that from any existing compliance policy.

You can edit and make other changes to the compliance policy via the Intune portal, the grace period will stay set at 1 hour.

The policy works exactly as expected, devices are marked as “in grace period” immediately after enrolment and users can access corporate resources immediately.  They are no longer blocked by any conditional access policies requiring a compliant device whilst Bitlocker encryption continues in the background.

As long as the Bitlocker encryption process completes within the grace period then the device is marked as compliant and the user can continue to work.  If for some reason Bitlocker does not complete the encryption process within the grace period then the user is still blocked as expected.

Additional Tips – Intune Compliance Policy Grace Period

Another consideration is that you may not want to have the same actions for noncompliance/grace period for other compliance settings such as TPM or Antivirus.  The approach I use here is to split the “Require encryption of data storage on device” setting into its own separate “Bitlocker compliance policy”. 

You can have multiple compliance policies with different compliance settings in each one all targeted at the same user/device – this allows you to customise the noncompliance actions and grace period for those specific settings as the actions are tied to the policy. 

For example, you can continue to enforce “mark devices noncompliant immediately” for all other compliance settings except for Bitlocker where you allow 1 hour for the encryption process to complete.  However, if you do have multiple policies with actions that send notifications to users just be mindful of not spamming end users as per the Intune docs 😃.

I have been using this solution in production for some time now and it has really helped improve the end-user experience and reduce calls to support.  If you are enforcing Bitlocker via compliance policy and also block access to resources from noncompliant devices through conditional access how are you managing this today?  Let me know in the comments!

Author

Mark is a Modern Workplace Solutions Architect based in the UK with more than 23 years of experience working in IT. He has been working in enterprise desktop management since the start of his IT career with a focus on OS deployment with SCCM/MDT. Since 2015 he has been working on Enterprise Mobility and modern management of Windows with EndPoint Manager/Intune. Twitter -> https://twitter.com/Mark_Thomas73.