AVD session host VM deploys successfully but never registers to host pool (Host pool shows 0 session hosts) — tried 4 times

Question

Hi all, I’m trying to deploy Azure Virtual Desktop (AVD) and I’m stuck on a repeatable issue: session host VMs deploy successfully in Azure, but the host pool still shows 0 session hosts (no VMs listed under Host pool → Session hosts). I’ve tried four times with the same result.

What I’m seeing (symptoms)

• I create a pooled host pool and add a session host via Host pools → Session hosts → + Add.
• The ARM deployment completes successfully.
• The VM exists and is running in Azure (Compute → Virtual machines).
• VM extensions appear successful (including AADLoginForWindows).
• But the host pool overview shows “Total virtual machines: 0”, and Session hosts list is empty.
• Because the host pool has 0 session hosts, users cannot connect.

General configuration (no sensitive info)

• Host pool type: Pooled
• Load balancing: Breadth-first
• Max session limit: 5
• Region: West US 2
• Session host OS image: Windows 11 Enterprise multi-session + Microsoft 365 Apps
• VM size: D-series (8 vCPU / 32 GB class)
• Disk: Standard SSD (128 GB)
• Security type: Trusted launch VM, Secure Boot enabled, vTPM enabled
• Network:
  • Custom VNet + subnet
    • NSG: Basic
      • Public inbound ports: No (no public RDP)
      • Identity:
        • Microsoft Entra ID join
          • Enroll VM with Intune: No
          • RBAC:
            • Users are in an Entra ID security group
              • Group has Virtual Machine User Login assigned at the Resource Group scope
                • Users assigned to the Desktop Application Group
                • Device join setting:
                  • Entra ID: “Users may join devices to Azure AD” = Yes

What I’ve tried (so far)

1. Deleted/recreated session host VM(s) multiple times
2. Regenerated the host pool registration key (new key, short expiry)
3. Confirmed Entra ID device join allowed
4. Verified RBAC + application group assignment
5. Confirmed VM creation and extensions show success
6. Verified the host pool remains at 0 session hosts after each attempt
7. Tried creating a fresh host pool again to rule out naming/caching

Questions for the community

1. What causes a VM to deploy successfully but never register as an AVD session host (host pool stays at 0)?
2. Which logs/events are the most definitive to confirm the registration failure?
   • Is Event Viewer → Applications and Services Logs → Microsoft → RDInfraAgent the best place?
     • Are there specific error IDs/messages to look for?
     1. Are there known issues with Entra ID–joined session hosts where AADLoginForWindows succeeds but the AVD agent doesn’t register?
     2. Any common “gotchas” (Conditional Access, endpoint requirements, required outbound URLs, agent/bootloader issues) that could lead to silent non-registration?

Any guidance or a checklist for diagnosing “VM exists but not in host pool” would be greatly appreciated. I’m trying to avoid continuing to rebuild without knowing the root cause.

Thanks in advance!

Answer 1

Hello Admin Oscar Catana,

this behavior is known with the session host virtual machines being created successfully but failing to register with the Azure Virtual Desktop service. When a session host does not complete agent registration, it will not appear under Host pool -> Session hosts, and the host pool will continue to show 0 session hosts, even though the VM exists and is running. The Azure Virtual Desktop control plane only lists session hosts after the Azure Virtual Desktop Agent successfully registers the machine to the host pool. If that registration step fails, the VM remains invisible to the host pool.

Common Causes for failure:

1. Registration token issues: If the registration token is expired, invalid, or never successfully applied by the agent, registration does not complete.

On the session host VM, review: Event Viewer -> Windows Logs -> Application. Look for events from RDAgentBootLoader, WVD-Agent, or WVD-Agent-Updater

A common failure is Event ID 3277, with messages such as:

INVALID_REGISTRATION_TOKEN
EXPIRED_MACHINE_TOKEN

If these appear, generate a new registration key from the host pool and reapply it to the session host using supported re-registration steps.

1. Azure Virtual Desktop Agent or bootloader not running: The VM will not register if either of the following services is not running:
   Remote Desktop Agent Boot Loader (RDAgentBootLoader) Remote Desktop Services Infrastructure Agent If these services fail to start or crash during startup, the session host will not be registered with the host pool. Service startup failures are typically visible in the Application or System logs.
2. Outbound network connectivity to required endpoints: AVD requires outbound HTTPS connectivity from the session host to specific service endpoints. If required endpoints are blocked by an NSG, firewall, or proxy, the agent may install successfully but fail registration. Azure Virtual Desktop is not supported if required FQDNs are blocked.
   The supported way to validate this is by running the Azure Virtual Desktop Agent URL Tool (WVDAgentUrlTool.exe) from the session host VM.
3. Session host identity join issues (Microsoft Entra ID join):
   For Microsoft Entra ID–joined session hosts created through the Azure Virtual Desktop portal, the AADLoginForWindows extension being present indicates the join process ran, but it does not guarantee successful agent registration. If registration fails, the root cause is typically visible in: Azure Virtual Desktop agent logs AADLoginForWindows logs Agent health checks once registration partially succeeds
4. Duplicate or previously registered session host names: If a session host name was previously registered and not fully cleaned up, the agent may reject re-registration. This is known as a NAME_ALREADY_REGISTERED failure in agent logs. In this scenario, removing old session host records and ensuring new, unique VM names is required before redeployment.

Recommended diagnostic approach is:

