Notes from the field: Windows 10 Device Compliance

Back to Blog

Notes from the field: Windows 10 Device Compliance

One of the coolest features in Microsoft 365 is the ability to measure device compliance, and based on that reading, grant, deny or limit access to cloud resources. For mobile devices this works really well, and most compliance policies are fairly simple: make sure the device isn’t jail-broken/rooted, require a device PIN, etc. I’ve never had an issue with these settings.

Windows devices are another story. Throughout the last year of working with this feature I have seen too many instances where Windows devices mysteriously fall out of compliance for one reason or another, and lose access to resources. I have yet to see an instance of this where the compliance issue being reported is of any significant concern. It appears to be just “the way it works.”

The most common setting that trips the compliance snafu is the Antivirus requirement, specifically when third-party antivirus is present (Defender hasn’t given me any issues like this yet).

For some reason, third party antivirus solutions don’t always seem to work right with this compliance setting. I have gone to these devices, looked at the Security Center, did not see anything saying that antivirus was out of date, or disabled, or otherwise amiss in any way. Usually, simply forcing a sync on this device does the trick to clear up the issue, but because we’ve been seeing it so frequently, I have moved my default settings here to Not configured for the most part, when third-party security software is present.

Shared computers = not supported

Now I have also seen several other controls misreport from time to time, such as the firewall and others. However, I believe this is isolated to shared devices, and it’s just been too many days since the “other” user has signed in, so the compliance goes stale for that user. Vacations, conference rooms where users sign in very infrequently, employee terminations and so on.

But guess what? We shouldn’t be surprised by this–because shared devices are technically NOT SUPPORTED for use with compliance policies. Go read it here on the official docs page:

“Enroll devices to one user, or enroll without a primary user. Devices enrolled to multiple users aren’t supported.”

Crazy, right? How many small businesses out there have shared devices? Answer: hard to say, but a whole hell of a lot.

The problem is that Intune will track compliance for every associated user on a device, and if one user falls out of compliance on the device then the whole device is considered not compliant (even if the active user shows up as compliant, Conditional access is still affected by the inactive users on the device). So ridiculous, right?! If you agree, go vote it up on uservoice.

These behaviors are pretty annoying to say the least when combined with Conditional Access.

Ideal conditions…

The Goldilocks zone for Conditional access with an enforced Windows 10 compliance policy therefore seems to be:

  • 1-1 device-to-user scenarios
  • built-in Defender Antivirus rather than third-party

I never have these types of issues with that configuration. But there are many businesses using third-party security software, and of course, many shared machines out there in the average workplace. So, you may want to consider adjusting your compliance policies, and/or exempting these devices, is what I’m getting at. It’s less than ideal, but… there may be another way….

Consider implementing Conditional Access without a Compliance policy?

We could go with the “out of box” configuration, where devices with NO compliance policy are simply marked compliant (and this implies you should not create a compliance policy for Windows 10).

In theory, this configuration would have the desired effect. I haven’t implemented this anywhere yet, but I am considering it. Let’s move through a mental exercise here–what would be the result of simply not assigning a Windows 10 compliance policy and using the default configuration of marking devices without policies assigned as compliant?

Well, it means:

  1. I cannot measure the devices for compliance, and
  2. I cannot withhold access based on compliance

But, I can still create a Conditional Access policy with the control “Require device to be marked as compliant,” and it will still be meaningful. Why?

A device that does not show up in Intune can’t be considered compliant or not compliant–it just cannot be evaluated. So even though devices will automatically be considered compliant when no policy is present, the device must at least be in our inventory of enrolled devices in order to gain the “compliant” status, and have access. And that means we have visibility and leverage over the device. So while I cannot withhold access based on compliance, I can still withhold access to devices that have not enrolled.

And of course, in this configuration we are not in an unsupported configuration when it comes to shared PC’s (the problem is with compliance policies, but in this case there is no compliance policy assigned).

New access control needed

What I really wished we had was one more access control: Require device to be enrolled. That way, I could withhold access based on enrollment.

The benefits would be:

  • I could hold mobile devices to a “compliance standard” while allowing Windows devices to be held only to the “enrollment standard”
  • I could target specific groups with the more strict compliance requirement while leaving others such as shared devices on the lesser control
  • I could make on-boarding to Conditional Access and Endpoint Manager much easier–I can start with the lesser control and smoothly transition up once I’ve nailed compliance down org-wide

Because right now it’s all or nothing: Conditional access compels not only enrollment but also compliance. And if I modify the compliance settings to allow every device to be marked compliant with or without a policy, that is a global setting–but I don’t necessarily want to relax the requirements for everyone, just Windows 10.

If you like this idea, go vote it up at uservoice also.

Departed users

The other issue is that devices could still fall out of compliance after the validity period passes. For instance, when users leave the company and a device is re-purposed for a new user. After the compliance validity period (30 days by default) the machine would fall out of compliance for the departed user and that would affect the new user of this device.

Therefore, the best thing to do in this situation is to reset the device completely and redeploy it, removing the old device object from your inventory.

If you think it’s dumb that we have to reset a device and re-enroll it when it changes owners, go vote this feature up at uservoice.

Another management task that could be avoided if the requirement were simply device enrollment, rather than compliance. Or… I don’t know, maybe Intune could be smart enough to realize when a user has departed, or a machine is being shared, or it’s changed hands? Maybe upgrade the intelligence a bit so it knows to measure only the active session on each device?!

