How to Set Up Health Attestation Service on Windows Server 2025

Device Health Attestation (DHA) is one of the most important and often overlooked security pillars in a modern Windows Server 2025 environment. At its core, DHA answers a fundamental question that traditional certificate-based trust cannot: is the device attempting to access your network cryptographically verifiable as having booted into a trusted, unmodified state? By leveraging measurements collected by the Trusted Platform Module (TPM) during the boot sequence, DHA provides cryptographic proof that Secure Boot was enforced, that BitLocker was active before the OS loaded, that Early Launch Antimalware (ELAM) drivers ran first, and that no known-bad firmware or bootkit modified the boot chain. This guide covers the full deployment of Health Attestation on Windows Server 2025 both as a cloud-integrated service through Microsoft Intune and as an on-premises DHA server for environments that cannot send attestation data to the cloud.

Prerequisites

Windows Server 2025 (for on-premises DHA server role)
Client devices with TPM 2.0 (TPM 1.2 supported with limited evidence types)
UEFI firmware with Secure Boot capable and enabled on client devices
Early Launch Antimalware (ELAM) compatible antivirus (Windows Defender satisfies this)
Active Directory domain with Group Policy management
Microsoft Intune or SCCM/ConfigMgr 2203 or later (for MDM integration)
Network access from DHA server to has.spserv.microsoft.com (cloud DHA) or internal DHA endpoint
SSL certificate for the DHA server endpoint (from internal CA or public CA)

Step 1: Verify TPM and Secure Boot State on Client Devices

Before deploying DHA, audit your client fleet to confirm TPM and Secure Boot are present and correctly configured. Deploying attestation against devices that lack TPM will cause false negatives that block legitimate users.

# Run on client devices - check TPM status
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated, TpmOwned, ManufacturerId

# Check TPM specification version
$tpm = Get-WmiObject -Namespace "rootcimv2securitymicrosofttpm" -Class "Win32_Tpm"
$tpm | Select-Object IsActivated_InitialValue, IsEnabled_InitialValue, SpecVersion

# Check Secure Boot state
Confirm-SecureBootUEFI

# Check ELAM (Early Launch Antimalware) driver status
Get-WinEvent -LogName "Microsoft-Windows-Kernel-Boot/Operational" -MaxEvents 20 |
    Where-Object { $_.Message -like "*ELAM*" } |
    Select-Object TimeCreated, Message

# Bulk TPM audit via PowerShell remoting across domain
$computers = Get-ADComputer -Filter { OperatingSystem -like "*Windows 11*" } |
    Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
    $tpm = Get-Tpm
    [PSCustomObject]@{
        Computer   = $env:COMPUTERNAME
        TpmPresent = $tpm.TpmPresent
        TpmReady   = $tpm.TpmReady
        SecureBoot = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
    }
} | Export-Csv -Path "C:AuditTPMAudit-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Step 2: Install the Device Health Attestation Server Role

The on-premises DHA server role is available on Windows Server 2025 for organizations in regulated industries or air-gapped environments that cannot route attestation requests through Microsoft’s cloud DHA service. Install it on a dedicated server separate from your domain controllers.

# Install Device Health Attestation server role
Install-WindowsFeature -Name DeviceHealthAttestationService -IncludeManagementTools

# Verify installation
Get-WindowsFeature -Name DeviceHealthAttestationService

# Install required IIS components (DHA runs as a web service)
Install-WindowsFeature -Name Web-Server, Web-Asp-Net45, Web-Windows-Auth, Web-Mgmt-Console

# Check DHA service status
Get-Service -Name DhasService | Select-Object Status, StartType, DisplayName

# Start and set to automatic
Set-Service -Name DhasService -StartupType Automatic
Start-Service -Name DhasService

Step 3: Configure the DHA Server with SSL Certificate

The DHA service requires HTTPS. Bind an SSL certificate from your internal Certificate Authority to the DHA IIS site. The certificate Common Name must match the DNS name that MDM clients will use to reach the DHA endpoint.

# Request a certificate from internal CA for the DHA server
$certParams = @{
    DnsName           = "dha.contoso.local"
    CertStoreLocation = "Cert:LocalMachineMy"
    KeyAlgorithm      = "RSA"
    KeyLength         = 2048
    HashAlgorithm     = "SHA256"
}
$cert = New-SelfSignedCertificate @certParams  # Use internal CA in production

