Hybrid Autopilot has a dependency that classic Entra-join Autopilot does not: a Windows Server somewhere running the Intune Connector for Active Directory, quietly creating computer objects and handing back offline domain join blobs. When that connector is too old, it does not announce itself. Enrollments just start timing out during the domain join step, and the error you get points at the network rather than at the connector you have not patched since you installed it.
Intune Connector for Active Directory versions older than 6.2501.2000.5 are deprecated and can no longer process enrollment requests. Microsoft moved the connector from running as the local SYSTEM account to a Managed Service Account, and retired the old build. A device provisioning with a hybrid profile depends on that connector to receive its offline domain join (ODJ) blob - if it never arrives, provisioning fails with a domain join timeout rather than a version error. Check the installed version on the connector server, and confirm the client's profile is genuinely hybrid by reading CloudAssignedDomainJoinMethod.
The problem: an ODJ timeout that is not a network problem
The classic presentation is a hybrid Autopilot deployment that gets through Entra join and MDM enrollment, then stalls and fails at the domain join step. The device-side error is a timeout waiting for the ODJ blob or for connectivity - and because the message mentions connectivity, the investigation almost always starts with firewalls, VPN and DNS.
Those are legitimate causes. But if the connector itself is a deprecated build, the service is simply refusing its enrollment requests, and no amount of network troubleshooting on the client will surface that. The client is waiting for a blob that is never going to be generated.
Why it happens: the connector was retired, not just superseded
Microsoft changed how the connector authenticates. The original build ran as the local SYSTEM account; the replacement uses a Managed Service Account, which is a meaningful security improvement for a component whose whole job is creating computer objects in your directory. Rather than support both indefinitely, Microsoft set a hard floor: builds older than 6.2501.2000.5 are deprecated and can no longer process enrollment requests.
That is a service-side cutoff, which is why it is so easy to miss. The connector may still be installed, the service may still be running, and the server may look healthy - while every enrollment request it makes is rejected.
How to verify: check the connector, and the client profile
Two checks, on two different machines. On the connector server, get the installed version:
On the client, confirm the profile really is hybrid before you blame the connector at all - a cloud-only profile does not involve it:
1 before touching the server.The fix: upgrade the connector, then re-test
Context: the fix is a connector upgrade on the server. There is no client-side workaround, because the rejection happens service-side.
- Sign in to intune.microsoft.com.
- Go to Devices › Enrollment › Intune Connector for Active Directory and review the connectors listed and their last check-in.
- Download the current connector installer from that blade, and run it on the connector server to upgrade in place.
- Because the current build uses a Managed Service Account rather than SYSTEM, confirm the account it runs as has permission to create computer objects in the target organisational unit - re-check the OU delegation rather than assuming it carried over.
- Confirm the connector reports healthy and has checked in recently in that same blade.
- Re-run one hybrid Autopilot enrollment end to end before declaring it fixed. A connector that shows healthy has not yet proven it can complete a join.
The DC connectivity check, and why skipping it moves the failure
Hybrid profiles can skip the domain controller reachability check during OOBE. When set, the client does not verify it can reach a DC before proceeding - useful for devices provisioning off the corporate network, since the ODJ blob does not need DC line of sight at that moment.
The trade-off is diagnostic. With the check enabled, an unreachable DC fails early and obviously. With it skipped, provisioning proceeds and the problem surfaces later, as a join or post-join failure whose root cause is further from the symptom. Neither setting is wrong - but if you have skipped the check, factor that into how you read a later failure.
Registry reference
Client side, the relevant values live inside the cached Autopilot profile JSON:
| JSON field | Value | What it means |
|---|---|---|
CloudAssignedDomainJoinMethod | 1 | Microsoft Entra hybrid join - this device depends on the ODJ connector |
CloudAssignedDomainJoinMethod | 0 | Microsoft Entra join - cloud only, the connector is not involved |
HybridJoinSkipDCConnectivityCheck | 1 | The DC reachability check during OOBE was skipped - failures surface later rather than up front |
IsExplicitProfileAssignment | True | The profile was assigned directly rather than inherited via a dynamic group - useful when reconciling why a device got this profile |
PolicyDownloadDate | Timestamp | When this profile was cached. Edits made after this date are not on the device |
Server side, the connector's version is in the standard uninstall registry keys under DisplayName matching "Intune Connector for Active Directory", with the build in DisplayVersion.
Proof it worked: a real hybrid device, confirmed
A genuine run of Test-HybridAutopilotOdjReadiness.ps1 from this series against a real Autopilot-provisioned, Entra hybrid joined client. The script detects it is a client rather than the connector server and reports accordingly:
This is what a healthy, fully hybrid-joined Autopilot device looks like, corroborated three ways. The cached profile says the join method was hybrid. The profile also confirms the DC connectivity check was skipped, so this device provisioned without needing line of sight to a domain controller. And dsregcmd independently confirms the outcome actually happened - AzureAdJoined: YES together with DomainJoined: YES is the definition of Entra hybrid joined.
The value of checking all three is that they can disagree. A device whose profile says hybrid but whose dsregcmd shows DomainJoined: NO is precisely the failure this post is about - the intent was hybrid, the ODJ blob never arrived, and the connector is the first thing to check.
References
- Microsoft Learn - Enrollment for Microsoft Entra hybrid joined devices
- Microsoft Learn - Install the Intune Connector for Active Directory
- Microsoft Tech Community - Intune Connector for Active Directory security update - the Managed Service Account change and the deprecation of older builds
- Microsoft Learn - What's new in Windows Autopilot
Microsoft MVP community deep-dives
Verified and genuinely on-topic - each URL was fetched and confirmed before being cited here, not copied on trust:
| Author | Post | What it adds |
|---|---|---|
| Rudy Ooms (MVP, call4cloud.nl) | Step by Step: How Windows Retrieves the Autopilot Profile | Traces the full eight-step token-and-profile retrieval flow, and independently documents both the AutopilotPolicyCache registry key and the wmansvc on-disk cache this post relies on |
Script for this post is in Windows-Autopilot-Scripts.