Fixing AVD Error NAME_ALREADY_REGISTERED: A Real-World RDAgentBootLoader Saga — Part II

Rebuilding a session host in AVD should be one of the simpler operations in the platform. Delete the broken VM, re-provision a fresh one from the host pool, wait for the agent to register, and you’re done. Except this time, the fresh deployment didn’t proceed cleanly — instead it returned a different error that had nothing to do with the agent itself:

This error surfaced immediately after attempting to add a new VM to the same host pool using the Azure portal’s “Add virtual machines” flow. The VM name and resource names had not been changed from the previous (now-deleted) session host. That turned out to be the root of the problem.

The Starting Point

After the agent reinstall saga in Part I, the decision was made to remove the broken session host entirely and re-provision a clean one. The host pool (aavi-ss-hp) had a single session host, aavi-ss-1-0, showing Unavailable with zero sessions and no assigned user — a clean candidate for removal and replacement.

The session host aavi-ss-1-0 in an Unavailable state — the VM is running but the AVD agent won’t cooperate.

Step 1 — Remove the Session Host from the Host Pool

The first step is to deregister the session host from the host pool. Select the session host in the portal, click Remove, and confirm. The dialog is explicit about what this does — and what it doesn’t:

The Remove dialog: clears the registration and logs off sessions, but deliberately does not delete the underlying VM or its resources.

Success: 1, Failed: 0 — the AVD registration record has been cleared from the host pool.

Step 2 — Delete the VM and Associated Resources

With the AVD registration gone, the next step is to delete the actual Azure resources. Navigate to the resource group and select the VM, the network interface, and the OS disk together, then delete them as a batch. This is important — leaving orphaned NICs or disks creates unnecessary cost and potential name-collision issues on the next deployment.

All three resources selected for deletion: the VM (aavi-ss-1-0), its NIC, and its OS disk. Delete them together.

Step 3 — Re-provision a New Session Host

With the old resources gone, navigate to the host pool and use the “Add virtual machines” option to provision a fresh session host. The wizard walks through four tabs: Basics, Virtual Machines, Tags, and Review + create.

Basics tab

The Basics tab captures the host pool context — subscription, resource group, host pool name, and location. No changes needed here; these are pre-populated from the host pool.

The Basics tab. Host pool name, resource group, and location are pre-populated from the existing host pool context.

Virtual Machines tab

The Virtual Machines tab is where the name prefix matters. In this case the name prefix was changed from aavi-ss-1 (the old broken session host) to aavi-ss-01 — a small but deliberate change to avoid any residual name-collision risk. The image chosen was Windows 11 Enterprise version 25H2 on a Standard B2as v2 with a 128 GiB Standard HDD.

VM configuration: new name prefix aavi-ss-01, Windows 11 Enterprise 25H2, Standard B2as v2, 128 GiB Standard HDD.

Tags tab

Tags are applied at the resource group level using the cm-resource-parent option to group host pool costs together. An Owner tag is set to track resource ownership for billing and governance.

Tags tab — applying an Owner tag and enabling the cm-resource-parent grouping for cost management.

Review + create

Validation passes and the summary confirms all settings before committing. Always double-check the name prefix on this screen — it’s the last chance to catch a typo before the ARM deployment kicks off.

Validation passed. The summary shows the new name prefix (aavi-ss-01) and the complete VM configuration before creation.

The Error: NAME_ALREADY_REGISTERED

After clicking Create, the AddVMsToHostPool ARM deployment began but immediately stalled with no deployment details populating:

The deployment starts but the “Deployment details” section shows no results — a sign that something is being rejected early in the pipeline.

Checking the session host registration status in the host pool revealed the error. The AVD control plane had flagged the new VM as a duplicate:

Error: NAME_ALREADY_REGISTERED — the control plane considers the VM name already taken, even though the old VM and its registration were both deleted.

The official resolution path from Microsoft documentation lists five steps: remove the session host from the host pool, create another VM with a unique name, go to the host pool Overview in the portal, open the Session Hosts tab and verify all session hosts are listed, and wait 5–10 minutes for status to update to Available.

The issue here is a control-plane propagation delay. When the session host is removed from the host pool via the portal and the underlying VM is deleted from Azure, the AVD service-side registration record may not have fully cleared by the time the new deployment tries to register. The new VM’s agent sees the name as already taken and refuses to complete registration.

The Resolution

The fix is straightforward once you understands the cause.

You need to go to the Entra ID and delete this VM name.

Wait a few minutes to let the AVD control plane finish clearing the old registration, then trigger a new deployment with either the same name (now safe) or a new prefix, so the deployment was simply re-submitted:

Your deployment is complete — the VM was provisioned and the AVD agent registered successfully with the host pool.

Back in the host pool, the overview now shows the new session host alongside the resolution:

Host pool overview: 2 total machines — one can connect (the new session host), one cannot (the old unavailable one still appearing during control-plane cleanup).

Verification

The session hosts list confirmed the new VM registered cleanly with an Available health state and drain mode off:

aavi-ss-01-0 is Running and Available. Agent version 1.0.14506.600 confirms a fresh registration with the current agent build.

The session host list after cleanup — the new host is healthy and ready for user assignment.

The real test is an end-to-end connection. Launching the session from the Windows App client:

The connection prompt confirms the correct new session host (aavi-ss-01-0) and the right user account.

Windows 11 lock screen loading — the session host accepted the connection and is signing in the user.

Full desktop session established. The session host is healthy and serving connections normally.

And the final confirmation — the hostname inside the session:

hostname confirms the VM name inside the session matches the newly provisioned session host: aavi-ss-01-0.

Takeaways

Bringing Part I and Part II together, a few generalizable lessons from this two-part incident:

1. “VM running, host unavailable” is always an agent problem. Skip VM-level diagnostics and go straight to the RDAgent and RDAgentBootLoader service states inside the VM.
2. A service that won’t stay running is corrupted, not glitchy. Plan for a full reinstall rather than repeated service restarts.
3. Silent MSI installs can hang on locked services. If a scripted uninstall stalls waiting for a service to stop, the GUI installers are a reliable fallback.
4. MSI error 1603 plus duplicate entries in Programs and Features means an incomplete prior uninstall is in the way. Clear folders, registry, and service entries before reinstalling.
5. Always verify the registration token field before clicking Install — placeholders like INVALID_TOKEN are easy to miss when working from a saved script.
6. Know when to stop debugging and rebuild. A host pool image makes session hosts disposable by design — use that advantage when an individual VM has degraded beyond easy repair.
7. NAME_ALREADY_REGISTERED is a conflict with the VM name in Entra ID. Wait a few minutes after removing the old session host and deleting the VM before re-deploying and delete the record from Entra ID, or use a new name prefix to sidestep it entirely.
8. Remove from host pool and delete from Azure are two separate operations. Both must be done if you want to reuse a name — the portal’s Remove action only handles the AVD side, It has to be deleted from Entra ID

Published on whyazure.in — Azure Virtual Desktop, Windows 365 and Citrix Blog

Part I: Fixing Azure Virtual Desktop Error 0x3000047 — A Real-World RDAgentBootLoader Saga Part I