Forum Discussion
Device Compliance
Baljit Aujla I have figured out the solution.
When you have Compliance policy, assigned to All Users, it will reflect all your Azure AD users with those logins. But what about other (local accounts), like "system account" etc.., they are not compliant.
Resolution is to have another additional (same) compliance policy, assigned to Azure AD security group, and add those (shared) windows 10 devices to the group.
In that case, Compliance policy is assigned on device level to the specific device, and then "system account" does not cause the problem.
It is poorly documented, but this is something that Microsoft Support given to me...
I've had this problem too and I'll share my experience here:
If you assign policies to a device it applies the policies to all accounts on that device, including the system account (which will usually bring trouble for the compliance and such). I've not had any cases in which the system account was actually needed in Intune.
In most cases it is better to just assign the policies to the users and I usually use a dynamic group with all enabled users in it instead of 'All users'. If they then change device it will automatically migrate all policies and apps to that device as well, which will save us some time. Only when you work with special shared devices is assigning them to the device itself useful in my opinion (and even then there are some good cases for user assignment).
Simply reassigning the policies to users instead of devices won't make that system account go away in the portal though. You will have to delete the policy and make a new one, then assign it to the users only, then there won't appear a system account.
This is what I have found out from experience. I might be wrong but it has worked for me in the past. If someone wants to correct me about my policy assignment best practices, feel free to do so. I'm relatively new to Intune.
Same issue here as well. We assigned the device compliance policy to a Windows 10 device group. Because we have multi user devices we cannot switch to user groups. Very often devices are marked as non compliant because of the system account. This is really annoying and we can't use Device Compliance within CA. Already opened support ticket but no help from there yet....
In our environment we use device assignment, too. (For device compliance and for device configurations.)
Some of the devices are only showing the compliance and configs for the user, some devices are showing them for user AND system account.
I really have no idea why. Anyone else?
And of course we have the same issues as everyone in here:
Some device configs are compliant for user AND system account, some configs are only compliant for the user.
BUT: When i have a device with user compliance marked as compliant and system account as non compliant, the whole device is marked as compiant in the GUI nevertheless.
Same here - we thought device compliance was the best way to go, since we are cloud only, joined to AzureAD and other users could theoretically log in to other devices even though they hardly ever do that. Win10 is at least v1803 on our machines.
But, like you and a few other posters here mentioned, some devices report complaint with both 'system' and user account, then others are marked non-compliant with either the 'system account' or user account not compliant.
@microsoft:
being that we as system admins have no control over this 'system account', I'd like to request it officially removed from compliance checking, or at least see a check-box in the policy to exclude it. Additionally, if assigning most policies to devices is not the preferred method, update the documentation to include explanations that system admins can understand, then we can make an informed decision as to which way we'd like to go for our organization. Also add some explanation as to what the 'system account' is and how it is controlled/administered/used.
SamTeerlinck In many cases customers of ours have allready Intune implemented or partialy implemented. If I would be building an enviroment based on user assignment it would also impact devices that are allready in use by users.
Another case where I don't want user assignments is when we have a customer that has BYOD devices. Those devices are personaly owned and most of the times policies for BYOD and corporate owned devices will deffer from eachother.
A third example is development users versus "standard" users. But in that case it's not the policies that we don't want to target to users but just the applications.\
As long as we can't exclude devices on policies that are assigned to users, I need to have policies applied to devices most of the time.
In my opinion there is a major!! flaw in compliance reporting by Intune. The problem we encounter with shared devices forced us to completely disable all compliancy checks for those devices.
The situation:
- User 1: logs on to the device
- User 1: marks the device as not compliant for whatever reason
- User 1: Logs of from the device before remediation could be started
- User 2: Logs on to the device
- User 2: The device gets remediated
- User 2: tries to open a resource that requires a compliant device and is denied access because the device is NOT compliant
The only solution is... let User 1 sign in again and remediate the device under User 1....
In my opinion this is absolutely unacceptable.... The solution is called DEVICE compliance. So how the beep is it possible that the DEVICE wont be set to compliant when a different user logs on to the device and remediates the issue that marked the device to be non compliant.....
For another customer of ours, an admin needed to logon to a users device and marked that device as non compliant. Result was the user wasn't able to access resources that required a compliant device.
Especialy with shared devices we cannot trust the Device Compliance solution the way it works now. This is a huge issue in a world where compliancy is one of the key components to secure access to resources.
Apart from this, Intune Device compliancy is way too unstable for me to use it as a conditional access.
Luckily we don't have thousands of users so I can manually check if one of the devices becomes incompliant. Usually it's just an intune bug.
