Monday, January 24, 2022

The Last Days of Custom Compliance

Must read

Rudy Ooms
Rudy is a Modern workplace architect and currently working for a company in the Netherlands, called Deltacom Steenbergen. He has been working in IT since he was 16 years old. Within these years, he gained a lot of experience in different kinds of expertise. I guess like most of you, he started working with active directory environments. In June 2021 he received the MVP status in the category Enterprise Mobility for the first time. The multi-tenant PowerShell scripted Deltacom-Cloud environment is one of his creations.

This blog will show you the nice wonderful addition to Intune, called the Custom Compliance Policy. This blog will be updated along the way as it’s new and this blog is just describing my own first attempts with these custom compliance policies and my opinions!

With the custom compliance policy, it’s (should be?) way easier to measure compliance.

  1. The Custom Compliance policy
  2. The PowerShell Detection Script
  3. The JSON
  4. The Results
  5. Some important stuff
  6. Conclusion

I guess everybody read my blog about device health attestation and how BitLocker is measured and how you could solve this issue.

But now with the new custom compliance policy options, we have another solution at our disposal. With the use of Custom Compliance Policies (for Windows) we now have the option to write a simple PowerShell detection script to (I guess that’s obvious about a detection script) detect any setting we want to detect.

For example, if services are running, if specific files exist or if Bitlocker is enabled and configured the way we want it to be.

The Powershell Detection Script will “return” the output of the PowerShell script in a JSON format to Intune/Microsoft Endpoint Manager. In the Custom compliance policy, we also need to define a JSON file. This JSON file will be used by Intune and will be compared with the PowerShell script output it got.

This JSON file will also be used to provide the end-user with a message on how they could “remediate” those messages. Mmm… Detection… Remediation… That’s sounds familiar, doesn’t it?

So to set it up we need a PowerShell Script and a JSON file

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Okay, let’s start with the PowerShell Detection script. In the first part, I showed you some examples you can use with Custom Compliance Policies. In this blog, I will show you a simple script to monitor for Bitlocker Compliance.

What settings do we need, when we want to Monitor our BitLocker compliance? Let’s check out what kind of settings we have. We can check out the BitLocker settings with this command: Get-Bitlockervolume

So looking at the picture, I guess the EncryptionPercentage and ProtectionStatus will be fine (for now)

Afbeelding met tekst  Automatisch gegenereerde beschrijving

So how do we know what Setting Name we are going to monitor and use? Like an example, I am monitoring the Percentage and Protectionstatus for compliance

Afbeelding met tekst  Automatisch gegenereerde beschrijving

The only thing you need to do, when you want to check out the values we need for compliance monitoring is just export the good values on a working device first!

For example, First I am exporting all the BitLocker information on an already BitLocker working and enabled device.

Like I showed you at the beginning of the blog, you will need to return the PowerShell output in JSON format. To do so we only need to return the variable ($) and convert it to JSON (Convertto-JSON). Please make sure you are also using the -compress option to make sure the output results are returned in one line.

Let’s take a good view of all the settings first with the knowledge we know now.

But I guess we don’t want to monitor everything for compliance only a select few. So I am adjusting the get-bitlockervolume to only show us the encryption percentage and protectionstatus

$BLinfo = Get-Bitlockervolume

$hash = @{Percentage= $BLinfo.EncryptionPercentage; ProtectionStatus = $BLinfo.ProtectionStatus}

return $hash | ConvertTo-Json -Compress

Looking at the picture above… that is way better to read! Of course, you could also add the “encryptionmethod” if you want to make sure your devices are compliant to match the XtsAes.

As an example, you want to use XtsAes256 and get your device NOT compliant if they are encrypted with XtsAes128

So let’s create the required PowerShell script first

We can now simply create a new PowerShell script and copy-paste the contents in the detection script part.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Now we have the PowerShell script ready. We need to also configure the JSON file itself to import in Intune. Otherwise, Intune only has the returned values but nothing to compare it with…

