Event banner
Event details
30 Comments
- We see a lot of false positives for compliance failures, e.g. Firewall up for userA, Firewall detection failure for userB. This makes it impractical to use Conditional Access as intended, to block access to Email/Sharepoint etc. This has been the case for 2 years. It's actually slightly better as time goes by, but still a problem. I think non-compliance should only be set if you _know_ it's not compliant. If you get multiple conflicting signals, clearly the problem is with your service and you shouldn't be locking users out of corporate resources. Why are things evaluated per user? Bitlocker is on or off on the device. Firewall is on or off. Secure Boot is on or off. It all feels like you've made it more complex than it needs to be.
- If you know the device should have e.g. bitlocker, and it doesn't, there must be ways to just "make it so" - automatic remediation. If you suspect a restart would fix it, bug the user to reboot, or give them a 24 hour reboot deadline... If auto-remediation fails, send the error logs to the Admin portal so a human can start from a reasonable place. At the moment, it's a massive workload to resolve non-compliance issues - we don't have much data.
- Heather_Poulsen
Community Manager
That concludes our live stream for Device Health Attestation AMA. We’re happy you’re here with us at the Microsoft Technical Takeoff! Whether you are attending one session or many, please take this 2-minute survey and let us know your thoughts on this event.
We’ll continue to answer questions here in the chat for the rest of the half hour and we’ll check back throughout the rest of the week.
I hear it said to apply compliance policies to Users (or am i picking that up wrong), however if in the case of Windows compliance policy applied to Users makes devices non compliant unless a user has logged on.
The device is non compliant because there is no compliance policy assinged to it.
Great session by the way.
- compliance policies and the devices or user targeting... always a nice topic and fun when you end up with a non compliant device because of the the system account https://call4cloud.nl/2021/06/blood-sweat-and-built-in-compliance-policies/
- Thanks Rudy, That is a great in depth view on the compliance policies. We used to deploy our Windows compliance policy to All Users but found that many devices were non-compliant due to the Has compliance policy assigned being non compliant. We have now deployed it to devices and the non-compliance has dramatically reduced. (The bulk of our devices are multi user (Education) with only staff devices being assinged a Primary User. The biggest cause of non-compliance we have now is the "is Active" setting.
- The documentation for DHA and communication/service flows with the DHA cloud service appears to have been heavliy updated in past year or so (had issues with new fleet of pcs and DHA and could find info in past). Great job on the doc updates and service flow diagrams to assist in understanding.
- If you use a seperate policy to set USB bitlocker and fixed drives bitlocker in order to allow for an exemption group for requiring usb bitlockered, it shows as a conflict.
- I want to start testing the enabling bitlocker on some test laptops. What is the best practice? Is there documentation on how to set up the policy?
- Joe_Lurie
Microsoft
The BitLocker policies that you set: encryption level, PIN, TPM, etc...are specific to your company's needs. Here's our Learn (docs) page on how to configure the policy, but work with your security team on the actual settings. https://learn.microsoft.com/en-us/mem/intune/protect/encrypt-devices(edit.. wanted to reply on the OP... but replied on your message 😛 ) Also dont forget to set the bitlocker compatible TPM settings to Required and disabled as mentioned here https://call4cloud.nl/2021/02/b-for-bitlocker/ as you don't want silent encryption to fail 🙂
Why evaluate a device's health PER USER? I can see per logon, or just before a Conditional Access test.
- It would be nice to have a way to re-validate the device health (for example in the mentioned case of the BitLocker example) while in the OS instead of only during boot. By Powershell/manual button etc etc
- with the bitlocker csp "issue" ,(protection only enabled after logging in) we need to have a reboot to make sure we can report the status to the dha service. But in that time the device isn't compliant and with conditional access in place the end user could end up with a not working device. until he/she reboots the device.. Any advice how we could deliver a better experience? setting the grace period?switching to powershell to enable bitlocker during the device phase? just a penny for your thoughts 🙂
- As "someone at ms" made me aware off the fact that setting grace period isn't the nicest thing... .. his exact words... would you like tot have a device without bitlocker in your company, would you be okay with that 😉
So true Rudy_Ooms_MVP ! I don't like grace periods also. It is a choice I rather not make, sometimes you need to however. I would love to see some improvements on this.
