Forum Discussion
Windows Compliance
Hi All
I hope you are well.
Anyway, I'm having a nightmare with Device Compliance on Windows devices.
Recent research of Microsoft and other guides and documents reveals seriously conflicting information.
To sum up, we have a mixture E3 and F3 users logging onto Windows devices. These Windows devices have a basic compliance policy deployed that requires BitLocker, AV, Firewall etc.
The problem starts when multiple users logon to a Windows device, as one would expect in a shift based org, with the device showing as compliant for one user but not the other(s).
One of the biggest non compliance issues is with BitLocker, but it does vary.
Now reading online, I can see a Shared / Multi User config which can be deployed to Windows devices.
Is this what I need?
Furthermore, our Compliance policies which contain Require BitLocker are currently deployed to devices. Should this policy be deployed to users instead?
The info available online is massively confusing and conflicting with some "guru's" stating that Compliance policies are best deployed to users but other state that BitLocker policies should be deployed to devices.
Can anyone help me solve this E3 / F3 Compliance riddle?
SK
5 Replies
I believe this will resolve your issue
Enroll all shared computers using a DEM account, then for the primary user in the intune portal, remove any user entirely. So it should say, "NONE", that activates shared mode for the computer.
No single user should enroll a shared device into intune.Your follow-up confirms both policies already target device groups, which Intune supports. Moving compliance to user groups is not required merely because shift workers share a PC. Shared PC configuration manages account access, cleanup and power behavior; it does not itself resolve a failed BitLocker check.
First compare the failing setting, error code, associated user and last check-in on one affected device. Microsoft documents that shared-device reports can reflect the previous user's state and contain separate user and system records, so compare equivalent, recent evaluations.
For Require BitLocker, distinguish completed disk encryption from Device Health Attestation. Microsoft documents that a restart may be necessary before the encrypted device becomes compliant. After confirming encryption, restart, sync and review the refreshed setting result.
The E3/F3 labels alone cannot identify this failure. If the discrepancy persists, give support the per-setting errors and paired check-in timestamps before changing targeting or weakening compliance requirements.
Hi Buddy
Many thanks for your reply
OK, let me clarify a few things before we start misdiagnosing the problem:
- Yes these Windows devices are shared between E3 / F3 users however a Shared PC config has not been deployed
- This is a Compliance issue and not restricted to BitLocker
- This is not a request for info on how to " resolve a failed BitLocker check"
A little context again:
- E3 / F3 users logging onto Windows devices
- Compliance policy deployed to device groups
- Some Conditional Policies that restrict access to SharePoint Online etc (printing / downloading) from unmanaged / non compliant devices as per below:
- We are seeing various Compliant and Non Compliant results per managed (Intune enrolled) devices
What I suspect is causing the problems is related to the "Primary User" but the info available online doesn't 100% clarify anything. See below Google AI search result:
There are lot of other search results hinting at Intune only processing Compliance for the Primary user. I also think there is similar info stating that the Intune Company Portal app can only be assigned to and then used to fix Compliance by the Primary User.
Finally, some of our IT Support tech have "fixed" non compliance by Changing the Primary User.
It's this Primary User thing that led me thinking Shared PCs might help with our constant Compliance iisues, as well as some of the info on the guide below:
https://www.burgerhout.org/p/mastering-windows-shared-pcs-with-microsoft-intune
I just need a concrete answer.
Stuart
Hi SK,
I'd suggest assigning both policies to devices. Here's why, and what to check.
1. Likely cause: user-targeted compliance policies are evaluated for the users in the target group. On a shared device, a user outside that group (say F3 users when only E3 is targeted) may have no policy applied. If Compliance policy settings > "Mark devices with no compliance policy assigned as" is set to Not compliant (which Microsoft recommends with Conditional Access), that user's sign-in shows as non-compliant. You can confirm it in the Company Portal, which shows "No compliance policies have been assigned", or in the Devices without compliance policy report.
2. Fix: assign the compliance policy to a device group (for example a dynamic group on Windows OS, or All Devices with a filter). Assign the BitLocker policy (Endpoint security > Disk encryption) to devices too. The result is then the same whoever signs in.
3. Shared multi-user device profile: it's a separate profile (SharedPC CSP) that controls sign-in, account cleanup and power settings, so it won't fix compliance on its own. Use it if you want that locked-down shared-PC behaviour, and assign it to device groups.
4. Reporting caveat: compliance reports show the last signed-in user, or "System account" for device-targeted policies, so don't read too much into which user appears.
5. If BitLocker still fails after that, check TPM status and key escrow on an affected device.
E3 vs F3 doesn't change how compliance is evaluated. It's about who is targeted.
Docs: https://learn.microsoft.com/intune/device-security/compliance/overview and https://learn.microsoft.com/intune/device-security/compliance/monitor-policy
Hi Buddy
Many thanks for the reply.
Currently my Windows Device Configuration and Compliance policies are targeting device groups.
Stuart
