Are your employees rebooting their devices from time to time and you don’t know what to do about it? Relax, I have an idea to solve your problem - Custom Compliance Policy in Intune.
Let’s create a new policy in Microsoft Intune to flag forgetful users’ devices and block their access to Microsoft 365 services. Are you ready? Let’s get started!
But why?
Where did the idea for such a policy come from, and why is IT making a big deal out of nothing? That’s a good question! Why do we need to force employees to reboot corporate devices on a regular basis? Let’s make a list of potential problems.
- What should you do before sending a request to IT? - Reboot your computer. Your problem may magically fix itself before you submit the ticket to IT, just by doing this one specific action 🪄
- Some drivers and applications require a reboot after installation or update, and we always want to have the latest software on company computers.
- Group Policy settings, Task Scheduler and other actions set to run on device startup or shutdown will not work because the computer is not shut down or restarted!
I think that’s enough. If you’re someone who doesn’t shut down your computer regularly - please start 🥺 And if you are on the other side, and you want to force your employees to reboot their corporate devices on a regular basis, I invite you to read on.
Possible problem solutions
Let’s think about how we can encourage our employees to restart their devices regularly.
- Notifications in corporate communication tools, such as the internal intranet, email, Microsoft Teams, Yammer, or other evil HR tools, and a message from IT to turn off the corporate PC after work.
- System notifications to users prompting them to restart the device after exceeding the maximum device activity time. Psst: For more examples of PowerShell notifications (toast notifications) click here.
- Automatically force the computer to restart when the maximum time for device activity up time is exceeded.
Does it work? Option #1 will, but only for people who read such messages and are polite enough to follow them. Option #2 without enforcing option #3 will usually not work. Users often don’t pay attention to such notifications and don’t know that there is such a thing as a Notification Center (who would look there? 🙃). On the other hand, the most effective option #3 can lead to loss of employee data if IT forces a reboot and the user doesn’t save anywhere that super important company presentation he/she has been working on for hours!
So you need to find a solution that encourages employees to restart their computers while minimizing the risk of losing corporate data. This is where today’s solution comes in - Custom Compliance in Intune and Conditional Access 🙂
A recipe for problematic users
What is our devil’s plan?
Company devices are subject to compliance policies in Intune. If a corporate computer lacks encryption or has its firewall disabled, Intune will mark the device as non-compliant. Sounds like something we’d like to use! If an employee’s computer is in use for more than 7 days, let’s mark it as non-compliant and block access to cloud applications.
What’s more, evil IT gives you the ability to solve the problem yourself via status and instructions in the Company Portal. Important files can also be saved locally before rebooting!
Custom Compliance Policy
How does our policy today differ from other built-in policies in Intune? The difference is cosmetic - instead of pre-built settings and switches in the admin center, we have to build the logic (PowerShell script) and messages to employees (JSON) in the Company Portal ourselves. This gives us more options to verify compliance, but also requires more work.
The Custom Compliance Policy has two elements:
- Discovery script - is a PowerShell script that checks the compliance of a given device and reports back to Intune.
- Custom Compliance Settings JSON - is a JSON file that contains messages for the user and a description of the parameters used in the discovery script for Intune.
No worries! No one is going to force you to code here. I have already prepared both files for today’s policy. You can find them in my repo on GitHub.
Configuration
It’s time to create our work of destruction! But before we begin, remember that both conditional access and Intune use require appropriate licenses.
And according to blog’s FAQ, you are the only one responsible for any changes in your production environment - I won’t accept any complaints.
Scripts
Download the following files:
and customize it to suit your needs. By default, the discovery script marks devices that have not been rebooted in over 7 days as non-compliant.
Discovery script
Navigate to: Microsoft Intune admin center and select: Devices -> Compliance policies -> Scripts. Then click Add > Windows 10 and later.
Enter the name and description of our script (optional). We will use this name later for the new compliance policy.
Then go next (to the Settings tab) and paste the DeviceRebootedWithin7Days_Discovery.ps1 file contents.
Set the remaining settings to:
- Run this script using the logged on credentials: No
- Enforce script signature check: No
- Run script in 64 bit PowerShell Host: Yes
The last step (Review + Create tab) is to verify that all settings have been configured correctly. Confirm the changes by clicking the Create button.
Done - the discovery script is in place. Now we need to create a new compliance policy that will use it to check the compliance of our devices.
Compliance policy
To create a new compliance policy navigate to: Devices -> Compliance policies -> Policies and select: +Create policy.
Choose Platform: Windows 10 and later. The Profile type should automatically set to Windows 10/11 compliance policy.
Again, enter the policy name and optional description. Next, go to the Compliance Settings tab, expand the Custom Compliance category, and configure:
- Custom compliance: Require
- Select your discovery script: Script created in previous step - in my case Discovery-Windows-DeviceRebootedWithin7Days.
- Upload and validate the JSON file with your custom compliance settings: Select the downloaded DeviceRebootedWithin7Days_ComplianceSettings.json file.
The next step is to set the policy actions. Of course, we want Intune to mark devices that haven’t been restarted in the last 7 days as non-compliant.
Make sure the Mark device noncompliant action is set to 0 (Immediately) and go next.
Time to assign our policy
Although the Add all users and Add all devices options are tempting, for testing purposes it is better to select a specific group of test users - we don’t know who else is using our test environment and we don’t want to mess things up 🙃
Select the test user group and continue.
The last step (Review + Create tab) is to verify that all settings have been configured correctly. Confirm the changes by clicking the Create button.
Done! Time for testing!
Tests
Policies have been created, now it’s time to test. Go to your test machine or device and wait until time since system up time exceeds 7 days…
…or if you’re a bit impatient (like me), you can adjust the values in the script to speed up the process.
Speeding up the script
Set the variable: $maximumDays to 1 and switch method in $lastRestartDays from .Days to .Hours.
After these minor changes, your machines should be marked as non-compliant after only an hour of device operation!
Now all we have to do is wait until our test machine exceeds one hour of up time and becomes non-compliant with our policy.
It’s time to check your computer’s compliance. First, let’s check the computer’s up time in Task Manager.
It looks good! Let’s go to Company Portal and check the device’s compliance status:
Success! Our computer became non-compliant and the user received a message stored in our policy settings.
It’s time to open the champagne and recap what we configured today 🥂
Before that, let’s go through a short FAQ, because in the middle of your testing, you may run into problems I haven’t mentioned yet.
Potential problems and FAQ
Blocking access to company resources
The Not Compliant status in Intune alone does not block access to Microsoft 365 services or other integrated applications with Entra ID. If you want to block non-compliant devices, you must create a new conditional access policy.
Manual
Navigate to: Microsoft Entra admin center and select: Protection -> Conditional Access -> Policies. Then create a policy with the following conditions:
- Users
- [Include]: Specify the group that contains your test users that you want to deny access to.
- [Exclude]: Exclude your account and Break Glass Accounts
- Target resources: Select All cloud apps
- Conditions: You don’t need to select anything, but it’s a good idea to set Device platforms = Windows since we configured the policy for that platform.
- Grant: [x] Grant access + Require device to be marked as compliant
- Enable policy: On
Done. Access to corporate resources will be blocked from devices with Not Compliant status.
Fast startup - Incorrect computer up time
When testing policies or scripts, you may find that your device still reports non-compliance even after a reboot. Why is this happening? The culprit is a setting called fast startup, which prevents the device from performing a full reboot, but increases its boot speed!
Starting with Windows 8.x, the default shutdown and restart scenario has been updated and named fast startup. Fast startup begins with the shutdown process and includes writing data to disk similar to the hibernate process. A key difference is that all user sessions (Session 1) are logged off and the remaining information is written to the hiberfile. When you boot the PC from this state, Windows loads the previously initialized state by reading from the hiberfile, instead of running the full boot process in which Windows, drivers, devices, and services are initialized. This method speeds up the process of initializing the lock or Start screen.
— Microsoft Docs - Delivering a great startup and shutdown experience - Fast startup
So the Shutdown option in the Start Menu doesn’t always mean a complete shutdown of the computer…
If you want to change this default Windows behavior, I recommend disabling fast startup before implementing the policy described in this post.
BTW: Wake-on-LAN also doesn’t work with fast startup enabled 🙂
Device policy and compliance sync
Custom compliance policies in Intune behave slightly differently than built-in compliance policies. What I am referring to here is the amount of time it takes for Intune to run the discovery script the first time, and then again.
According to the documentation, the device’s compliance is synchronized every 8 hours. Unfortunately, this isn’t joke… which is why Custom Compliance is not suitable for checking the settings that we need to read and report in real time.
When a Windows device receives a compliance policy with custom settings, it checks for the presence of Intune Management Extensions. If not found, the device runs an MSI that installs the extensions, enabling the client to download and run PowerShell scripts that are part of a compliance policy, and to upload compliance results. Actions managed by the services include:
- Checking for new or updated PowerShell scripts every eight hours.
- Running the discovery scripts every eight hours.
- Running scripts that download when a user selects Check Compliance on the device. However, there is no check for new or updated scripts when Check Compliance is run.
It is not possible to push notifications to a device to enable custom compliance to run on demand.
Manual verification
After we click the Check Compliance button in the Company Portal, the Intune Management Extension checks our machine compliance against the custom compliance policy and reports it to Intune using a copy of the discovery script stored locally on the device.
However, this is a manual action - the employee must click Check Compliance or the default schedule of 8 hours will apply.
Wizards can work around this problem, but let’s face it - we don’t want to use such tricks in production environments if we don’t have to.
Conclusion
Congratulations, you made it to the end of the post. Now it’s time for a little recap:
- We were able to configure a custom compliance policy in Intune - well done!
- The policy was correctly applied to our machine and we were compliant with the new policy.
- After an hour (actually, after two hours and forcing a sync), our test device received a non-compliant status, which was reported in Intune and the Company Portal.
- No animals were harmed during our testing.
And now it’s time to say goodbye and… New Year’s wishes!
In the coming 2024, I wish you, my dear readers, lots of energy for exciting future projects, much faster Intune policy syncs, and lots of patience and colleagues who don’t open all the links in the messages they receive 💣
See you in a year and in future posts!