The dsregcmd command-line tool is an indispensable utility for any administrator managing Windows devices in a modern, hybrid environment. It provides a wealth of information about a device’s identity and its join state with both on-premises Active Directory (AD) and cloud-based Azure AD (Entra ID).

However, the output can sometimes be confusing. A common scenario is running dsregcmd /status and seeing that AzureAdJoined, EnterpriseJoined, and DomainJoined are all set to NO. While this might look like an error, it simply means the computer is in a standalone workgroup state.

This guide will decode the dsregcmd /status output and explain what the “All NO” state means and how to troubleshoot common issues related to it.

What is dsregcmd?

dsregcmd (Device State Registration Command) is a command-line tool built into Windows that is used to view the device’s registration status with Azure AD. It is the primary tool for troubleshooting issues related to device identity, single sign-on (SSO), and conditional access.

Decoding the dsregcmd /status Output

When you run dsregcmd /status, the “Device State” section is the first thing you should look at. It tells you how the device is connected to your organization’s identity providers.

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

Here’s what each of these fields means:

  • AzureAdJoined: If YES, the device is directly joined to Azure AD. This is common for cloud-only devices.
  • EnterpriseJoined: This is a legacy state, often associated with “Workplace Join,” and is less common in modern environments.
  • DomainJoined: If YES, the device is joined to a traditional on-premises Active Directory domain. If the device is also registered in Azure AD, this indicates a Hybrid Azure AD Join.

The “All NO” State: What It Means

When all three of these values are NO, it means the computer is in a workgroup. It has no active connection to either an on-premises AD or a cloud-based Azure AD. It is a standalone machine that authenticates users against its local Security Account Manager (SAM) database (e.g., .\Administrator).

Common Issues in the “All NO” State

Even in a workgroup state, you might encounter some confusing behavior, especially after disjoining a machine from a domain.

  • Lingering Microsoft Account Prompts: The Windows login screen might still prompt for a Microsoft Account or work email. This is often due to cached credentials or policies that haven’t been fully removed.
  • Network Reachability: You might still be able to ping the machine’s old hostname or connect to it via RDP. This is because the DNS record for the machine may still exist on your DNS server, and the local firewall may still allow RDP traffic.

The Road Back: How to Properly Rejoin a Domain

If your goal is to rejoin the machine to a domain, it’s crucial to do it cleanly to avoid conflicts.

Step 1: Clean Up Any Lingering Cloud Identities

Even if dsregcmd /status shows all “NO”, it’s a good practice to run the /leave command to clear out any cached settings.

# Run in an elevated command prompt or PowerShell
dsregcmd /leave

Step 2: Rename the Computer

To prevent conflicts with stale DNS records and the old computer object in Active Directory, you should always rename the computer before rejoining it to the domain.

Rename-Computer -NewName "MyNewPCName" -Restart

⚠️ Important: After the computer restarts, you will no longer be able to connect to it using its old hostname. You will need to log in at the console or use its IP address for RDP.

Step 3: Rejoin the Domain

Once the computer has been renamed and restarted, you can cleanly join it to the domain.

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

After the final restart, you can run dsregcmd /status again. You should now see DomainJoined : YES, confirming that the process was successful.

Conclusion

The dsregcmd /status command is a powerful tool for understanding a device’s identity state. An output of all “NO” is not an error; it’s a confirmation that the machine is in a workgroup.

When troubleshooting identity issues, remember that a computer’s presence on the network (DNS) is separate from its identity (AD and Azure AD). By following a clean process of leaving, renaming, and rejoining, you can resolve most identity-related conflicts and ensure your devices are properly registered in your environment.