Not measuring compliance isn’t the end of the world…

Also, let’s consider other ways we could measure compliance. I may not be able to look at a compliance policy and see which devices meet or do not meet my requirements, but I can enforce most of the same requirements using Device configuration profiles, and even report on their success or failure.

In this example, if we were using BitLocker as a measure of compliance rather than simply applying a device configuration profile, 15 users would be screwed!

We’re not really missing that much by ditching compliance. So no Windows 10 compliance policy might just be the ticket until Microsoft improves the intelligence here or gives us another access control based on mere enrollment… And even then, don’t forget to manage stale devices, especially for departed users!

My suggestion: just keep slogging through it for now, but head over to User voice and vote these issues up! Remember that you, the consumer of these products, are responsible for the software we all have tomorrow.

Update: I ultimately decided on a very “low bar” for compliance–right now I am only enforcing a minimum OS level (1809 which is 10.0.17763). This appears to work without issue.

Comments (14)

  • Gilad Reply

    hey,
    love your articles, I was actually waiting for you to write one regarding compliance issues.
    I think I must agree with the issues you mentioned.

    I’m working with some large (+800 users) customers on their Zero Trust deployment and some raised the needs to more enhanced / custom compliance capabilities, for that I posted a UserVoice of my own and discussed it with Intune PM team.

    As you are obviously very experienced with M365 , I would be happy to hear your thoughts on that on – https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/38890249-forcing-a-device-to-become-non-compliant-based-on

    December 11, 2019 at 10:01 am
    • Alex Reply

      Love it. Voted it up.

      December 13, 2019 at 2:25 pm
  • Rkast Reply

    “Enroll devices to one user, or enroll without a primary user. Devices enrolled to multiple users aren’t supported.”

    I think you are wrong here. A device cannot be enrolled to multiple users. I think the not support means that a device cannot be enrolled by multiple users but multiple users can log in to the device.

    Shared devices ARE supported see https://docs.microsoft.com/en-us/intune/enrollment/enrollment-method-capab

    and

    https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/self-deploying
    Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device

    December 12, 2019 at 9:24 am
    • Alex Reply

      Maybe that’s a better interpretation, however in practice the shared device thing is very hard on compliance. Not a single conference room PC out there in my customers is ever compliant (at least not for very long).

      December 13, 2019 at 2:26 pm
  • Martijn Hof Reply

    Hi Alex,

    You are wrong about the fact that shared devices are not supported. As you mention ““Enroll devices to one user, or enroll without a primary user. Devices enrolled to multiple users aren’t supported.””

    Enrolling a device to multiple users is not supported and even possible. But logging in to a device with multiple users is working and also supported. I have some links that see below.

    https://docs.microsoft.com/en-us/intune/enrollment/enrollment-method-capab
    “Devices can be used as shared device”

    https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/self-deploying
    “Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device”

    December 13, 2019 at 3:34 am
    • Alex Reply

      This comment is very similar to the other one I just replied to. Assume it could be the same person. But yes, even if shared devices are okay (I think there is an issue with the wording in that article–and it is specific to compliance policies not Intune generally), it doesn’t change the poor experience we have with compliance and shared devices.

      December 13, 2019 at 2:29 pm
  • Martijn Hof Reply

    Hi Alex, sorry it was a double post indeed cause the browser timed out and did not know if it was posted or not. I agree the shared device in general is a b**ch. Compliance is never met but i also encounter policies not applying on shared devices. Best is 1-on-1 user device but in our sector it is not possible or much more expensive. You also encounter policy not arriving or getting set on shared devices ?

    December 14, 2019 at 6:40 am
    • Alex Reply

      Yes, it has been hard. But, apparently some recent updates may help with the experience. I’ll have to try them out…

      December 14, 2019 at 12:34 pm
      • Gilad Keidar Reply

        In shared devices env the best way is to enroll devices using autopilot self-deploy.
        When doing so 2 basic requirements must met:
        1. Device must support TPM 2.0 for self-deploy enrollment to work properly
        2. All policies — compliance, configuration, apps etc — should be targeted to a device’s group (if I’m not wrong some may work with user’s group too)

        December 14, 2019 at 1:44 pm
        • Alex Reply

          How about using a Device Enrollment Manager? Have you tried that? What do you like/not like about it compared to Autopilot?

          December 14, 2019 at 9:52 pm
          • Gilad Keidar

            Actually I didn’t try EM, that could be simpler solution than self-deploy. The question if device which enrolled using EM left with no primary / enroll user.
            We’ll try and let you both know :)

            December 14, 2019 at 11:55 pm
  • Martijn Hof Reply

    I saw the tweet also :)
    Will test and try it out.
    Keep is posted and i will do too.
    Regards!

    December 14, 2019 at 1:32 pm
  • Martijn Hof Reply

    DEM has it limitations too.
    DEM account must be licensed account and can enroll to max 1000 devices
    With DEM you cannot (total) automate and customize enrollment/setup
    The device enrolled with DEM cannot assess resources protected by CA

    And experience with compliance and policies are the same with DEM

    I prefer always Self Deploy mode with shared devices

    December 15, 2019 at 1:14 am
  • Carl Reply

    Great posts and comments – I noticed that Cathy Moya updated the Uservoice for “Change Registered Owner” to ‘Started’ – hopefully we will see a development on this in early 2020

    December 16, 2019 at 4:38 am

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.