Fixing Hybrid Join Sync Failures: Domain-Joined PCs Not Appearing in Microsoft Entra ID

Domain-joined PCs sat in a synced OU but never appeared in Microsoft Entra ID, because their AD computer objects had no userCertificate value. Microsoft Entra Connect only syncs a computer as a device after the PC registers itself and writes that certificate to its own AD object. The PCs could not finish that step, so nothing reached Entra. Once the failing PCs could reach a domain controller, were re-joined to the domain, and had the Automatic-Device-Join task run, the certificate was written and the devices synced.

The OU scope, the sync rules and the SCP can all be correct, and devices still won't sync. Check the device first.

Environment and symptoms

The goal was to onboard devices to Intune using Microsoft Entra hybrid join, with Entra Connect syncing AD-joined PCs by OU and a GPO applied to that OU.

How hybrid join and device sync work

Moving a PC into a synced OU only puts it in sync scope and lets the OU's GPOs apply. It does not register the device. Registration is done by the device itself, and the order matters:

1. The PC is joined to the AD domain.

2. At logon or startup, the built-in Automatic-Device-Join task runs as SYSTEM. It finds the Service Connection Point (SCP) in AD, which holds the tenant name and ID.

3. The PC creates a certificate and writes it to the userCertificate attribute of its own AD computer object. This needs a working connection to a domain controller.

4. Entra Connect sees the certificate and syncs the computer to Entra as a device in the Pending state.

5. The PC completes registration with Entra, and the state becomes Registered. dsregcmd /status then shows AzureAdJoined : YES.

6. The MDM auto-enrollment GPO enrolls the device in Intune. This only applies after step 5.

An empty userCertificate is not shown as a blank row in AD or in the Entra Connect connector space. The attribute is simply absent. Seeing no userCertificate on a computer means that PC never completed step 3.

Troubleshooting steps and findings

The checks ran from the Entra Connect server first, then moved to the device. Each row rules something out or points at the cause.

Root cause

The failing PCs never wrote userCertificate to their AD computer objects, so Entra Connect had no registered device to sync. Entra Connect, the OU filter and the SCP were all healthy.

The registration step failed at the AD pre-check because the PC could not find a domain controller.

Resolution

Re-joining the domain and running the registration task fixed it. Do the steps in this order on each failing PC.

1. Put the PC on a network that reaches a domain controller. Use the wired corporate LAN, the corporate Wi-Fi, or a VPN that pushes internal DNS. Not guest or quarantine networks.

2. Confirm the PC can find the domain. nltest /dsgetdc:<domain> must return a domain controller, and nslookup <domain> must resolve.

3. Re-join the domain (or repair the secure channel with Test-ComputerSecureChannel -Repair -Credential <domain admin>) so the machine account trusts the PC again. Restart.

4. Run the registration task:

Start-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join"

5. Check that the certificate is now in AD:

Get-ADComputer <PC name> -Properties userCertificate | Select Name, @{n="CertCount";e={@($_.userCertificate).Count}}

CertCount of 1 or more means registration worked.

6. Sync, then verify. On the Entra Connect server run Start-ADSyncSyncCycle -PolicyType Delta. The device appears in Entra as Pending, then Registered after the next run of the task or the next sign-in.

If the task returns 0x801C03F3 (device object not found in Entra), the certificate is in AD but Entra has no matching device yet. Sync, wait a few minutes, and run the task again. If it persists, delete any stale entry for that PC in Entra and run dsregcmd /leave, restart, and retry.

Prevention and rollout checklist

Hybrid join depends on each PC reaching a domain controller at the moment the registration task runs. Plan the rollout around that.

• ☐ Confirm the SCP exists and shows the correct tenant before any rollout.

• ☐ Confirm no GPO sets "Register domain-joined computers as devices" to Disabled.

• ☐ Have each PC sign in once on the corporate LAN or VPN after it lands in the OU.

• ☐ Make sure the DHCP scope for every user VLAN hands out the domain DNS servers, not only a router.

• ☐ Check the VPN pushes internal DNS if laptops register remotely.

• ☐ A few minutes after first logon, check Get-ScheduledTaskInfo for the task. LastTaskResult : 0 means success.

• ☐ Check userCertificate in AD for the new PCs before expecting them in Entra.

• ☐ Only then expect the MDM auto-enrollment GPO and Intune enrollment to work.

Quick reference