Built-in Device Compliance Policy - is active - Not Compliant

[MrNuggets]

I have an enrolled windows device (we are using Azure AD, no hybrid), where I changed the primary user.
The compliance policy and the build-in device compliance policy for the new primary user is showing compliant.
But the build-in compliance policy for the user, who has enrolled the device is showing "not compliant" see screenshots

Do you have any ideas how to solve this? 

[#2]

Hi MrNuggets,

this is something I see appearing and disappearing every now and then. Seems like a refresh issue. However, there are a few things you can check:

- check whether the device has another compliance policy assigned
- check whether the device is active (recently synchronized)
- check whether the user that enrolled the device (still) exists in AAD

if all answers are YES, then you can also try to re-enroll the device to get all data populated all new in the Intune database.

hope it helps

Alex

[#3]

Hi,

If the user is active and everything good there is a known issue with this built in compliance policy that Microsoft knows about. Our tenant have hundreds of these even if they are "compliant".

[#4]

@AlexdeJong 

thank you for your reply, I checked your points:
Only one compliance profile is assigned.
The client syncronized 30 minutes ago.
The enrolled user still exists.

I will think about reenrolling the device.
 

[#5]

Hi

<Maybe offtopic but 😛
Just looking at the pictures.. but just wondering... but are you okay with the settings: mark devices with no compliance policy --> compliant?

[#6]

@Rudy_Ooms_MVP 

We do not have any clients without a compliance policy, but you are right, I will change this setting 🙂

[#7]

@gerardoamadeus Do you know if this is still an ongoing issue with MS? Do you have a link for MS page where this known problem is outlined? 

[#8]

Hi, I see you posted this in 2021. Its 2023 now and seems Microsoft still did not fix this bug.

Any idea why they still haven't worked on this? We just have random ipads marked as not compliant due to "Built-in Device Compliance Policy". They are complaint in other compliance policies such as the Tik Tok app block and IOS verison.

[#9]

I came here looking for the same solution. 😞 Mine's not even iOS; they're Windows devices.

[#10]

@MrNuggets 

This probably won't help others, but in your case...

You note that a different user was used for enrollment. I think you can clear your error by logging into the device as that enrollment account (the account with the compliance policy showing as not active). So, reboot and then login and let the device sit for 5-10 minutes. If you don't reboot, then you might need to click Sync in the Intune console, and on the device in Settings > Accounts > Access Work / School > click domain > click Info button > scroll down and click the Sync button. I'd also open Company Portal > Settings > Sync too, but since it isn't the primary user, this may not do too much, but I'd still do it to cover all my bases. If this is a user device who I don't want to inconvenience with another disruption, then I'd probably reboot after the 10 minutes, login as the enrollment account and let it sit for another 5 minutes. It will probably take the Intune console longer than the 5-10 minutes to fully refresh, but I think it will clear in the 10-30 minute window. 

[#11]

That makes sense. Computers in corporate environment get shared, so it's not always the same user signing in. I wish Intune can be made to work with any domain users signing in.

[#12]

@CutlerTS We have this issue quite often in our Shared PC environment. The device has a shared policy, has no primary user and has a valid compliance policy with active devices. They somehow STILL get marked as non-compliant. I logged in with the original administrative account that enrolled the device. This made no difference, despite much syncing and rebooting. The only thing that worked was to reenrol the device again. This isn't an acceptable solution, as this issue crops up randomly and frequently. It's really frustrating, as it's a constant upkeep. If it was a valid flag, it wouldn't be so bad, but it gets to the point where there is so much 'noise', the valid issues are lost in the haystack. Microsoft, you need to sort this out!

[#13]

Having the same issues and also got in touch with MS Support who is stating that this behavior is as designed. Reading the other suggestions of re-enrolling this can't be by design to re-enroll a device as soon as another user logs in to the device and the user that was logged in before get's not compliant because of "no activity".

[#14]

@Cena10 That’s nonsense isn’t it? We have a complete shared environment. It’s unworkable to keep re-enrolling. Common sense suggests it’s a bug but the advisor isn’t aware. I’d never be able to keep up with that. It must depend on who answers the query, as I’ve had corkers advised to me. On a different topic - “don’t switch off the PC, or you’ll have to set up the client rules again” 🤣🤣🤣. I’ll keep the damned ticket open until they fix it!!

[#15]

Hi All and @MrNuggets 

We have a similar problem. Several windows 10 machines were not enrolled by the user himself but by an IT colleague who then set the user as Primary user. Unfortunately, in the compliance policy settings e.g. "has a compliance policy assigned" or "Require Bitlocker" the user who enrolled the machine has non compliant values. The Primary user is green. Do you have any idea how can we make compliant the user who enrolled the device or how can we solve this non compliant values?

Thank You!

[#16]

@Sunyix the MS technician who is working on my ticket was stating to log back in with the user that is incompliant and start a sync with that user. I already tried that on one of our machines and a day later it got incompliant again with the same way as it was before. 

[#17]

One thing that does seem to work is if you’re having different people potentially logging into the same device (which we do) and we have Shared PC policies, removing the Primary User altogether (so no primary user exists) seems to just show the device compliance against the last person that logged in. Microsoft didn’t mention this specifically but they did say that the compliance policies are ALWAYS evaluated against the user and NOT the device. I’d set up device groups. The advice online is if you want a PC or laptop to always have a circumstance, such as bitlocker to be valid, then use device groups or all devices. However, if the compliance policies are only ever going to be user evaluated, then clearly, this isn’t going to work. It should be:

Compliance policy - Users
Configuration profiles Devices.

Bit confusing, but what I have seems to work ok in our Shared PC environment with a Shared PC profile.