# Better - request from enterprise CA
$certReq = @{
    Template          = "WebServer"
    DnsName           = "dha.contoso.local"
    CertStoreLocation = "Cert:LocalMachineMy"
}
# Get-Certificate @certReq  # Uncomment when enterprise CA is available

# Bind the certificate to IIS HTTPS site (port 443)
Import-Module WebAdministration
$thumbprint = $cert.Thumbprint

# Remove existing HTTPS binding if present
Remove-WebBinding -Name "Default Web Site" -Protocol https -ErrorAction SilentlyContinue

# Add HTTPS binding with the DHA certificate
New-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -SslFlags 0
$binding = Get-WebBinding -Name "Default Web Site" -Protocol https
$binding.AddSslCertificate($thumbprint, "My")

# Configure DHA endpoint URL
Set-DhaSvcConfiguration -EncryptionCertificateThumbprint $thumbprint `
    -SigningCertificateThumbprint $thumbprint

Step 4: Configure DHA Integration with Microsoft Intune (Cloud DHA)

For most organizations using Intune, Microsoft hosts DHA as a cloud service eliminating the need for the on-premises server role. Intune automatically collects attestation data from enrolled devices and evaluates it through Compliance Policies.

# Verify device is enrolled in Intune MDM (run on client)
$mdmInfo = Get-MdmDeviceEnrollmentDetails -ErrorAction SilentlyContinue
if (-not $mdmInfo) {
    # Check via registry
    $mdmKey = "HKLM:SOFTWAREMicrosoftEnrollments"
    $enrollments = Get-ChildItem -Path $mdmKey -ErrorAction SilentlyContinue
    foreach ($enrollment in $enrollments) {
        $props = Get-ItemProperty -Path $enrollment.PSPath -ErrorAction SilentlyContinue
        if ($props.ProviderID -eq "MS DM Server") {
            Write-Output "Device is MDM enrolled. UPN: $($props.UPN)"
        }
    }
}

# Check attestation data on the client device via Health Attestation CSP
$dsregOutput = dsregcmd /status
$dsregOutput | Select-String -Pattern "AzureAdJoined|EnterpriseJoined|DomainJoined|MdmEnrollmentUrl"

# Check Device Health Attestation status on Windows 11/Server 2025 client
$attestKey = "HKLM:SOFTWAREMicrosoftPolicyManagercurrentdeviceHealthAttestation"
if (Test-Path $attestKey) {
    Get-ItemProperty -Path $attestKey
}

Step 5: Configure SCCM/ConfigMgr for On-Premises DHA

When using ConfigMgr (SCCM) as your MDM authority instead of Intune, configure DHA to point to either the Microsoft cloud DHA endpoint or your on-premises DHA server in the ConfigMgr administration console via PowerShell.

# Configure ConfigMgr DHA settings via WMI (run on ConfigMgr site server)
$siteCode = "PS1"  # Replace with your site code
$siteServer = "sccm.contoso.local"

# Connect to ConfigMgr
Import-Module "$($env:SMS_ADMIN_UI_PATH)..ConfigurationManager.psd1" -ErrorAction SilentlyContinue
Set-Location "${siteCode}:"

# Create a Compliance Policy with Health Attestation requirements
# In ConfigMgr console: Assets and Compliance > Compliance Settings > Configuration Items
# The following sets DHA server URL via Group Policy as a complement

# Configure DHA URL via Group Policy (for SCCM-managed devices)
$gpoName = "DHA Configuration"
$gpo = Get-GPO -Name $gpoName -ErrorAction SilentlyContinue
if (-not $gpo) {
    $gpo = New-GPO -Name $gpoName -Comment "Device Health Attestation server URL"
}

# Set the DHA server URL registry value via GPO
Set-GPRegistryValue -Name $gpoName `
    -Key "HKLMSOFTWAREPoliciesMicrosoftWindowsHealthAttestation" `
    -ValueName "DhaServiceUrl" `
    -Type String `
    -Value "https://dha.contoso.local:443/DeviceHealthAttestation"

Set-GPRegistryValue -Name $gpoName `
    -Key "HKLMSOFTWAREPoliciesMicrosoftWindowsHealthAttestation" `
    -ValueName "EnableHealthAttestation" `
    -Type DWord `
    -Value 1

# Link GPO to the Computers OU
New-GPLink -Name $gpoName -Target "OU=Computers,DC=contoso,DC=local"

Step 6: Configure Conditional Access Based on Health Attestation

DHA delivers its greatest security value when wired into Conditional Access policies that block non-attested devices from accessing sensitive resources. The compliance state flows from the DHA measurement through MDM into Azure AD Conditional Access.

# Check current device compliance state (run on enrolled client)
$complianceKey = "HKLM:SOFTWAREMicrosoftPolicyManagercurrentdevice"
Get-ChildItem -Path $complianceKey -Recurse -ErrorAction SilentlyContinue |
    Get-ItemProperty | Where-Object { $_.PSChildName -like "*Health*" }

# Verify BitLocker attestation evidence is being reported
$bitlockerStatus = Get-BitLockerVolume -MountPoint "C:" |
    Select-Object VolumeStatus, ProtectionStatus, EncryptionMethod, EncryptionPercentage
Write-Output $bitlockerStatus

# Verify Secure Boot is in the TPM measurements (check TCG logs)
$tcgLogPath = "$env:windirLogsMeasuredBoot"
$latestLog = Get-ChildItem -Path $tcgLogPath -ErrorAction SilentlyContinue |
    Sort-Object LastWriteTime -Descending | Select-Object -First 1

if ($latestLog) {
    Write-Output "TCG Boot Log found: $($latestLog.FullName)"
    Write-Output "Size: $($latestLog.Length) bytes"
    Write-Output "Last modified: $($latestLog.LastWriteTime)"
} else {
    Write-Warning "No TCG boot log found. TPM may not be logging measurements."
}

# Check Windows Security Center for ELAM/Early Launch status
Get-MpComputerStatus | Select-Object `
    AntivirusEnabled, `
    BehaviorMonitorEnabled, `
    IoavProtectionEnabled, `
    NISEnabled, `
    RealTimeProtectionEnabled, `
    AMServiceEnabled

Step 7: Verify Attestation Status via MDM Portal and PowerShell

Once devices are configured, verify that attestation reports are reaching the MDM system and that the compliance status accurately reflects each device’s measured boot state.

# Force an MDM sync to push latest health attestation data
# Run on the client device
$session = New-CimSession
Invoke-CimMethod -Namespace "rootcimv2mdmdmmap" `
    -ClassName "MDM_Client" `
    -MethodName "StartEnterpriseDeviceRecovery" `
    -CimSession $session -ErrorAction SilentlyContinue

