Configuring Microsoft Entra hybrid join: SCP, targeted deployment and validation

Microsoft Entra hybrid join gives domain-joined Windows devices an identity in Microsoft Entra ID, which unlocks device-based Conditional Access and PRT-based single sign-on. Turning it on for a whole forest takes one wizard page, which is exactly why it deserves a pilot first. In this post I'll configure hybrid join for a managed domain, pilot it with a targeted registry-based deployment, switch to the forest-wide service connection point (SCP) and validate the result.

How it works#

In a managed domain (password hash sync or pass-through authentication), registration is a relay between the device, Active Directory and Entra Connect:

1. The device reads the SCP, from its registry or from the AD configuration partition, to learn your tenant ID and name.
2. The Automatic-Device-Join scheduled task (under \Microsoft\Windows\Workplace Join) runs at user sign-in, creates a self-signed certificate and writes it to the computer object's userCertificate attribute.
3. Entra Connect Sync exports the computer object to Microsoft Entra ID, where it shows as hybrid joined with a registered state of Pending.
4. On the next attempt the device proves it holds that certificate, completes registration and, at the next user sign-in, receives a Primary Refresh Token.

So hybrid join depends on four things: a correct SCP, computer objects in sync scope, network access in system context, and at least one sync cycle of patience.

Prerequisites#

• Microsoft Entra Connect Sync with the default device attributes left in sync. The device options page needs version 1.1.819.0 or later; run a current build.
• A Hybrid Identity Administrator account, plus Enterprise Admin credentials for each forest where Connect will write the SCP.
• Device settings that let users register devices with Microsoft Entra ID; Microsoft lists this as a prerequisite.
• Domain-joined devices on Windows 10 version 1607 or later; current Windows 11 builds are the sensible baseline.
• Access in system context to https://enterpriseregistration.windows.net, https://login.microsoftonline.com and https://device.login.microsoftonline.com, plus https://autologon.microsoftazuread-sso.com if you use Seamless SSO. Registration runs as SYSTEM, so any proxy must be found through WPAD or a WinHTTP setting, with proxy authentication working in machine context.

Device writeback is a separate option in the same wizard and isn't needed for hybrid join.

Step 1: Put the computers in sync scope#

In the Entra Connect wizard, choose Customize synchronization options and, on Domain and OU filtering, tick the OUs that hold your pilot computers. Skip this and pilot devices publish their certificate but never appear in Microsoft Entra ID.

Step 2: Pilot with a client-side SCP#

A targeted deployment writes the SCP into the registry of selected computers instead of Active Directory, so only those computers try to join.

1. Check whether a forest-wide SCP already exists (first command below). If it does and you want a pilot, open ADSI Edit as an Enterprise Admin, connect to the Configuration naming context, browse to Services › Device Registration Configuration and remove the azureADId and azureADName values from the SCP object's keywords attribute.
2. Create a GPO such as ClientSideSCP. Under Computer Configuration › Preferences › Windows Settings › Registry, add two registry items with the action Update in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD:
   • TenantId (REG_SZ): the tenant ID shown under Entra ID › Overview › Properties.
   • TenantName (REG_SZ): in a managed environment, a verified domain or your contoso.onmicrosoft.com name; with AD FS, your verified federated domain.
3. Link the GPO to the pilot computer OU. If you still federate with AD FS, link it to the AD FS servers as well; otherwise AD FS treats on-premises as the source of authority for devices and starts deleting device objects after its MaximumInactiveDays period.

# Is there a forest-wide SCP? (an error or no output means no)
$configNC = (Get-ADRootDSE).configurationNamingContext
$scp = "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,$configNC"
(Get-ADObject -Identity $scp -Properties keywords).keywords

# On a pilot PC after gpupdate /force
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD

Step 3: Validate the pilot#

1. Restart a pilot PC or sign out and back in so the scheduled task runs, then confirm the computer object now has a certificate.
2. After the next sync cycle (30 minutes by default) the device appears in Microsoft Entra ID as Pending. The following sign-in or restart completes registration.
3. Run dsregcmd /status on the device.

# Did the device publish its certificate in AD?
Get-ADComputer PC01 -Properties userCertificate |
    Select-Object Name, @{n='Certs';e={$_.userCertificate.Count}}

# Has it reached Microsoft Entra ID, and how is it joined?
Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -Filter "displayName eq 'PC01'" |
    Select-Object DisplayName, TrustType, ApproximateLastSignInDateTime

A TrustType of ServerAd means hybrid joined (AzureAd is Microsoft Entra joined, Workplace is registered). In dsregcmd /status, good looks like this:

             AzureAdJoined : YES
              DomainJoined : YES
          DeviceAuthStatus : SUCCESS
                AzureAdPrt : YES

If the device isn't joined, the diagnostic section lists pre-join tests; a failed AD Configuration Test means the device couldn't read a valid SCP configuration. Details land in Applications and Services Logs › Microsoft › Windows › User Device Registration › Admin, and my dsregcmd troubleshooting guide maps the common errors.

Step 4: Configure the SCP forest-wide#

When the pilot is clean and every workstation OU is in sync scope:

1. Open Microsoft Entra Connect, select Configure, then Configure device options under Additional tasks.
2. Sign in as a Hybrid Identity Administrator and choose Configure Microsoft Entra hybrid join.
3. Select the device operating systems your domain-joined devices use.
4. On SCP configuration, select each forest, choose Microsoft Entra ID as the authentication service for a managed domain, select Add and enter Enterprise Admin credentials.
5. Select Configure, then rerun the SCP check: keywords should now hold an azureADName: value with a domain in your tenant and an azureADId: value with your tenant ID.

Step 5: Retire the pilot GPO#

A device that finds the SCP in its registry uses it and never reads Active Directory. Once the forest-wide SCP is in place, unlink the ClientSideSCP GPO and remove the CDJ\AAD values from pilot devices; items created with the Update action stay behind after the GPO is gone. That keeps your tenant pointer in one place.

Verify at scale#

Count hybrid joined devices by operating system version, and repeat over a few days as computers restart:

Get-MgDevice -All | Where-Object TrustType -eq "ServerAd" |
    Group-Object OperatingSystemVersion | Sort-Object Count -Descending |
    Select-Object Name, Count

In the Microsoft Entra admin center, filter All devices by join type Microsoft Entra hybrid joined: the Registered column should show dates, with Pending entries shrinking towards zero. Devices stuck in Pending or in dual state are covered in my clean-up guide.

Tips and gotchas#

• Widen OU sync scope before you publish the SCP, or devices keep retrying without ever completing.
• Make sure no Group Policy sets Register domain joined computers as devices (under Windows Components › Device Registration) to Disabled.
• Exclude https://device.login.microsoftonline.com from TLS break-and-inspect; interception breaks the device's certificate authentication.
• With AD FS, devices can register through the federation service straight away, with sync join as the fallback. If you're moving off AD FS, sync scope becomes the only path.

References#

• Configure Microsoft Entra hybrid join
• Microsoft Entra hybrid join targeted deployment
• Microsoft Entra Connect: Device options