Today we’re going to have a look at Intune compliance policies for Windows 365 Cloud PCs.
Windows 365 Cloud PCs are just virtualized workplaces running a version of Windows, therefor we can and need to target Intune compliance policies to these devices. But because these are workplaces running on a virtualization platform, there are some things to keep in mind when implementing compliance policies for Cloud PCs.
Overall we can target most of the compliance settings that we target to our physical Windows devices to our cloud PCs as well. But there are some exceptions on these, because the setting is not supported, or sometimes behave a little bit “different” on Cloud PCs.
Unsupported compliance settings
BitLocker is one of the exceptions we shouldn’t configure in our compliance policy targeted to Cloud PCs.
As written in the Microsoft documentation, BitLocker is not supported as encryption option for Windows 365 Cloud PCs.
Although BitLocker isn’t supported, our stored data on Cloud PCs is safe as Windows 365 Cloud PC disks are encrypted with Azure Storage server-side encryption (SSE) and host-based encryption.
But this is at least one compliance settings on which we shouldn’t check our compliance state.
As BitLocker isn’t supported, we also shouldn’t configure Encryption of data storage on device.
BitLocker would mark your device not compliant when you do target it to a Cloud PC, Encryption of data storage on device will show as not applicable.
Another setting which we can remove from our compliance policy is the one that checks the Trusted Platform Module (TPM). That setting will also show as not applicable if you add it to your compliance policy.
Settings to implement with caution
We also have settings from which we can check the compliance state, but with caution. Secure boot and code integrity are two of these settings. Both settings can be added to our compliance policy, and will report compliant, eventually.
On physical devices you might sometimes see secure boot or code integrity report as not compliant, but most of the time this is solved by performing a reboot of your physical device.
On Cloud PCs, for some reason, it might just take some time before it reports compliant. Or some people report on community forums it reports as not compliant and after a while it is reporting compliant again.
Compliance policy
It’s recommended to create a separate compliance policy specifically for your Windows 365 Cloud PCs, as some settings are not supported in this environment.
Settings like minimum OS version, Real-time protection, and Defender Antimalware version can be configured without any issues. Depending on your organization’s requirements, you can include all these settings in a single compliance policy.
However, if Secure Boot or Code Integrity checks behave inconsistently, consider using a grace period for these two settings. In that case, it’s best to split the policy:
- Create one policy that includes Secure Boot and Code Integrity, and test in your environment to determine an appropriate grace period. In most cases, half a day to one day should be sufficient.
- Create a second policy without a grace period, and include all other settings. This ensures that most compliance issues are reported immediately when detected.
Windows 365 Cloud PCs offer a flexible and secure way to deliver virtual desktops, but they do come with some considerations when it comes to compliance. I hope this helps you in setting up your compliance policies for Windows 365.
Thanks for reading!
