Re-registering an AVD Session Host After a Host Pool Outage

One of the more confusing Azure Virtual Desktop issues is when a session host drops out of the host pool and refuses to register again.

![AVD](/assets\img\2026-06-16-AVD-reregister-hostpools\01.png

The error usually looks like this:

WVD-Agent service is being stopped: NAME_ALREADY_REGISTERED
This VM needs to be properly registered in order to participate in the deployment

At first glance this looks like a token problem, but in many cases it is actually a name collision. The old session host object is still present in the host pool, so the VM tries to register with a name that already exists.

Typical scenario

I usually see this after one of the following events:

• the session host was restored from backup
• the VM was rebuilt or cloned
• the host pool deployment partially failed
• the VM dropped out of the host pool but the old session host entry remained behind

The important part is that re-registration is not only a VM-side action. If the old host name is still present in the host pool, the new registration can collide with that stale object.

What to check first

Before changing anything on the VM, verify these items:

• the VM is supposed to register to the correct host pool
• the registration token is fresh and still valid
• the same session host name already exists under Session hosts
• the RDAgentBootLoader and RDAgent services exist on the VM

If the old host record is still present in the host pool, do not start with endless service restarts. Remove the stale host pool entry first.

Correct order of operations

This is the sequence that works reliably:

1. Check the host pool for the old session host entry.
2. Remove the old session host object from the host pool.
3. Generate a new registration token.
4. Re-register the VM with the new token.

That second step is the important one. If you skip it, the re-registration may fail again with NAME_ALREADY_REGISTERED because the old name is still reserved by the stale session host object.

Remove the old session host first

In the Azure Portal:

1. Open the Azure Virtual Desktop host pool.
2. Go to Session hosts.
3. Find the old host with the same VM name.
4. Remove that session host entry.

Only after that should you generate a fresh registration token and start the re-registration on the VM.

Re-register the VM from Run Command

After the stale host entry is removed, the VM can be re-registered with a fresh token. The following PowerShell can be run from Azure Portal Run command on the VM.

$RegistrationToken = "PASTE_A_FRESH_TOKEN_HERE"

$path = "HKLM:\SOFTWARE\Microsoft\RDInfraAgent"

if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}

Set-ItemProperty -Path $path -Name "IsRegistered" -Value 0 -Force
Set-ItemProperty -Path $path -Name "RegistrationToken" -Value $RegistrationToken -Force

Restart-Service RDAgentBootLoader -Force

Start-Sleep -Seconds 45

Write-Output "RDInfraAgent registry state:"
Get-ItemProperty -Path $path -Name IsRegistered | Select-Object IsRegistered
Get-ItemProperty -Path $path -Name RegistrationToken | Select-Object RegistrationToken

Write-Output "Services:"
Get-Service RDAgentBootLoader, RDAgent | Select-Object Name, Status

This script is meant to run directly on the VM. If you use Azure Portal Run command, paste only the PowerShell above. Do not wrap it in Invoke-AzVMRunCommand.

Why the old name causes the failure

The agent is not only checking whether it has a token. It is also trying to register itself as a session host in the target host pool. If the previous record with the same name is still there, Azure Virtual Desktop treats that as an existing object and rejects the new registration attempt.

That is why simply updating the token often does not solve the issue.

The conflict must be removed first, then the VM can register cleanly.

Prevention

If you keep AVD session hosts powered off for long periods, do not leave them completely offline for more than 90 days.

A more practical rule is to start them every 60 or 75 days and let them run for 20 to 30 minutes. That simple maintenance window is usually enough to avoid falling too far out of sync and reduces the chance of registration issues later.

Final note

If a session host falls out of an AVD host pool and you need to re-register it, always check for the old host name first. In this case the working fix is not just “generate a new token and retry”. The safe order is:

1. remove the stale session host entry
2. generate a new registration token
3. re-register the VM

That sequence avoids the name collision and usually brings the host back into the pool cleanly.