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...
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.
I have had some advice from MS Intune support and they say that in my case (a Bitlocker policy) it should be applied to the User and not the machine to solve the issue. It seems counter intuitive (to me anyway) to apply a policy which really only can apply to machines (it is encrypted or it isn't), to users who aren't going to be encrypted. Anyway, I am going to test this advice and see what happens, but it does feel like a 'fudge'.
If I remember correctly (and I might not), it seems a System A\C is created when the machine is added to the system (Intune?) before the primary user is created. The trouble is this System A\C can either be compliant or not, depending on something as yet unknown. One way to get rid of it is to remove the machine from AAD and re-join it. Simple enough in AD but not so in AAD, and anyway there is the extra gotcha in making sure that you've not named your machine with over 15 characters, which is allowed, (maybe 16, but just to be on the safe side) as it makes the process of creating a local admin that you need to log into when off the domain, impossible. Believe me, I have stumbled into that one which took days and was solved by accident and luck.
Overall I can see the point of Intune, especially if you need to back up your security principles/management of devices with some sort of verifiable evidence. However, every policy is a complex slog and I have now started to create policies with only one or the minimum changes possible to keep things simple. Plus, on advice, I am now testing things that directly and obviously affect the user, one at a time, which makes it an even bigger slog. For example, I'm testing a policy to block access to Defender settings, so no-one can switch them off. One setting, which according to Intune has worked, but on the machine no change. Spotted in the (awful) documentation that for this setting the machine requires a reboot. Rebooted it, no change. So Intune says the policy is successful but the machine has clearly not got the message. Incidentally the 'Disable Autoplay' setting doesn't make any visible changes and the Autoplay button remains 'on' in the Settings panel. You would think this would be fairly easy to test before it is shown the light of day!!
AJRoy Did you already tested assigning the bitlocker policy to users?
Hi, no I can't come up with any ideas either but I just wanted to post my screaming frustration with this scenario, it really is not good enough. We use device policies and fortunately we don't have that many machines, but we have compliance failures for System Accounts that should have no bearing on the situation. We also have situations where the System Account is Ok and the user account isn't! Go figure.
