Microsoft Intune MAA Connectivity Validation Guide

🔐 Microsoft Intune MAA Connectivity Validation Guide

This guide provides a practical method for validating network connectivity from a Windows 11 endpoint to the Microsoft Azure Attestation (MAA) endpoints used by Microsoft Intune.

The objective is to determine whether DNS resolution, TCP 443 connectivity, HTTPS communication, proxy configuration and possible TLS inspection issues could prevent the endpoint from reaching the required MAA service.

Executive Summary

This guide validates the network path to the Microsoft Azure Attestation service. It is designed to help administrators distinguish a connectivity problem from a device health, Intune policy or compliance configuration problem.

A successful test confirms that the tested endpoint can reach the MAA service over HTTPS. It does not by itself prove that a Windows Health Attestation session or Intune compliance evaluation has successfully completed.

Important:
Always verify Microsoft's current Intune network endpoint documentation before implementing firewall, proxy or SSL inspection changes. Microsoft service endpoints can change over time.

On this page

What Is Changing?
Who Needs to Validate This?
Step 1 – Identify the MAA Endpoints
Step 2 – Validate DNS, TCP 443 and HTTPS
Step 3 – Check Proxy Configuration
Step 4 – Check for SSL/TLS Inspection
Step 5 – Optional SYSTEM Context Test
Step 6 – Interpret the Results
Intune Compliance Considerations
What Windows Health Attestation Actually Does
Validate From the Actual Windows 11 Client
Validation Checklist
Example: Successful Network Validation
What This Test Does Not Prove
Enterprise Best Practices
Microsoft Documentation
Final Summary

🧠 What Is Changing?

Windows Health Attestation provides security-related health information that can be used by Microsoft Intune when evaluating device compliance.

For Windows 11 devices, Microsoft Intune can use Microsoft Azure Attestation (MAA) for Device Health attestation based on the Intune tenant location.

This is particularly relevant when Intune compliance policies use Device Health settings such as:

BitLocker
Secure Boot
Code Integrity

Potential impact:
If a firewall or network security solution blocks the required MAA endpoints, Windows 11 devices using affected Device Health compliance settings may be unable to obtain the required attestation information and can fall out of compliance.

Microsoft states that Windows 10 and GCCH/DOD environments continue to use the existing DHA endpoint and are not affected by this specific Windows 11 MAA migration.

🏢 Who Needs to Validate This?

This validation is most relevant for organizations that restrict outbound Internet traffic using:

Firewalls
Web proxies
URL allowlists
Network security appliances
SSL/TLS inspection

If the environment allows unrestricted outbound HTTPS traffic, the risk of an MAA connectivity issue caused by network filtering is generally lower.

Goal:
The purpose of this guide is to validate network connectivity. It is not intended to change Intune compliance policies or replace Microsoft's Health Attestation diagnostics.

🌍 Step 1 – Identify the MAA Endpoints

Microsoft provides region-specific MAA endpoints for Intune. The applicable endpoints depend on the location of the Intune tenant.

To identify the tenant location, open:

Microsoft Intune admin center

Tenant administration → Tenant status → Tenant details → Tenant location

For the Europe region, Microsoft currently lists:

intunemaape7.neu.attest.azure.net
intunemaape8.neu.attest.azure.net
intunemaape9.neu.attest.azure.net
intunemaape10.weu.attest.azure.net
intunemaape11.weu.attest.azure.net
intunemaape12.weu.attest.azure.net

Endpoint list last verified against Microsoft Learn: 2026-09-17 — re-check before relying on it, Microsoft can change these.

Do not use the Europe endpoints blindly.
If the Intune tenant is located in North America or Asia Pacific, use the endpoints listed by Microsoft for that region instead.

Official Microsoft documentation:
Network endpoints for Microsoft Intune

🔎 Step 2 – Validate DNS, TCP 443 and HTTPS

The following test checks three basic layers of connectivity:

DNS – Can the client resolve the MAA hostname?
TCP 443 – Can the client establish a TCP connection to the service?
HTTPS – Can the client establish HTTPS communication and receive an HTTP response?

If DNS resolution fails for an endpoint, the script skips the TCP and HTTPS checks for that endpoint rather than waiting on tests that cannot meaningfully succeed — this keeps a run against all six endpoints fast even when several are blocked.

$endpoints = @(
    "intunemaape7.neu.attest.azure.net",
    "intunemaape8.neu.attest.azure.net",
    "intunemaape9.neu.attest.azure.net",
    "intunemaape10.weu.attest.azure.net",
    "intunemaape11.weu.attest.azure.net",
    "intunemaape12.weu.attest.azure.net"
)

$results = foreach ($endpoint in $endpoints) {

    Write-Host "`nTesting $endpoint" -ForegroundColor Cyan

    $dnsIP = $null
    $dnsStatus = "Failed"

    try {
        $dns = Resolve-DnsName `
            -Name $endpoint `
            -Type A `
            -ErrorAction Stop

        $dnsIP = (
            $dns |
            Where-Object { $_.Type -eq "A" } |
            Select-Object -First 1 -ExpandProperty IPAddress
        )

        if ($dnsIP) {
            $dnsStatus = "Success"
        }
    }
    catch {
        $dnsStatus = "Failed"
    }

    if ($dnsStatus -eq "Success") {

        try {
            $tcpResult = Test-NetConnection `
                -ComputerName $endpoint `
                -Port 443 `
                -WarningAction SilentlyContinue `
                -ErrorAction Stop

            $tcpSucceeded = $tcpResult.TcpTestSucceeded
        }
        catch {
            $tcpSucceeded = $false
        }

        try {
            $httpsStatus = curl.exe `
                -I `
                -s `
                -o NUL `
                -w "%{http_code}" `
                --connect-timeout 10 `
                --max-time 20 `
                "https://$endpoint"

            if ([string]::IsNullOrWhiteSpace($httpsStatus)) {
                $httpsStatus = "000"
            }
        }
        catch {
            $httpsStatus = "000"
        }

    }
    else {
        $tcpSucceeded = "Skipped"
        $httpsStatus  = "Skipped"
    }

    [PSCustomObject]@{
        Endpoint = $endpoint
        DNS      = $dnsStatus
        DNS_IP   = $dnsIP
        TCP_443  = $tcpSucceeded
        HTTPS    = $httpsStatus
    }
}

$results | Format-Table -AutoSize

$passCount = (
    $results |
    Where-Object {
        $_.DNS -eq "Success" -and
        $_.TCP_443 -eq $true -and
        $_.HTTPS -match '^\d{3}$'
    }
).Count

$totalCount = $results.Count
$summaryColor = if ($passCount -eq $totalCount) { "Green" } else { "Yellow" }

Write-Host "`nSummary: $passCount of $totalCount endpoints reachable" -ForegroundColor $summaryColor

$desktopPath = [Environment]::GetFolderPath("Desktop")
$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$csvPath = Join-Path $desktopPath "MAA-Connectivity-$timestamp.csv"

$results | Export-Csv `
    -Path $csvPath `
    -NoTypeInformation `
    -Encoding UTF8

Write-Host "`n============================================" -ForegroundColor Green
Write-Host "MAA NETWORK TEST COMPLETE" -ForegroundColor Green
Write-Host "CSV exported to:" -ForegroundColor Green
Write-Host $csvPath -ForegroundColor Yellow
Write-Host "============================================" -ForegroundColor Green

Example result

