When working with compliance policies, it’s important to understand the complex series of actions that must take place on the device for them to apply properly. For example, a common scenario that may occur includes BitLocker being enabled on the device with the drive encrypted but the compliance policy shows non-compliant for BitLocker. IT administrators need to understand how compliance policies impact BitLocker to troubleshoot scenarios such as this.
To begin, we first need to look at how the compliance policy is configured. A common configuration includes having all three Device Health settings (Require BitLocker, Require Secure Boot to be enabled on the device, and Require code integrity) set to Required. Note: It’s not required to configure all three settings. They can be set in any desired combination.
Having all three Device Health settings set to Required ensures that you’re enabling device health attestation on the device and using it to check whether BitLocker, Secure Boot, and code integrity are enabled via the HealthAttestation Configuration Service Provider (CSP).
It’s also important to note that this is not the only way to check whether encryption is enabled in a compliance policy. Under System security, there’s an option to Require encryption of data storage on device.
This uses the DeviceStatus CSP to check whether the device is encrypted. The difference between this and the Device Health Attestation (DHA) setting is that the encryption compliance will check for any type of encryption on the operating system (OS) drive and is not limited to BitLocker. It can also include third party encryption and doesn’t rely on device health attestation. For more information about OS disk encryption, see Azure Disk Encryption for Windows VMs.
You can use either of these options, however, DHA is the more secure of the two.
When the three options in the Device Health compliance policy are set to Required, there’s a specific set of HealthAttestation CSP processes that need to take place to check the settings.
Windows device health attestation
How Device Health Attestation checks for encryption compliance
BitLocker isn’t supported on certain virtual platforms and will show as not applicable in the compliance policy for the following:
Troubleshooting Windows DHA compliance
There are three parts to DHA:
Generally, issues occur during the first step of the process as either the boot data has not been gathered properly or not at all. To remediate this issue, reboot or analyze the measure boot logs at C:\Windows\Logs\MeasuredBoot. For more information about how to analyze the measured boot logs, see Decode Measured Boot logs to track PCR changes.
Reboot
The first step in troubleshooting is to reboot. The DHA evaluation takes place on boot so, if the device has received the policy and hasn’t rebooted, a manual reboot will be required.
Firmware
If the reboot doesn’t resolve the issue, the next step is to see whether the device has the latest version of the firmware. Occasionally, a particular device make/model might be affected, which could indicate an issue with the manufacturer’s firmware. Updating to the latest firmware version will help isolate whether the issue was already addressed in the most recent update.
Registry
If rebooting and updating the firmware have not resolved the issue, then check whether the device can access the DHA service. To do this, check the registry.
On the non-compliant Windows device, navigate to Start > Run > Regedit > and then navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\HealthCert\Store\has.spserv.microsoft.com\Status.
If the values are HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) or HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0), then the certificate retrieval process has not completed. You’ll need to run the task scheduler manually to see what error is recorded. Refer to the Task scheduler section below for more information about how to do this.
404 Endpoint_Not_Reachable DHA-Service isn't reachable by DHA-CSP
A 404 error occurs if the Health Attestation service is inaccessible over port 443. The device needs to be able to access has.spserv.microsoft.com over port 443. Ensure that firewalls aren’t blocking access.
Refer to Step 1: Verify HTTPS access for validation steps.
400 Bad_Request_From_Client DHA-CSP has received a bad (malformed) attestation request.
A 400 error could indicate problems with the communication between the device and the DHA service. The device could be missing a certificate or have an issue communicating with the Trusted Platform Module (TPM). Check if the following registry key has the certificate:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\HealthCert\Store\has.spserv.microsoft.com\HealthCertificate
Task scheduler
If the status in the registry key is not 3, then manually run the Tpm-HASCertRetr task from the task scheduler.
On the affected device, navigate to Start and enter “task scheduler” into the search tool. Expand Task scheduler Library > Microsoft > Windows > TPM > Tpm-HASCertRetr.
Right-click on Tpm-HASCertRetr and select Run.
If you see a last run result of 0, then the task has completed successfully. If the task has completed with an error, you’ll see a hexadecimal code.
If, for example, you get the hex code 0000001e, this converts to decimal value of 30. If you look up the 30-error code in the list of HealthAttestation CSP status and error codes, it translates to:
30 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST DHA-CSP failed to send the HTTP request.
This indicates an issue with the device connecting to the HAS service.
BitLocker, code integrity, and Secure Boot compliance all rely on the DHA CSP, the interaction of the device with the MDM provider (Intune, in this case), and the DHA service hosted in Azure.
Most issues an admin experiences stem from the device connecting to the DHA service, which is usually caused by network issues, firmware not being up to date, or the device not rebooting since encryption took place.
If you have any questions, let us know in the comments or tag @IntuneSuppTeam on X (formerly known as Twitter).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.