Azure AD Device Registration Failure: SCP Discovery Error (0x801c001d) Causing M365 Sign-In Loop on RDS Host

Question

Azure AD Device Registration Failure: SCP Discovery Error (0x801c001d) Causing M365 Sign-In Loop on RDS Host

Chris Osborn 0

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.

Saravana Kumar D 170 Reputation points Microsoft External Staff Moderator

2026-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

Require device compliance with Conditional Access

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

Troubleshoot Microsoft Entra hybrid joined devices

Configure Microsoft Entra hybrid join

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.

2 answers

Your answer

Answer 1

Hello Chris,

Adding to Saravana´s Comment, in a Microsoft Entra Domain Services-only environment, hybrid join isn´t possible at all.

Answering your Questions:

Missing SCP, expected?
1. Yes. The SCP is only used for Microsoft Entra hybrid Join, and Hybrid Join requier the computer object to be synced from a On-Premises AD to Entra / azure via the Entra Connect. Microsoft says that installing the Entra Connect in a managed domain to sync back isn´t supported. So the SCP is absend by design here.
Create it Manually?
1. No, the device still couldn´t Hybrid Join, because the Computer Object never reaches Entra so the error would just come in a later phase again.
Related to the CA failure?
1. No. windows attempts the hybrid join automatically on every domain joined machine, so the error "0x801c001d" is a expected noise and can be ignored in your setup. The 53000 comes only from Require compliant device - a registered device only gets device-based Conditional Acccess when its enrolled in Intune the "AAD joined: Yes" from Windows Hello events are most likely reflects per-user work account registrations every user who adds a work account on the server creates their own registered deivce oject with the same name and multiplies the devices like this.

What i would do in your scenario is to treat the host a never-compliant and protect is differently what i mean by that:

Use the "Compliant OR MFA" pattern for the RDS Sessions: its a Microsoft Conditinal Access Template Require compliant or hybrid joined device or MFA for all users lets the RDS host pass with MFA while managed clients pass with compliance. Scope your strict "Requiere compliant device" policy so it doesn´t cover the RDS user/sessions (what i mean: by group, or by named location for the hosts outbound IP if its a fixed IP) keep in mind test the Policy first in Report only and with the "What if" tool.
- Optionall: Block registration on the Server so users can´t create new registered device onjects via "Add work or School account" the Registry Key can be found here:
```
    HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin --> BlockAADWorkplaceJoin with the Value 1 (DWORD)
```
  Existing registrations are per user profile and need to be discnnected under Settings - Accounts - Access work or school
- if device compliance is a hard requirement, the Micrsofot supported way is a Azure Virtual Desktop or Windows 365 with Entra Joined, intune managed hosts

Important: please check what your interim fix is currently using if it is using a Device filter it won´t apply to a unregistered device, so if you block and remove the registrations, the 53000 loop comes back - so Please set up the new scoping before you unregister the host.

References for you to read it:

Best regards Alex

Answer 2

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