Microsoft Entra extension fails when I deploy a VM

Question

I added the WindowsAALogin extension during the creation of the VM (Windows Server 2022 DataCenter). I called the VM "ACF-ITAMS-STAGE-TESTA01".

The VM gets created, but "AADLoginforWindows" deployment failed.

The error message:

When I run dsregcmd /status on the VM, it returns the info below. What stands out the device name is "ACF-ITAMS-STAGE", but the VM is called "ACF-ITAMS-STAGE-TESTA01".

Is it cutting off the VM name because there is limit on device name? How do I ensure that Device Name matches the VM name to prevent issues when the device registered? We have a name conventions ACF-ITAMS-[environment]-[VM name] and can't just name it random things.

Answer 1

Hi @Garcia, Cha,

This behavior is expected and not an issue with the Azure VM resource name. Although Azure allows VM resource names up to 64 characters, Windows enforces a 15‑character limit on the computer (hostname). When the VM name exceeds this limit, Windows automatically truncates it, and Microsoft Entra ID registers the device using this truncated hostname, which is why dsregcmd /status shows ACF-ITAMS-STAGE instead of the full VM name.

The AADLoginForWindows extension then fails with error 0x801c0083 (hostname already used) because Entra ID requires device hostnames to be unique within the tenant. If another device (active or stale) already exists with the same truncated name, the join fails.

To prevent this, ensure that the first 15 characters of your naming convention are unique, or remove any stale device objects with the same truncated hostname from Microsoft Entra ID → Devices before redeploying the extension. The Azure VM resource name and the Entra device name do not need to match exactly, but the effective Windows hostname must be unique.

Kindly let us know if the above helps or if you need further assistance on this issue.

Answer 2

The AADLoginForWindows extension is failing because Microsoft Entra join detects that a device with the same hostname already exists in the tenant. This is a known failure mode: if a device object with the same displayName as the VM’s hostname is already present, the join fails with a “hostname is already used by another device in this tenant” error.

The truncated device name seen in dsregcmd /status is the actual Windows computer name being used for join. If that name already exists as a device in Microsoft Entra ID, the extension fails.

To resolve and prevent this:

1. Check for an existing device with the same name
   • In Microsoft Entra ID, look under Devices and search for a device whose display name matches the hostname being used (for example, ACF-ITAMS-STAGE).
   • If this is a stale or unused entry, delete that device object.
2. Avoid hostname duplication
   • If another active device legitimately uses that hostname, change the VM’s hostname so it is unique before (re)deploying the AADLoginForWindows extension.
   • The documentation explicitly recommends avoiding duplication by modifying the hostname when this error occurs.
3. Redeploy the extension
   • After ensuring the hostname is unique (or the old device object is removed), redeploy the AADLoginForWindows extension and then run dsregcmd /status again. The goal is to see AzureAdJoined : YES.

Regarding naming conventions: they can still be used, but each VM’s effective Windows hostname must be unique within the tenant. If the convention causes truncation or reuse of the same prefix (for example, ACF-ITAMS-STAGE), adjust the pattern or ensure that no two devices end up with the same final hostname.

---

References:

• Sign in to Windows virtual machine in Azure using Microsoft Entra ID and Azure Roles Based Access Control