• Verify the Azure Virtual Desktop Agent and Boot Loader services are running.
• Review Event Viewer application logs for Azure Virtual Desktop agent errors (especially Event ID 3277).
• Confirm the registration key is valid at deployment and not expired.
• Run the Azure Virtual Desktop Agent URL Tool to validate required endpoint access.
• Confirm the session host image and OS are supported (Windows 11 Enterprise multi-session is supported).
• Confirm agent installation completed without error and was not blocked by policy or network restrictions.

References:

• https://learn.microsoft.com/troubleshoot/azure/virtual-desktop/troubleshoot-agent
• https://learn.microsoft.com/azure/virtual-desktop/session-host-status-health-checks
• https://learn.microsoft.com/troubleshoot/azure/virtual-desktop/troubleshoot-vm-configuration
• https://learn.microsoft.com/azure/virtual-desktop/required-fqdn-endpoint
• https://learn.microsoft.com/azure/virtual-desktop/check-access-validate-required-fqdn-endpoint
• https://learn.microsoft.com/azure/virtual-desktop/add-session-hosts-host-pool

Answer 2

The VM deployment and extensions can succeed even when the Azure Virtual Desktop agent never completes registration, so the host pool shows 0 session hosts. Troubleshooting needs to focus on the AVD agent and registration token on the VM, not the ARM deployment.

A concise checklist based on supported guidance:

1. Confirm registration-token issues on the VM
   • On the session host VM, open Event Viewer → Windows Logs → Application.
   • Look for events with ID 3277 from the AVD agent that contain:
     • INVALID_REGISTRATION_TOKEN or
     • EXPIRED_MACHINE_TOKEN.
   • These indicate the registration key used during deployment is invalid or expired, so the VM never registers to the host pool even though the VM and extensions are healthy.
2. Fix invalid/expired registration token
   • In the Azure portal, generate a new registration key for the host pool (Host pool → Overview → Registration key → Generate new key) as described in Generate a registration key.
   • On the session host VM, open PowerShell as Administrator and run (replace <RegistrationToken> with the new key):

          $newKey = '<RegistrationToken>'
          
          Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "IsRegistered" -Value 0 -Force
          Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "RegistrationToken" -Value $newKey -Force
          
          Restart-Service RDAgentBootLoader
     

   • Then verify registration state:

          Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name IsRegistered | FL IsRegistered
          Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name RegistrationToken | FL RegistrationToken
     

   • Expected output:

          IsRegistered : 1
          
          RegistrationToken :
     

   • After this, the VM should appear under Host pool → Session hosts once the agent completes registration.
3. Use the “reset registration” pattern if the host still does not appear
   • Removing and re-adding the session host effectively resets registration:
     1. In the Azure portal, go to Azure Virtual Desktop → Host pools → <host pool> → Session hosts.
     2. Select the problematic VM and choose Remove. This unregisters it from the host pool.
     3. Generate a new registration key for the host pool (Host pool → Overview → Registration key → Generate new key).
     4. Reinstall the AVD agent and boot loader on the VM using the new key (per the same article section that describes generating and using a new registration key).
   • This sequence is the recommended approach when the issue is not resolved by simply updating the registry token.
4. Check for duplicate-name registration errors
   • If the VM name has been reused across attempts, the agent can fail with NAME_ALREADY_REGISTERED.
   • In that case, guidance is:
     1. Remove the session host from the host pool.
     2. Create a new VM with a unique name and add it to the host pool.
     3. Wait 5–10 minutes and confirm the status becomes Available in Host pool → Session hosts.
5. Understand why ARM deployment can succeed while registration fails
   • For host pools using a session host configuration, the domain join/registration is handled by the AVD agent, not the domain join extension.
   • As documented, this means:
     • The ARM template deployment can succeed even if domain join or registration fails.
     • The result is a healthy VM in Azure but an unhealthy/unregistered session host that never appears in the host pool.
   • Diagnostics for these failures are available in the session host details JSON and in the agent logs (Event Viewer and HKLM:\SOFTWARE\Microsoft\RDInfraAgent).
6. Where to look for definitive registration failures
   • Event Viewer → Windows Logs → Application
     • Event ID 3277 with INVALID_REGISTRATION_TOKEN or EXPIRED_MACHINE_TOKEN is definitive for token problems.
   • Event Viewer → Applications and Services Logs → Microsoft → RDInfraAgent
     • Use this for deeper agent/registration errors if the basic token fix does not resolve the issue.
   • Session host details JSON in the Azure portal (for hosts that partially registered) can also surface domain join/registration health flags.
7. Entra ID–joined hosts and common gotchas
   • For Microsoft Entra joined session hosts, registration still depends on the AVD agent and a valid registration key.
   • Users must have Virtual Machine User Login or Virtual Machine Administrator Login role assigned at VM, resource group, or subscription scope to sign in, but this does not affect whether the VM appears in the host pool; that is purely agent registration.
   • If the VM is not in the host pool at all, focus on:
     • Registration token validity and usage.
     • Agent/boot loader health and logs.
     • Duplicate VM names causing NAME_ALREADY_REGISTERED.

In summary, the most common cause of “VM exists but host pool shows 0 session hosts” in this pattern is a registration-token or agent registration failure. The definitive checks are the RDInfraAgent registry keys and Event Viewer events (especially ID 3277), followed by resetting registration using a new host pool registration key and, if needed, recreating the VM with a unique name.

---

References:

• Troubleshoot common Azure Virtual Desktop Agent issues
• Troubleshoot session host configuration and session host update in Azure Virtual Desktop
• Microsoft Entra joined session hosts in Azure Virtual Desktop