# Alternative: trigger via OMA-DM sync
Start-Process -FilePath "ms-settings:workplace" -ErrorAction SilentlyContinue

# Check DHA event logs on the DHA server
Get-WinEvent -LogName "Microsoft-Windows-DeviceHealthAttestation/Admin" -MaxEvents 50 |
    Select-Object TimeCreated, LevelDisplayName, Message |
    Format-List

# Check DHA service health
Get-WinEvent -LogName "System" |
    Where-Object { $_.ProviderName -like "*DHA*" -or $_.Message -like "*HealthAttestation*" } |
    Select-Object -First 20 | Format-Table TimeCreated, Message -AutoSize

# Monitor DHA IIS logs for successful attestation requests
$iisLogPath = "C:inetpublogsLogFilesW3SVC1"
$todayLog = Get-ChildItem -Path $iisLogPath -Filter "*.log" |
    Sort-Object LastWriteTime -Descending | Select-Object -First 1
Get-Content $todayLog.FullName | Select-String "HealthAttestation" | Select-Object -Last 20

Conclusion

Device Health Attestation on Windows Server 2025 represents a fundamental shift from trusting devices because they have a certificate to trusting devices because their entire boot chain is cryptographically verified. By integrating TPM 2.0 measurements, UEFI Secure Boot enforcement, BitLocker pre-boot protection, and ELAM driver validation into a single attestation report that flows into your MDM compliance policies, you close off an entire class of attacks where malware or a bootkit could persist beneath the OS and go undetected by traditional endpoint security tools. Whether you deploy the cloud-based DHA service through Microsoft Intune or stand up the on-premises role in a ConfigMgr environment, the Conditional Access policies built on top of attested compliance state ensure that only devices in a verified healthy boot state can access your organization’s most sensitive resources.

Links

Newsletter

Contact