Check Entra ID Join Status with PowerShell (All States) · CloudEngineerHub
Detection & Remediation8 min read4 views
Detecting the Entra ID Join Status of Any Device with PowerShell
One PowerShell script that parses dsregcmd /status into a clean join-state taxonomy: Entra joined, hybrid joined, Entra registered, or not joined, with exit codes.
C
CloudEngineerHub Team
Published: September 8, 2026· Last Updated: September 28, 2026·8 min read
Ask three administrators what "Entra registered" means and you will get three different answers, usually involving some hand-waving toward BYOD. That ambiguity has real consequences: a device that is Entra registered but not joined is not device-managed by Intune, does not satisfy device-scope conditional access the way a joined device does, and frequently turns up in audits as an unexplained gap. The good news is that every Windows device carries an exact, self-reported answer in dsregcmd /status, and the answer fits a clean four-state taxonomy. This article provides a read-only PowerShell script that parses that output and classifies the device as Entra joined, hybrid joined, Entra registered, or not joined, then exits with a code that maps directly onto Intune remediation reporting. Along the way it explains what each state actually means for management and for conditional access, so the next time someone pastes a dsregcmd screenshot into a ticket, you can classify it in five seconds.
Visual Walkthrough
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Exit 1 flips the device into the remediation queue for this package.
remediate
3
Remediation executes
Fix script runs silently as SYSTEM with a 5-minute budget.
verify
4
Re-run detection
The same detection script must now exit 0 — proof, not hope.
telemetry
5
Results report
Per-device outcome lands in Reports → Remediations for trend analysis.
6
Repeat on schedule
The loop continues — drift gets caught the day it appears.
Continuous cycle
Proactive Remediations — The Detect → Fix → Verify Loop. 1. Detection script runs: Scheduled (daily/hourly): exit 0 healthy, exit 1 unhealthy — nothing more. — 2. Verdict: unhealthy: Exit 1 flips the device into the remediation queue for this package. — 3. Remediation executes: Fix script runs silently as SYSTEM with a 5-minute budget. — 4. Re-run detection: The same detection script must now exit 0 — proof, not hope. — 5. Results report: Per-device outcome lands in Reports → Remediations for trend analysis. — 6. Repeat on schedule: The loop continues — drift gets caught the day it appears.
Symptoms
Join-state confusion rarely announces itself as a join problem. It looks more like this:
Conditional access treats two seemingly identical devices differently, and the difference turns out to be registered versus joined.
Intune enrollment succeeds for some users but the device never shows up as corporate for others.
Audits list machines that are in Entra but not in Intune, or in neither, with no one able to explain which state they are in.
Users on personal machines hit "your device is not registered" prompts during SSO while their corporate devices sail through.
Support tickets that say only "the device is in Entra somehow", with nobody able to say whether it is joined, hybrid, or registered.
Possible Causes
User-driven workplace join on a personal or unmanaged device
When a user adds a work account to a device that is not managed, Windows performs a user-level registration. dsregcmd shows EnterpriseJoined YES with AzureAdJoined NO. This is the Entra registered state, and it is expected behavior for BYOD.
Entra join during OOBE or Settings
Corporate devices provisioned through Autopilot or joined manually from Settings get a device-level identity: AzureAdJoined YES, DomainJoined NO. That is Entra joined.
Domain join followed by Entra registration
Traditional AD devices that completed hybrid join show AzureAdJoined YES plus DomainJoined YES. Devices that are domain joined but never completed the Entra half show DomainJoined YES alone, which is a common hybrid rollout gap.
Mixed states from imaging or cloning
Devices captured from a source that already had identities can present contradictory or partial state, which is exactly why the script treats unclassifiable combinations as their own outcome instead of forcing a guess.
Detection Script
The script is read-only, runs in 64-bit SYSTEM context, and completes in a couple of seconds. It executes dsregcmd /status once, parses every key:value line into a field map, and classifies the device from three flags: AzureAdJoined, EnterpriseJoined, and DomainJoined. It also logs DeviceId, TenantId, TenantName, and AzureAdPrt for correlation with Intune and conditional access decisions.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
#Requires -RunAsAdministrator
[CmdletBinding()]
param()
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Detection script: classifies the device's Entra ID join state from
dsregcmd /status into the standard taxonomy.
.DESCRIPTION
Read-only. Classifies:
HybridEntraJoined - AzureAdJoined YES + DomainJoined YES
EntraJoined - AzureAdJoined YES + DomainJoined NO
EntraRegistered - EnterpriseJoined YES (user-level workplace join)
NotJoined - none of the flags set
Also reports DeviceId, TenantId, TenantName, and the AzureAdPrt flag.
AzureAdPrt is user state: when this script runs as SYSTEM with no
signed-on user it typically reports NO, which is expected and not a fault.
Exit 0 = Entra joined or hybrid joined (device-manageable states).
Exit 1 = Entra registered only (no device-level join; normal for BYOD but
a finding on corporate fleet devices).
Exit 2 = not joined to any directory, or the state could not be classified.
Exit 3 = unexpected error.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'EntraJoinStatusDetection.log'function Write-DetectionLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
function Get-DsRegStatusFieldMap {
# Runs dsregcmd /status and returns its key:value lines as a hashtable. # Spaces in field names are stripped so field naming differences across # Windows builds resolve to the same key.$map = @{}
$output = & "$env:SystemRoot\System32\dsregcmd.exe" /status 2>$nullforeach ($linein$output) {
if ($line -match'^\s*([A-Za-z][A-Za-z0-9 ]*?)\s*:\s*(.*?)\s*$') {
$map[($Matches[1] -replace'\s', '')] = $Matches[2]
}
}
return$map
}
try {
Write-DetectionLog 'INFO''Entra join status detection started.'$dsreg = Get-DsRegStatusFieldMap
$azureAdJoined = $dsreg['AzureAdJoined']
$enterpriseJoined = $dsreg['EnterpriseJoined']
$domainJoined = $dsreg['DomainJoined']
$deviceId = $dsreg['DeviceId']
$tenantId = $dsreg['TenantId']
$tenantName = $dsreg['TenantName']
$prt = $dsreg['AzureAdPrt']
Write-DetectionLog 'INFO'"dsregcmd: AzureAdJoined=$azureAdJoined EnterpriseJoined=$enterpriseJoined DomainJoined=$domainJoined"
Write-DetectionLog 'INFO'"dsregcmd: DeviceId=$deviceId TenantId=$tenantId TenantName=$tenantName AzureAdPrt=$prt" # ---- Classify the join state ----$state = 'Unclassified'if ($azureAdJoined -eq'YES' -and$domainJoined -eq'YES') {
$state = 'HybridEntraJoined'
}
elseif ($azureAdJoined -eq'YES') {
$state = 'EntraJoined'
}
elseif ($enterpriseJoined -eq'YES') {
$state = 'EntraRegistered'
}
elseif ($azureAdJoined -eq'NO' -and$enterpriseJoined -eq'NO' -and$domainJoined -eq'NO') {
$state = 'NotJoined'
}
if ([string]::IsNullOrWhiteSpace($prt)) {
Write-DetectionLog 'INFO''AzureAdPrt not reported in this session - expected when running as SYSTEM with no signed-on user.'
}
else {
Write-DetectionLog 'INFO'"AzureAdPrt=$prt - must be YES for signed-in-user SSO and Conditional Access user flows."
}
# ---- Exit by classification ----switch ($state) {
'EntraJoined' {
Write-DetectionLog 'INFO'"Join state: Entra joined. DeviceId=$deviceId is device-manageable by Intune."
exit 0
}
'HybridEntraJoined' {
Write-DetectionLog 'INFO'"Join state: hybrid Entra joined. DeviceId=$deviceId is device-manageable by Intune."
exit 0
}
'EntraRegistered' {
Write-DetectionLog 'WARN''Join state: Entra registered only (EnterpriseJoined). The device has no device-level Entra join, so Intune device enrollment and device-scope Conditional Access do not apply the way they do for a joined device.'
exit 1
}
'NotJoined' {
Write-DetectionLog 'WARN''Join state: not joined to Entra ID or an AD domain.'
exit 2
}
default {
Write-DetectionLog 'WARN'"Join state could not be classified (AzureAdJoined=$azureAdJoined EnterpriseJoined=$enterpriseJoined DomainJoined=$domainJoined)."
exit 2
}
}
}
catch {
Write-DetectionLog 'ERROR'"Unexpected failure: $($_.Exception.Message)"
exit 3
}
finally {
Write-DetectionLog 'INFO''Entra join status detection finished.'
}
Detection Logic
Field parsing. The script runs dsregcmd /status and captures every field : value line into a hashtable, normalizing field names so build-to-build differences do not break the parse. Missing fields read as empty rather than erroring, which keeps the classification honest.
The taxonomy. Hybrid Entra joined means AzureAdJoined YES and DomainJoined YES. Entra joined means AzureAdJoined YES with DomainJoined NO. Entra registered means AzureAdJoined NO and EnterpriseJoined YES, because registration is a user-level workplace join recorded in the EnterpriseJoined flag. No flags set means the device belongs to no directory, and any other combination is reported as unclassifiable with exit 2 rather than guessed.
Identity correlation. DeviceId, TenantId, and TenantName are logged whenever present. DeviceId is the value you match against the Entra device object and Intune device records; TenantName can be absent in SYSTEM sessions with no signed-on user, so the script logs it informationally.
PRT context. AzureAdPrt is user state, not device state. When Intune runs the script as SYSTEM with nobody signed in, it typically reports NO, and the script says so explicitly in the log instead of treating it as a fault. When you run it interactively, YES is what you want for SSO and conditional access user flows.
Exit mapping. Joined and hybrid devices exit 0 because both states support Intune device management. Registered-only devices exit 1: normal for BYOD, but on a corporate fleet group it is a finding. Not joined and unclassifiable devices exit 2 as prerequisite or unknown states.
Remediation Script
Detection-only, and deliberately so. The join state is a fact about the device, not a fault to be repaired by a script, and the remedies differ completely by intended state: Autopilot or manual Entra join for corporate devices, hybrid join repair for domain-joined machines, MDM user enrollment for BYOD scenarios. Choosing between those is a design decision that belongs to you, not to a script running as SYSTEM. What this package gives you is an accurate, timestamped, per-device record of the starting point.
Deploying Through Intune
Open the Microsoft Intune admin center, go to Devices → Scripts and remediations, and select + Add on the Windows 10/11 platform tab.
Name the package Detect - Entra join status and describe it as a read-only classification script.
On the Detection script tab, upload detect.ps1. Set Run script in 64-bit PowerShell: Yes and Run this script using signed-on credentials: No so it runs as SYSTEM.
Leave Enforce script signature check: No unless your organization signs internal scripts.
On the Remediation script tab, select No remediation script.
Set Frequency to Weekly. Join state changes are rare on stable fleets; weekly captures migrations and new builds without noise.
On Assignments, target all Windows devices if you want a full taxonomy, or just corporate groups if registered-only BYOD devices would pollute the results. Filters can exclude devices you know are intentionally registered.
Review and create.
Post-specific notes:
Run without signed-on credentials so the result is machine-scoped and repeatable; the PRT line in the log explains why its value can be NO in that context.
Treat exit 1 on corporate groups as the actionable signal: it finds devices where someone completed a user-driven registration instead of proper enrollment.
Pair the results with the compliance status view in Intune to spot joined-but-never-enrolled devices.
Visual Walkthrough
dsregcmd states decoded: what each join type grants and expects.
Side-by-SideEntra Joined vs Registered — Know Your Device State6/6
Entra Joined
corporate
Entra Registered
BYOD
Fully managed by Intune (MDM)
MAM-managed or lightly managed
Full PRT with SSO to all cloud apps
SSO token for registered apps
Kerberos/Cloud proxy support
No local admin or Kerberos flow
Ideal for cloud-only fleets
Personal device, work account
Auto-enrolls into MDM
MDM optional, often user-enrolled
Entra Joined vs Registered — Know Your Device State. Entra Joined vs Entra Registered. Entra Joined: Fully managed by Intune (MDM) · Entra Registered: MAM-managed or lightly managed — Entra Joined: Full PRT with SSO to all cloud apps · Entra Registered: SSO token for registered apps — Entra Joined: Kerberos/Cloud proxy support · Entra Registered: No local admin or Kerberos flow — Entra Joined: Ideal for cloud-only fleets · Entra Registered: Personal device, work account — Entra Joined: Auto-enrolls into MDM · Entra Registered: MDM optional, often user-enrolled
Exit Codes
Intune treats any non-zero detection exit as remediation needed. The mapping here is a classification, so read the table with your intended device state in mind:
Code
Meaning
0
Entra joined or hybrid joined, both of which support Intune device management
1
Entra registered only: user-level workplace join without a device-level Entra join
2
Not joined to any directory, or the state could not be classified from dsregcmd output
3
Unexpected script error - inspect the log
Logging
The script appends to C:\ProgramData\Company\Logs\EntraJoinStatusDetection.log. Each line has a UTC timestamp, a level, and a message; the first two INFO lines every run record the raw dsregcmd flags and the correlation fields (DeviceId, TenantId, TenantName, AzureAdPrt), and a final line states the classification and exit path. Two or three lines per run means negligible growth; rotate on whatever cadence your log management already uses. To go deeper on a specific device, run dsregcmd /status interactively and compare the full output against the parsed values in the log.
Troubleshooting the Script
Exit 3 on specific devices. Confirm 64-bit PowerShell and SYSTEM context; also verify C:\Windows\System32\dsregcmd.exe exists and is not blocked by application control.
Everything exits 2. If dsregcmd output cannot be parsed, look for non-English output locales or unusual shell environments on those devices; run manually to inspect raw output.
TenantName is empty in Intune runs. Expected: the user section of dsregcmd output is sparse without a signed-on user. Run interactively when you need that field.
Devices flap between exit 1 and 0. Someone is joining and unregistering devices, or re-imaging is in progress; the log timestamps will show the transitions.
PRT reported NO on devices where users are signed in. Remember the script ran as SYSTEM. Run dsregcmd /status in the user's session to evaluate their PRT.
How to Validate the Fix
Run the script manually on a known Entra joined device. Expect exit 0 and "Join state: Entra joined" in the log with a DeviceId.
Run it on a domain-joined hybrid machine. Expect exit 0 with the hybrid classification.
Run it on a personal device after adding a work account. Expect exit 1 with the Entra registered classification.
Run it on a fresh workgroup machine. Expect exit 2 with "not joined".
Deploy the package to a pilot group and confirm the Device status view matches your manual results device for device.
Production Considerations
Context. Runs as SYSTEM in 64-bit PowerShell; the #Requires directive enforces admin rights for manual execution. No user interaction is required or expected.
Idempotency. The script performs one dsregcmd call and writes only to its log. Nothing on the device changes, ever.
Side effects. None. No reboot, no services touched, no network calls beyond local process execution.
Security review. The log contains device and tenant identifiers but no tokens or user data. Validate the package in a test ring with your PowerShell automation SME and security team before broad production rollout, and align retention of the log with your device inventory policies.
Interpretation discipline. Exit 1 is a finding, not always a fault. Decide per device group whether registered-only is acceptable before you let the results drive automation.
Why is AzureAdPrt NO when I run this through Intune?
The script runs as SYSTEM, and the PRT belongs to a signed-in user, so there is none to report in that session. The log says so explicitly. Run dsregcmd /status in the user's own session when you need to evaluate their PRT for SSO or conditional access debugging.
Can a device be both hybrid joined and Entra registered?
Unusual but possible when a user performs a workplace join on a domain-joined machine. The script classifies by priority: AzureAdJoined YES wins, so the device reports as hybrid joined, and the log records the EnterpriseJoined value too so you can see the full picture.
Which state should corporate devices report?
Entra joined or hybrid joined. Registered-only on a corporate device usually means someone added a work account to an unmanaged machine, which is worth a follow-up: either the device should be enrolled properly or the registration should be removed. The script's exit 1 on corporate groups is designed to surface exactly those cases.
Comments
0No comments yet — be the first to share your thoughts.