dsregcmd /status, then correlate tenant ID, device ID, join state, user context, and timestamps with the exact Entra record. Treat the Intune managed-device and Autopilot registration as separate objects. Do not delete records until you know which relationship is broken.Understand the three join types
Microsoft Entra uses three primary device identity models. A registered device is commonly a personally owned or bring-your-own device where a work account has been added. An Entra joined device is joined directly to the cloud directory and is commonly organization owned. A hybrid joined device is joined to on-premises Active Directory and also represented in Entra ID.
| Join type | Typical trust | Question to ask first |
|---|---|---|
| Microsoft Entra registered | A work or school account is registered on the device | Is the user expecting full organizational join, or only account registration? |
| Microsoft Entra joined | Cloud directory is the device’s organizational join authority | Does the local tenant and device ID match the directory object? |
| Microsoft Entra hybrid joined | On-premises domain join plus cloud registration | Are domain connectivity, synchronization, service connection, and registration all healthy? |
These states are not interchangeable labels. A device can be correctly registered and still fail a requirement that expects it to be joined. Likewise, the presence of a directory record does not prove that the local device currently trusts or uses that object.
Capture local evidence first
On Windows, run dsregcmd /status in the user context relevant to the problem and preserve the output. The values you need depend on the scenario, but a useful baseline includes the join indicators, tenant name and ID, device ID, authentication state, user/workplace registration, and the diagnostic or error section when present.
- Record the computer name, signed-in user, time, and network context.
- Capture whether
AzureAdJoined,DomainJoined, and workplace/user state match the intended design. - Copy the tenant ID and device ID exactly; do not rely on the display name.
- Note whether the user ran the command elevated, because some user-state details depend on context.
- Preserve any error phase, client error, server error, and correlation information before retrying.
A screenshot is better than memory, but searchable text is better than a screenshot. Remove access tokens or secrets if any surrounding diagnostic package contains them.
Correlate the exact directory object
In the Entra admin center, search by the device ID from local evidence when possible. Display names are routinely reused after reimaging, replacement, or naming-policy application. Compare join type, enabled state, registration or activity dates, owner information, and management indicators.
A pending hybrid joined record deserves different investigation from a disabled cloud-joined object. A recently registered personal record beside an older joined corporate record may be expected. A stale duplicate with no matching local device ID is a candidate for lifecycle review, but age alone is not sufficient authority to delete it.
Keep adjacent systems separate
For the same physical machine, administrators may encounter several identifiers:
- Entra device object ID and device ID: directory identity and trust.
- Intune managed-device ID: the management service’s record and check-in state.
- Windows Autopilot registration: deployment registration built from the hardware identity.
- Local hardware identifiers: serial number, manufacturer, and other inventory facts.
They are related, not identical. Deleting the Intune record does not necessarily remove the Entra identity or Autopilot registration. Before cleanup, make a small correlation table with each system, its identifier, its observed status, and the time it was checked.
Use a decision path
- State the intended identity model: registered, joined, or hybrid joined.
- Capture current local join evidence and exact identifiers.
- Find the matching Entra object by identifier and compare tenant and join type.
- Inspect the related Intune record only if management or enrollment is part of the symptom.
- Inspect Autopilot registration only if deployment, profile assignment, or ownership is involved.
- Classify the mismatch: wrong tenant, wrong join type, pending registration, stale record, disabled object, enrollment failure, or a display-name duplicate.
- Choose the least destructive correction and preserve the before-and-after identifiers.
If the device is production critical, avoid broad “leave and rejoin” instructions until recovery access, local administrative access, BitLocker recovery, application impact, and policy reapplication have been considered.