This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
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.
How Device Health Attestation checks for encryption compliance
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
- The device forwards its boot data to the DHA service using the DHA CSP. This occurs on boot and can be traced using the measured boot logs at C:\Windows\Logs\MeasuredBoot.
- The DHA service replies with the encrypted data.
- The Mobile Device Management (MDM) server (Intune) sends a device health verification request via the DHA CSP.
- DHA CSP replies with the DHA data (encrypted and signed).
- The MDM server (Intune) posts data it receives from the device to DHA service in Azure.
- The DHA service reviews the data and replies with a DHA report.
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:
- Windows 365—All data is already encrypted and the device is hosted in a secure data center so that it can’t be lost. For more information, see Windows 365 Enterprise Security guidelines.
- Azure virtual desktop single-session.
- Azure virtual desktop multi-session—It will appear as not applicable in the compliance policy.
Troubleshooting Windows DHA compliance
There are three parts to DHA:
- The client gathering the boot data
- Communicating with the DHA service
- Intune communicating with the device using the DHA CSP
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.
- A 404 error response from the CSP in the Intune reporting indicates issues connecting from the Windows client to the DHA service. Check the network connectivity to troubleshoot.
- A 400 error response would indicate a communication failure or bad response when communicating from the client to the DHA service, possible reasons for this include problems with the TPM or a missing health certificate.
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.
- A healthy device will have a value of 3 in Status, which translates to HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE.
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.
- Any values other than 0, 1, or 3 can indicate that there is an issue. Refer to the HealthAttestation CSP error codes to see the full list of potential codes. The most common codes you’ll see translate to 400 or 404 errors.
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.
- Winget install openssl
- Change directory to C:\Program Files\OpenSSL-Win64\bin
- Run the following command: ./openssl.exe s_client -connect has.spserv.microsoft.com:443
A screenshot of the complete line command, PS C:\Program Files\OpenSSL-Win64\bin> ./openssl.exe s_client -connect has.spserv.microsoft.com:443.
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.
Summary
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).