Microsoft Security | Microsoft Entra | Microsoft Entra ID
A cloud-based identity and access management service for securing user authentication and resource access
Azure AD Device Registration Failure: SCP Discovery Error (0x801c001d) Causing M365 Sign-In Loop on RDS Host
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(185.6, 53%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECO%3C/text%3E%3C/svg%3E)
Chris Osborn
0
Reputation points
roblem
Users on a Windows RDS host are stuck in a continuous M365 sign-in loop — error 53000, device compliance issue. Sign-in log Conditional Access details show a "Require Compliant Device" policy is the cause: everything matches except device compliance, since the device is workplace-joined only and never MDM-enrolled. Separately, dsregcmd /status shows a device registration discovery failure (SCP discovery error 0x801c001d). Unsure if these two are related or independent.
Environment
Windows Server VM, RDS host, Azure Central US Stable for 3+ years, workplace-joined ("Registered") since 2022 Domain-joined to Microsoft Entra Domain Services (AADDS) — no Azure AD Connect / on-prem AD
What I've tried
dsregcmd /status (non-elevated + elevated/SYSTEM) — consistent both times:
AzureAdJoined: NO, AzureAdPrt: NO
AD Configuration Test: FAIL [0x80070002]
Error Phase: discover, Client ErrorCode: 0x801c001d
User Device Registration event log — Windows Hello for Business events say AAD joined: Yes, conflicting with dsregcmd's NO. Can't explain the discrepancy.
Queried the SCP object directly in the AADDS domain — object doesn't exist in the forest's configuration partition.
Ruled out: recent CA policy changes, DNS/connectivity to all relevant MS endpoints, reboot/patch history, time sync, RDS licensing.
Found the exact CA policy via sign-in logs. Its last modification predates this issue by ~12 weeks — can't confirm a causal link (audit retention doesn't go back that far).
Interim fix: excluded the affected device from the CA policy to restore access.
Took a VM disk snapshot before making changes.
Questions
Is a missing SCP object expected/normal in an AADDS-only environment (no AD Connect)? If it should exist — does Microsoft provision it, or do we configure it manually? Is manual creation safe in AADDS? Is the SCP failure related to/causing the CA compliance failure, or are they independent? What's the right long-term approach for an RDS host that's workplace-joined but never MDM-enrolled, since it can't natively satisfy "compliant device"?
Goal: Restore reliable device registration and M365 sign-in, and understand root cause well enough to prevent recurrence.
Microsoft Security | Microsoft Entra | Microsoft Entra ID
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(227.2, 4%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESK%3C/text%3E%3C/svg%3E)
Saravana Kumar D 170 Reputation points Microsoft External Staff Moderator2026-10-01T13:59:36.47+00:00 Hello @Chris Osborn
Greetings!
Based on the information shared, the sign-in issue appears to be related to a Conditional Access policy that requires the device to be marked as compliant.
The RDS host is currently Microsoft Entra registered (Workplace Joined), but it is not enrolled in Intune. Since device compliance status is provided through Intune, Microsoft Entra cannot validate the device as compliant, resulting in sign-in failures with error 53000. Microsoft documentation confirms that Conditional Access device compliance relies on Microsoft Intune compliance policies.
Relevant Microsoft Documentation
The additional 0x801c001d error observed in dsregcmd appears to be related to the device registration discovery process. According to Microsoft documentation, error 0x801c001d (DSREG_AUTOJOIN_ADCONFIG_READ_FAILED) indicates that Windows was unable to read the Service Connection Point (SCP) or retrieve Microsoft Entra tenant information required for Hybrid Join discovery.
The current dsregcmd output indicates that the server is domain joined but neither Microsoft Entra joined nor Microsoft Entra hybrid joined. In Hybrid Join scenarios, a properly configured SCP and Hybrid Join prerequisites are required.
Relevant Microsoft Documentation
Recommended Next Steps
- Review the Conditional Access policy identified in the sign-in logs and confirm whether this RDS scenario is expected to satisfy the compliant-device requirement.
- If Intune compliance is not applicable for this RDS workload, consider excluding the affected RDS users/devices from the compliant-device requirement and using an alternate control such as MFA.
- Confirm the intended device identity state for the server (Microsoft Entra Registered, Microsoft Entra Joined, or Microsoft Entra Hybrid Joined).
- If Hybrid Join is the intended configuration, validate the SCP configuration, synchronization prerequisites, and required network connectivity documented by Microsoft before making any directory changes.
At this stage, the SCP discovery error should be investigated as a separate device registration issue, while the immediate M365 sign-in failure appears to be caused by the device not meeting the Conditional Access compliant-device requirement.
Regards,
Saravana D.
Sign in to comment
1 answer
Sort by: Most helpful
-
Deleted
This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
1 deleted comment
Comments have been turned off. Learn more