Let’s take a look at the JSON File first

             "Title":"Bitlocker Hard Drive must be fully encrypted",
             "Description": " Bitlocker Hard Drive must be fully encrypted "
             "Language": "en_US",
             "Title": "Bitlocker protection must be enabled.",
             "Description": " Bitlocker protection must be enabled.","

You will notice some important “fields” in the JSON file:

SettingsName: The setting we noticed in the PowerShell output

Operand: the value we noticed in the PowerShell output after the setting name



Create a JSON file for custom compliance settings in Microsoft Intune | Microsoft Docs

So when creating the PowerShell script and getting the returned values, you will need to take a good look at which datatype you are using and how you are comparing it. Like an example, I guess the Bitlocker Encryption Percentage needs to be equal (IsEquals) to 100 (Int64)

You could also configure some nice remediations messages to make sure your employee knows what broke and how to fix it (even when they probably don’t have the permissions to do so..)

“Title”: “Bitlocker Hard Drive must be fully encrypted”,

“Description”: ” Bitlocker Hard Drive must be fully encrypted “

I will divide this part up into 2 subparts

  1. The Results When it’s compliant
  2. The Results when I break bitlocker

4.1 The Results when it’s compliant

The first time, I deployed the Compliance Policies.. all the devices were showing as “Not Applicable”

The assignments were good, normally the not applicable can also be due to Licensing issues. If you were following my tweets you know that there is a sort of warning when deploying these Custom Compliance policies

But for now, that is something you don’t have to think about….yet. The only thing you need to do is, rebooting your device and after a while, they will get applicable.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

4.2 The Results when I break Bitlocker

But what happens when your device isn’t compliant anymore? Let’s find out for ourselves by disabling Bitlocker (I know.. I am running this as admin as a normal user isn’t allowed to do this)

Afbeelding met tekst  Automatisch gegenereerde beschrijving

So I pressed the Check Access button and waited….

Afbeelding met tekst  Automatisch gegenereerde beschrijving

That’s weird… It is still compliant, even the agentexecutor is telling us the last check was 07:47 (when I booted my device today)

Also the results in the report section of the SideCarPolicies Scripts


The results are telling us it is still good to go and it is showing is no weird error codes

Even rebooting the device or stopping/starting the intune mgt service didn’t trigger anything.

Detection and remediation….. Detection and remediation…Scripts…. Scripts Ow wait.. then it will use the HealthScripts in the IMECache folder just like Proactive remediations!

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Of course, like always the execution of the Health Script is also visible in your IntuneManagementExtension amnd agentexecutor logs

There are some rules we need to beware of!

  • Like I told earlier… when deploying Custom policies, your devices need to reboot before something will happen!
  • When updating the existing/changing PowerShell script in you compliance policy, it can take up to eight hours before it works!
  • The discovery scripts are run each 8 hours… so does that mean your device can be compliant for 8 hours even when it’s not compliant? I guess you know the answer when looking back at the results!
  • You can manually check your device to see if its compliant, but there is no check to fetch the latest updated PowerShell scripts. I guess that means, just create a new compliance policy instead of changing an existing one?

I love the idea… but my first experience with it wasn’t that great… it felt a little bit buggy. But after some time it was working.

But why….why, 8 hours before the detection script is relaunched? In my opinion, this is the main reason I am not going to use it as I want it to fail within a few minutes… not a workday! And combine that 8 hours with probably an additional license to use it??

Mmmm I really hope I can dig into it later on today to find a solution for this. As waiting 8 hours before the device could fail compliance is not my “thing”

But don’t get me wrong, I totally love the idea of creating your own compliance policies… but for now, I am not filled with joy (yet?)

So I am not quite sure what to think about it as the DHA is rock solid, sometimes too solid.

Im Not Quite Sure GIFs - Get the best GIF on GIPHY

More articles

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Latest articles