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.
Check | Where | Result | Meaning |
Search Connector Space on the AD connector, by the OU's full DN (Sub-Tree) | Synchronization Service Manager | Both computers listed, Connector = True | The OU is in sync scope. Entra Connect imports both PCs. |
Compare the two computer objects' attributes | Connector space > Properties | Working PC had userCertificate. Failing PC did not. | The only difference. Points at device registration. |
Check the SCP | Get-ADObject on the Device Registration Configuration container
| azureADName and azureADId matched the tenant
| The SCP is correct. Re-running the Entra Connect device configuration would change nothing. |
dsregcmd /status on the failing PC
| Device | DomainJoined : YES, AzureAdJoined : NO, Diagnostic Data: AD Connectivity Test: FAIL at the pre-check phase
| Registration stopped before it reached Entra. |
User Device Registration > Admin log | Event Viewer | Event 220: unable to retrieve the computer's name in NameFullyQualifiedDN. The domain could not be contacted. | The PC could not talk to a domain controller. |
Task Scheduler > Workplace Join | Device | Automatic-Device-Join was Ready but failed. After a manual run it returned 0x801C03F3. | The task is healthy. It failed on the environment. A manual run later reached Entra, which had no matching device object yet. |
nltest /dsgetdc, nltest /sc_verify, Test-ComputerSecureChannel
| Device | ERROR_NO_SUCH_DOMAIN (1355), ERROR_NO_LOGON_SERVERS (1311), secure channel broken
| The PC could not locate any domain controller. |
ipconfig /all, nslookup
| Device | On Wi-Fi only. The only DNS server was the Wi-Fi gateway. The domain and its SRV records did not resolve. | The PC was on a network whose DNS did not know the AD domain. |
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
Item | Command or value | What it tells you |
Registration state | dsregcmd /status
| DomainJoined, AzureAdJoined, Diagnostic Data tests
|
Find a domain controller | nltest /dsgetdc:<domain>
| Fails with 1355 if the domain can't be located |
Secure channel | Test-ComputerSecureChannel -Verbose
| False means the machine account trust is broken |
Task result | Get-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join" | Get-ScheduledTaskInfo
| LastTaskResult : 0 is success
|
Certificate in AD | Get-ADComputer <name> -Properties userCertificate
| CertCount of 0 means the PC never registered
|
Registration log | Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin | Event 220 means the domain could not be contacted |
Force a sync | Start-ADSyncSyncCycle -PolicyType Delta
| Run on the Entra Connect server |
0x801C001D
| Task result code | Registration failure at an early phase. Read the event log for the cause. |
0x801C03F3
| Task result code | Entra has no device object matching this PC (error_missing_device). Sync, wait, retry. |
Join the conversation! Your thoughts help the community grow.