Introduction
Custom compliance settings in Intune, is a relatively new feature and is still in preview. However, the potential in this feature is enormous, and extends the possibilities for compliance policies almost endlessly.
- More on the feature from Microsoft Docs here: Use custom compliance settings in Microsoft Intune | Microsoft Docs
A similar feature released to ConfigMgr 2 years ago, and is something I also blogged about here:
To demonstrate how awesome this really is, I will give you something I intend to use in production once the feature goes GA.
The use case here, is to ultimately use this in combination with Conditional Access. We don’t force the Windows Hello for Business enrollment via the built-in and full-screen wizard. We believe that’s too intrusive. Instead we send out Toast Notifications to those users/devices, where WHfB is still not in use.
Custom Compliance Policy
The custom compliance policy consist of 2 parts; 1) a PowerShell script used for detecting the compliance state, and 2) a JSON file used to verify the compliance state. I suggest you have both of these ready, before moving on with the actual configuration in Intune.
PowerShell
The PowerShell detection script used for detecting if Windows Hello has been enrolled, can be found on my GitHub repository: PowerShell/Get-WindowsHelloStatus.ps1 at master · imabdk/PowerShell (github.com)
JSON
The JSON file used for verifying the Windows Hello enrollment status is found below:
{ "Rules":[ { "SettingName":"EnrollmentStatus", "Operator":"IsEquals", "DataType":"String", "Operand":"ENROLLED", "MoreInfoUrl":"https://imab.dk", "RemediationStrings":[ { "Language":"en_US", "Title":"Windows Hello for Business must be enrolled", "Description": "Windows Hello for Business must be enrolled" } ] } ] }
Microsoft Endpoint Manager
The further configuration of this, takes place in the Microsoft Endpoint Manager admin center: https://endpoint.microsoft.com in the Endpoint security -> Device compliance blade.
Create Detection Script
Start off by creating the mentioned PowerShell detection script:
Paste in the PowerShell code from my GitHub repository into the script area, and remember to configure the script to run as the logged on user:
Create Compliance Policy
Next up, create a new compliance policy based on custom settings:
Configure the newly created compliance policy similar to below:
- Select the Get-WindowsHelloStatus.ps1 (from my GitHub repo) script
- Upload the WHfB.json (copy/pasted from above) file
- Verify that EnrollmentStatus is equals ENROLLED
Assignments
Assign the compliance policy as you prefer. In my test scenario, I assigned it to a group containing my own user:
Compliance Results
Compliant
Once compliance is evaluated with Windows Hello properly enrolled, and the PIN provider therefore in use, you will notice your device reporting Compliant on the newly created compliance policy:
The compliance status is also logged into the IntuneManagementExtension.log located in: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
As per defined in our PowerShell script and JSON file, you will find the status ENROLLED when the device is compliant.
Not Compliant
Similar to when compliant, the IntuneManagementExtension.log will also tell you if the device it Not compliant and therefore produce an output of NOTENROLLED.
Final Notes
Prerequisites
In the official documentation on custom compliance setting, it’s currently and specifically mentioned that AADJ devices are required. It doesn’t tell if HAADJ devices works as well, but according to my testing both types of AAD join works just fine.
Pursuing true passwordless
If pursuing true passwordless, you can take additional measures in Windows, and disable the password credentials provider once the user/device is finally enrolled with Windows Hello for Business. More on that topic here: Passwordless Strategy – Windows security | Microsoft Docs
ENJOY 🙂
Martin,
Awesome post! You don’t happen to have the content of that other script/ json to go with what is listed as your first custom compliance script? I don’t see it in that github.
Get-BitlockerStatus
Great article! Thanks for the good info
Would you happen to have any scripts\json available for simple detection of an exe? We are attempting to validate our antivirus exe is running on a device for compliance and possibly virus definition version.
The only caveat for this situation would be detection runs every 8 hours.
Can you tell us what the status “not applicable” means ? Also this appear when the user used to launch the script is “system account”…