Endpoint                              DNS       DNS_IP       TCP_443    HTTPS
--------                              ---       ------       -------    -----
intunemaape7.neu.attest.azure.net    Success   x.x.x.x      True       404
intunemaape8.neu.attest.azure.net    Success   x.x.x.x      True       404
intunemaape9.neu.attest.azure.net    Success   x.x.x.x      True       404
intunemaape10.weu.attest.azure.net   Success   x.x.x.x      True       404
intunemaape11.weu.attest.azure.net   Success   x.x.x.x      True       404
intunemaape12.weu.attest.azure.net   Success   x.x.x.x      True       404

Summary: 6 of 6 endpoints reachable

Typical successful network result:

DNS = Success
TCP_443 = True
HTTPS = an HTTP response such as 200, 301, 302, 401, 403 or 404

The script also exports the results to a timestamped CSV file on the current user's desktop, using the actual redirected Desktop folder even in OneDrive Known Folder Move environments. This can be useful for documenting validation results or attaching them to a support case.

Understanding the results

Result	Meaning
DNS = Success	The MAA hostname was successfully resolved by DNS.
DNS = Failed	The MAA hostname could not be resolved. TCP and HTTPS checks are skipped for that endpoint since they cannot meaningfully succeed without DNS.
TCP_443 = True	The client successfully established a TCP connection to port 443.
HTTPS = HTTP status	HTTPS communication reached the remote service and an HTTP response was received. A 404 here is expected and fine — the important thing is that a status code came back at all, not which one.
HTTPS = 000	curl did not receive an HTTP status code. Investigate connectivity, TLS negotiation, proxy configuration or network inspection.

Important:
HTTP status 000 is not an HTTP status code. It is used by this test to indicate that curl did not receive a valid HTTP response code. A 404 response, by contrast, means the HTTPS request reached the service and got an answer — treat it as a pass for this reachability test, not as a problem to chase.

Key distinction:
For this network test, any HTTP response demonstrates that the HTTPS request reached the remote service. It does not prove that an actual MAA attestation transaction succeeded.

🔐 Step 3 – Check Proxy Configuration

Enterprise environments can use different proxy mechanisms depending on the Windows component or application making the connection. Therefore, checking only WinHTTP may not provide the complete picture.

Check WinHTTP proxy

netsh winhttp show proxy

Check the current user's Internet proxy settings

