First published on TechNet on May 04, 2017
Murali Krishna Hosabettu Kamalesha | Program Manager, Intune
If you’re managing Windows using mobile device management, and if you’re targeting those devices with conditional access policies, there’s a known issue we wanted to make you aware of with the Windows early launch anti-malware (ELAM) driver. This issue applies to both Intune and to Configuration Manager connected to Intune for MDM. Read on to find out more about how this issue might impact your devices.
Intune compliance polices are great for setting standards for the devices that need access to your organization’s resources. For Windows 10 MDM-managed devices, you can create an Intune compliance policy with a setting that requires the device to be considered healthy by the Windows Device Health Attestation Service (DHA-Service). When this setting is enabled, Intune uses several Windows settings to calculate compliance status.
- Code integrity is enabled
- Bitlocker encryption is enabled
- Secure boot is enabled
- Early launch anti-malware (ELAM) driver is loaded
If one or more of these Windows settings are reported to be disabled on the device, then the device gets marked as noncompliant by Intune and Azure Active Directory does the blocking, assuming of course you’ve enabled conditional access to a resource, for example SharePoint or Exchange Online.
There is a bug in Windows where the Windows Device Health Attestation Service incorrectly claims that the ELAM software is disabled on the device when it comes out of hibernation. Windows is aware of this bug and is working on a fix.
Intune is working on a change for the May release to stop including the ELAM state as part of the compliance check for the “Require devices to be considered healthy by the Windows Health Attestation Service” setting until the underlying bug is fixed in Windows. Until the May Intune release is available, you have two choices:
- You can disable the setting “Require devices to be considered healthy by the Windows Device Health Attestation Service” in the compliance policy targeted to users, but this will also prevent Intune from evaluating code integrity, Bitlocker, and secure boot settings. (In the future, Intune plans to allow admins to individually enable each setting used for compliance calculation.)
- You can tell users if they are blocked to restart their devices and click the “check compliance” button in the Intune Company Portal.
Note, we still have a few accounts that haven’t migrated to the new Azure Active Directory groups, mostly because they have migration blocking issues as described in this blog: http://aka.ms/intunemigrationblockers . If your account hasn’t migrated by the time the May release is available, you’ll need to tweak your policies so they will stop evaluating ELAM. All you need to do is open your compliance policies containing the setting “Require devices to be considered healthy by the Windows Device Health Attestation Service” and make any change to it, like adding a space to the description, and then saving the policy. Changing the policy in any way will make Intune recalculate the policy and check only code integrity, Bitlocker, and secure boot.
In the future, Intune plans to allow you to pick which settings you want to evaluate for compliance. We’ll start with three if the Windows bug isn’t fixed, but eventually you should be able to set all four individually.
