Azure Virtual Desktop: Session Host Unavailability Despite Power State — Domain Join and Health Check Issues

Question

Problem description

I am facing an issue where my Azure Virtual Desktop session hosts are powered on, but their health state is marked as unavailable. The only error message I have is related to a domain join check, indicating that the session host may not be properly domain joined or that there's a trust issue. This problem affects multiple users daily, and I cannot connect to the VDI.

Environment

An Azure Virtual Desktop session-host deployment with multiple hosts in a host pool. The affected hosts are powered on, but their health status shows as unavailable. No specific region, SKU, or resource names are provided.

What I've already tried

I have reviewed the support case details and the guidance related to domain join failures. I have not performed any specific troubleshooting steps, configuration changes, or log reviews beyond the initial support review.

Current status

Currently, the session hosts are still marked as unavailable in Azure Virtual Desktop, despite being powered on. The only known issue is the domain join health check failure. I am seeking assistance to diagnose and resolve the domain join or trust issues to restore host health status and enable user connections.

Answer 1

Hi @Glenn-9040

Since the session hosts are powered on but Azure Virtual Desktop reports them as Unavailable, the VM power state itself isn't the problem. The domain health-check failure is the key detail here.

Azure Virtual Desktop runs health checks independently of the VM's Azure power state. DomainJoinedCheck and DomainTrustCheck are fatal checks: if either fails, the session host can remain Unavailable and won't accept user connections.

First, determine whether this is an actual domain-join problem, a broken secure channel, or inability to reach a domain controller.

On one affected session host, run:

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain
Test-ComputerSecureChannel -Verbose
nltest /sc_verify:<your-domain-fqdn>
nltest /dsgetdc:<your-domain-fqdn>

Also verify DNS:

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName <your-domain-fqdn>

For an Active Directory domain-joined AVD deployment, the session hosts need working DNS resolution and network connectivity to the domain controllers. If DNS on the session-host subnet points only to public/Azure DNS rather than DNS capable of resolving your AD domain, the VM can be powered on while domain authentication/trust checks fail.

If:

Test-ComputerSecureChannel

returns False, or nltest /sc_verify reports a trust/password error, that strongly points to a broken machine-account secure channel. Before removing and rejoining the VM to the domain, you can test repairing it with appropriate domain credentials:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Then restart the VM and check the AVD health state again.

Don't remove all session hosts from the domain and rejoin them immediately, especially since multiple hosts are affected. If several hosts started failing around the same time, first look for a shared dependency such as DNS, domain-controller reachability, firewall/NSG/routing changes, or an AD-side issue. Rejoining every machine could temporarily hide the underlying problem.

If the secure channel tests successfully, next, inspect the exact AVD health-check results rather than assuming the domain is the only failure. In the Azure portal, go to:

Azure Virtual Desktop → Host pools → your host pool → Session hosts → select an affected host

and check which health checks are failing. This is to distinguish DomainJoinedCheck, DomainTrustCheck, and the Side-by-side (SxS) Stack Listener check; the latter is also fatal if it fails.

Also validate that the host can reach the required Azure Virtual Desktop endpoints. Microsoft provides the Azure Virtual Desktop Agent URL Tool with the AVD Agent specifically for this purpose; it reports required FQDNs/endpoints that the session host can't reach.

Since you mentioned this happens to multiple users daily, the most useful next information would be the output from one affected host for:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:<domain>

nltest /dsgetdc:<domain>

together with the exact failed AVD health-check names and messages. Please redact the domain/host names if necessary.

If DomainTrustCheck is failing while Test-ComputerSecureChannel and nltest consistently succeed, that distinction is particularly important. We should then investigate the AVD Agent/health-check path rather than repeatedly repairing the AD trust.

References:

AVD session host statuses and health checks

Troubleshoot AVD Agent issues

Check access to required AVD FQDNs and endpoints

Required FQDNs and endpoints for Azure Virtual Desktop

---

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.