Get-ItemProperty `
    "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
    Select-Object ProxyEnable, ProxyServer, AutoConfigURL

Direct connection

Current WinHTTP proxy settings:

    Direct access (no proxy server).

This indicates that WinHTTP is configured for direct access.

Proxy configured

If a proxy server is configured, verify that outbound HTTPS traffic to the required MAA endpoints is allowed and that the proxy does not interfere with the HTTPS/TLS connection.

Important:
WinHTTP proxy settings and the current user's Internet Settings are different configuration areas. Check both when troubleshooting enterprise proxy-related connectivity problems.

🛡️ Step 4 – Check for SSL/TLS Inspection

One of the most important considerations in enterprise environments is SSL/TLS inspection.

Microsoft's Intune network endpoint guidance states that SSL traffic inspection should not be applied to the relevant MAA endpoints.

A verbose HTTPS test can provide additional information about the connection:

curl.exe -v https://intunemaape10.weu.attest.azure.net

Look for output showing that the TLS connection was established and that the remote service returned an HTTP response.

Check the certificate issuer

When TLS inspection is suspected, inspect the certificate presented to the client.

If the certificate chain is issued or re-signed by an organization's security appliance rather than the expected public certificate chain, this can be a strong indication that TLS inspection is taking place.

The certificate issuer alone should not be treated as absolute proof. Confirm the result against the organization's proxy or firewall configuration.

Common enterprise security platforms that may perform TLS inspection include:

Zscaler
Palo Alto Networks
Fortinet
Blue Coat / Symantec
Other enterprise proxy or security appliances

Important:
Do not assume that TCP 443 connectivity alone proves that SSL/TLS inspection is not occurring.

TLS troubleshooting

If TCP 443 succeeds but HTTPS communication fails, investigate:

TLS negotiation
Certificate validation
Proxy behavior
SSL/TLS inspection
Security appliance policies
Outbound HTTPS filtering

The objective is to ensure that the network security infrastructure does not prevent the Windows 11 client from establishing the required HTTPS connection to the MAA endpoint.

🖥️ Step 5 – Optional SYSTEM Context Test

Testing from a normal administrator PowerShell session can confirm connectivity from the interactive user's network context. In some troubleshooting scenarios, however, it can also be useful to repeat the test under the SYSTEM security context.

This is particularly useful when:

User-context testing succeeds
Intune-related functionality still appears unable to communicate
The environment uses different proxy or security behavior for SYSTEM
You suspect machine-level network restrictions

Before you use PsExec:
PsExec requires local administrator rights, is not installed by default, and its download needs to be done separately from Sysinternals. Some endpoint security tools flag PsExec activity because it is also commonly abused for lateral movement — expect it to trigger alerts in a monitored environment and clear it with your security team first if that's a concern.

psexec.exe -i -s powershell.exe

After opening the SYSTEM PowerShell session, verify the security context:

whoami

The expected result is:

nt authority\system

Run the same MAA connectivity test from this session and compare the results with the normal user-context test.

Why this matters:
A difference between user and SYSTEM results can point toward machine-level proxy configuration, security policy, service context behavior or network filtering rather than a general Internet connectivity problem.

PsExec is part of Microsoft's Sysinternals utilities:

Microsoft Sysinternals PsExec

🧭 Step 6 – Interpret the Results

DNS resolution fails
→ Investigate DNS, filtering or name resolution.

DNS works but TCP 443 fails
→ Investigate firewall, routing or outbound network restrictions.

TCP 443 works but HTTPS returns 000 or fails
→ Investigate proxy configuration, TLS negotiation or network inspection.

HTTPS returns an HTTP response
→ The basic HTTPS path to the endpoint is working.

HTTPS returns 404
→ The HTTPS request reached the service; the tested root URL may not expose a resource at that path.

User context works but SYSTEM context fails
→ Investigate machine-level proxy configuration, security policies or SYSTEM-specific network behavior.

Certificate indicates possible TLS inspection
→ Review the proxy/firewall configuration and verify the required MAA exclusions.

All network checks pass
→ Continue investigating device health, HealthAttestation CSP, Intune policy configuration or compliance state if problems remain.

🏢 Intune Compliance Considerations

MAA connectivity is particularly important when Windows 11 compliance policies use Device Health settings.

BitLocker
Secure Boot
Code Integrity

If the attestation service cannot be reached, Intune may not receive the required health attestation information when evaluating compliance.

Network validation is only one layer.
A successful MAA network test should be used to help rule out connectivity problems. It should not be interpreted as proof that the device's health attestation or Intune compliance evaluation is healthy.

🔬 What Windows Health Attestation Actually Does

Windows Health Attestation involves more than a simple HTTPS connection. The Windows HealthAttestation CSP can collect security-related device information, communicate with the attestation service and maintain attestation status and reports.

Windows 11 includes MAA-related HealthAttestation functionality that allows the device to communicate with a Microsoft Azure Attestation service instance configured for the attestation flow.

For example, the HealthAttestation CSP exposes information such as:

Attestation status
Attestation error information
Service correlation IDs
Attestation reports
TPM readiness information

Important distinction:
The connectivity script in this guide does not query or validate every HealthAttestation CSP state. It validates the underlying network path to the MAA endpoint.

For detailed HealthAttestation CSP diagnostics, refer to Microsoft's official documentation:

HealthAttestation CSP

🖥️ Validate From the Actual Windows 11 Client

Whenever possible, perform the test directly from an affected or representative Windows 11 device.

Testing from an administrator workstation or server does not necessarily represent the network path used by the managed endpoint.

Test from the Windows 11 client
Test while connected to the corporate network
Test from the same VLAN or network segment used by managed devices
Test with the same proxy configuration used by the affected device
Repeat testing from different network locations when applicable
Compare user and SYSTEM context when troubleshooting advanced cases

📋 Validation Checklist

Check	Expected Result
Tenant location	Correct Intune tenant region identified
MAA endpoints	Current Microsoft endpoints for the tenant region
DNS resolution	MAA hostname resolves successfully
TCP 443	True
HTTPS	An HTTP response is received
HTTP status	Any HTTP response demonstrates HTTPS reachability
WinHTTP proxy	Direct or correctly configured proxy
User proxy	Direct or correctly configured proxy
SSL/TLS inspection	Not applied where Microsoft requires exclusion
SYSTEM test	Optional comparison for advanced troubleshooting
Intune compliance	Investigated separately after network validation

Do not overinterpret the result:
This conclusion means that the tested network path is reachable. It does not prove that the complete MAA attestation flow or Intune compliance evaluation has succeeded.

⚠️ What This Test Does Not Prove

Successful network connectivity does not guarantee that every Intune compliance evaluation will succeed.

This guide validates the network path to the MAA service. It does not validate:

Intune compliance policy configuration
Device Health policy configuration
TPM health
Secure Boot state
BitLocker state
Code Integrity state
Entra ID device registration
HealthAttestation CSP status
MAA attestation policy evaluation
Overall device compliance

Scope of this guide:
Treat this as a network connectivity validation, not as a complete Windows Health Attestation diagnostic.

📈 Enterprise Best Practices

Validate MAA connectivity before applying firewall or proxy changes.
Test from representative Windows 11 clients.
Review firewall and proxy allowlists.
Review SSL/TLS inspection exclusions.
Check both WinHTTP and user-level proxy configuration.
Compare user and SYSTEM context when troubleshooting advanced cases.
Document the tested endpoints and results.
Export and retain CSV results when troubleshooting multiple devices.
Monitor Intune compliance after the migration.
Keep network allowlists aligned with Microsoft's current documentation.

Recommended approach:
Treat Microsoft service endpoints as a continuously changing dependency. Review Microsoft's current Intune network requirements rather than relying on an old static firewall list.

📚 Microsoft Documentation

For authoritative and current information, always use Microsoft's official documentation.

✅ Final Summary

Scenario	Recommended Action
DNS fails	Investigate DNS, filtering and name resolution.
TCP 443 fails	Check firewall, routing and outbound restrictions.
TCP works but HTTPS returns 000	Investigate proxy, TLS negotiation and network inspection.
HTTPS returns an HTTP response	HTTPS communication reached the service; continue validation.
HTTPS returns 404	The HTTPS request reached the service. A 404 from the tested root URL does not automatically indicate a connectivity problem.
User context works but SYSTEM context fails	Investigate machine-level proxy, security policy or SYSTEM-specific network behavior.
Proxy configured	Verify that the required MAA endpoints are allowed and that the proxy does not interfere with HTTPS communication.
Possible SSL inspection	Review the certificate chain and security appliance configuration.
SSL inspection enabled	Verify the required MAA exclusions according to Microsoft's current requirements.
All network tests pass	If compliance problems remain, continue with device health, HealthAttestation CSP and Intune policy diagnostics.

📝 Author's Note

This guide focuses on practical validation from a Windows 11 endpoint. The commands are intended to help administrators quickly determine whether network connectivity to Microsoft Azure Attestation is available before investigating more complex Intune compliance or Health Attestation issues.

The guide intentionally separates network reachability from actual attestation success. This distinction is important when troubleshooting enterprise environments where DNS, firewalls, proxies, SSL inspection and endpoint security controls can affect connectivity independently of the device's actual security state.

Leta i den här bloggen

Tech Trends and Insights

Windows 11 Compliance in Intune: Preparing for the Migration from Device Health Attestation (DHA) to Microsoft Azure Attestation(MAA)