Why You Don't Need an AVD Registration Key

Atlas AVD creates, reuses and replaces your host pool's Azure Virtual Desktop registration key automatically whenever it adds a session host, and more.

What a registration key is

A registration key (also called a registration token) is a short-lived secret that Azure Virtual Desktop issues for a host pool. A new VM presents it once, when its AVD agent first joins the pool. After that the session host has its own identity and never uses the key again. Each host pool holds at most one key at a time, and every key has an expiry date.

How Atlas handles it

Every time Atlas adds a VM to a host pool, it gets the key for you at the moment it is needed. That covers Create Host, re-imaging (including the Replace option, which builds new VMs before retiring the old ones), a provisioning job that resumes after a restart, and AVD Hybrid hosts.

  • If the host pool already has a key with more than an hour left, Atlas reuses it.
  • If there is no key, or it expires within the hour, Atlas asks Azure for a new one that is valid for 4 hours. Azure keeps one key per host pool, so the new key replaces the old one.
  • When you add several VMs at once, they share one key, so a large batch does not create a key per VM.
  • Atlas passes the key straight to the VM's agent install during provisioning. It is never shown on screen or stored in your settings.

The one-hour margin is deliberate: a key that is about to expire could run out while a VM is still being built, so Atlas replaces it rather than risk the VM failing to join the pool.

Why you don't need to rotate or revoke it

  • Keys expire on their own within 4 hours of being created, so there is no long-lived secret to protect or rotate.
  • Session hosts that already joined the pool don't use the key, so a key expiring or being replaced never affects running hosts or signed-in users.
  • If you generated or deleted a key in the Azure portal yourself, that's fine. The next time Atlas adds a VM it checks the key and creates a new one if needed.

See it working

Open the host pool and look at the provisioning history on its Overview. Each provisioning job's log records whether Atlas reused the pool's registration key or created a new one, with its expiry time. A new VM that reaches the Available status in the Session Hosts table has used the key successfully.

If a new VM stays in a not-available state, the cause is almost never the registration key. Check the job log for the step that failed, and see Configuring Session Hosts.

Next steps