Troubleshooting Domain Join & Windows Identity: A dsregcmd Guide

Leaving and rejoining a Windows computer to an Active Directory (AD) domain is a common troubleshooting step, but in modern hybrid environments, it’s a process filled with pitfalls. A single computer often has multiple identities—in local AD, in DNS, and in Azure AD (Entra ID). When these get out of sync, it leads to “ghost” identities, connection issues, and even being locked out of the machine entirely.

This guide provides a definitive workflow for diagnosing these identity conflicts using the essential dsregcmd tool, cleaning up stale records, safely rejoining a domain, and recovering if you get locked out.

Part 1: Decoding Device Identity with dsregcmd

dsregcmd (Device State Registration Command) is your primary tool for troubleshooting device identity. Running dsregcmd /status shows you exactly how Windows sees its connection to AD and Azure AD.

Understanding the “Device State”

The first section of the output is the most important:

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
| AzureAdJoined : NO                                                   |
| EnterpriseJoined : NO                                                |
| DomainJoined : NO                                                    |
+----------------------------------------------------------------------+

• DomainJoined : YES: The computer is joined to a traditional on-premises AD. This is the first requirement for a Hybrid Join.
• AzureAdJoined : YES: The computer is either directly joined to Azure AD (a cloud-only machine) or is Hybrid Joined (meaning DomainJoined is also YES).
• The “All NO” State: When all three values are NO, the computer is in a standard workgroup. It has no active domain identity. This is the expected state after successfully leaving a domain but before rejoining one.

Part 2: The Ghost Identity Problem & The Clean Rejoin Workflow

The most common failure scenario is when you leave a domain, but “ghost” records remain in DNS and Azure AD. This creates a conflict when you try to rejoin. To avoid this, you must follow a strict cleanup and rejoin process.

Step 1: Enable the Local Administrator (CRUCIAL SAFETY STEP)

Before you do anything else, ensure you have a “backdoor” into the machine. If the domain leave process fails, this will save you from being locked out.

Run these commands in an elevated PowerShell prompt:

# Activate the built-in Administrator account
net user Administrator /active:yes
# Set a strong, temporary password you won't forget
net user Administrator "YourStrongPassword123!"
# Crucially, log out and test that you can log in as '.\Administrator' BEFORE proceeding.

Step 2: Leave the Cloud and On-Prem Domains

If the machine is Hybrid Joined, you must sever the cloud link first.

1. Leave Azure AD:

   dsregcmd /leave

2. Leave On-Prem Domain:

   # This will prompt for credentials with rights to unjoin the machine
   Remove-Computer -UnjoinDomain -Credential (Get-Credential) -Restart

Step 3: Bust the Ghosts (Cleanup Stale Records)

While the machine is rebooting, immediately go to your management servers and delete the old computer object from:

• Active Directory Users & Computers: Find and delete the computer object.
• DNS Manager: Find and delete the A (forward) and PTR (reverse) records for the old hostname.
• Azure AD / Entra ID Portal: Find and delete the stale device object.

This cleanup is the most important step to prevent future conflicts.

Step 4: Rename and Rejoin

Once the machine has restarted, log in as the local .\Administrator account you enabled earlier. Renaming the computer is the best way to avoid any lingering cache issues.

# Rename the computer to something new
Rename-Computer -NewName "Workstation-New" -Restart

Add-Computer -DomainName "mydomain.com" -Credential (Get-Credential) -Restart

Part 3: Emergency Recovery from Lockout

What if you didn’t enable the local admin and are now locked out? The login screen might only show a failing Entra ID prompt with no “Switch User” option. Here’s how to break back in.

The Utilman / Command Prompt Trick

1. Boot into Advanced Startup: At the login screen, hold the Shift key and click the on-screen Power button -> Restart.
2. Navigate to Command Prompt: Go to Troubleshoot -> Advanced options -> Command Prompt.
3. Find Your Windows Drive: In the recovery environment, your C:\ drive might be D:\ or E:\. Use dir D:\ to find your Windows installation.
4. Enable Administrator: Once you find the correct drive, run these commands:

   D:
   cd \Windows\System32
   move utilman.exe utilman.exe.bak
   copy cmd.exe utilman.exe

5. Reboot: Close the command prompt and restart the computer.
6. Open a System-Level CMD: At the login screen, click the Accessibility icon (the little person icon). Because you replaced utilman.exe, a SYSTEM-level command prompt will open.
7. Activate the Admin Account: In this new command prompt, run:

   net user Administrator /active:yes
   net user Administrator NewPassword123!

8. Reboot and Clean Up: Reboot the machine. You should now see the local Administrator account as a login option. Once you have successfully logged in and recovered your machine, you must reverse this change for security. Boot back into the Advanced Startup command prompt one more time and run the following commands (assuming D: is your Windows drive):

   D:
   cd \Windows\System32
   del utilman.exe
   move utilman.exe.bak utilman.exe

   After a final reboot, your system will be back to normal, but you will have regained access.

Conclusion

A computer’s identity in a hybrid environment is complex. Simply leaving a domain is not enough. By following a clean workflow—Enable Admin -> Leave -> Cleanup Ghosts -> Rename -> Rejoin—you can avoid most identity conflicts. And by knowing the dsregcmd command and the Utilman recovery trick, you have the tools to diagnose the state and recover from almost any lockout scenario.