The Intune Connector Certificate Expires and Hybrid Autopilot Stops, With No Alert

Hybrid Windows Autopilot has one on-premises moving part, and it is a Windows service on a server that nobody looks at. That service is the Intune Connector for Active Directory. When it stops being able to talk to Intune, every hybrid Autopilot deployment stalls at the domain-join step, and nothing in the Intune admin center emails you to say so.

The problem: deployment day stops at domain join

You have twenty laptops on a bench. Every one of them reaches the Enrollment Status Page (ESP), sits at the device setup phase, and eventually fails. Nothing changed in your Autopilot profile. Nothing changed in your Domain Join profile. Last month the same build worked.

What changed is on a server. Hybrid Autopilot needs an on-premises component to create the computer account and hand the device an Offline Domain Join (ODJ) blob. Microsoft calls that component the Intune Connector for Active Directory, and also calls it the ODJ Connector. The documented job is narrow. It joins computers to an on-premises domain during the Windows Autopilot process, and it creates computer objects in a specified Organizational Unit (OU) in Active Directory during that domain join.

The connector is not a chatty component. It has no dashboard, no notification channel, and no built-in expiry warning. Its entire health surface in the portal is one page with a status column.

That page shows a Connector name, a Status and a Version. The documented healthy state is simple. The server appears, Status reads Active, and the version is at or above the supported floor. Anything else is a problem, and the page will not tell you which problem.

There is a second reason this failure mode is confusing. A supported, current, correctly installed connector can still stop working. The version floor is a separate issue that this site has covered already. What follows is the other case, where the connector is on a good build and has simply lost the ability to authenticate.

Why it happens: an undocumented credential lifecycle

Start with what Microsoft actually states. During installation you sign the connector in with an Entra ID account that holds an Intune administrator role. Then comes the sentence that matters most. The account used to enroll the connector is only a temporary requirement at the time of installation, and it is not used going forward after the server is enrolled.

Read that carefully. The connector keeps working after the human credential goes away. Something durable and machine-held must be doing the authenticating from that point on. In practice that is a client certificate issued to the server during enrollment, held in the local machine store, and presented on every outbound call to the service.

That different product is worth naming, because the confusion is constant. The Certificate Connector for Microsoft Intune is the SCEP and PKCS connector. It is not the ODJ connector. For that product Microsoft does document a client-certificate story, including automatic updates over port 443 to autoupdate.msappproxy.net, and the blunt statement that the process to manually update a certificate connector is the same as reinstalling one.

What actually breaks the renewal path

Whatever the renewal cadence is, renewal is an outbound call. Anything that blocks that call turns a silent background refresh into a silent background failure. Four causes are documented.

One, no outbound internet at all. The requirement is explicit. The server hosting the connector must have access to the internet and to Active Directory, and the connector requires the same endpoints as Intune itself.

Two, a proxy the connector does not know about. By default the connector tries Web Proxy Auto-Discovery (WPAD). Where WPAD is absent, you have to declare the proxy in the connector's own .NET configuration files. The Microsoft support article for a connector that installs but never appears in Intune points at exactly this, with a distinctive error in the ODJ Connector Service log: Failed to get a value for Key: OdjServiceBaseUrl.

Three, TLS interception. This one bites mature networks hardest, because break-and-inspect is usually a security requirement there. The Microsoft endpoint documentation is unambiguous. SSL traffic inspection is not supported for *.manage.microsoft.com, *.dm.microsoft.com, or the Device Health Attestation endpoints. The connector service configuration points at https://manage.microsoft.com/, so an inspecting proxy sits directly in its authentication path.

Four, a hardened SCHANNEL configuration. Microsoft documents a specific failure where the connector sign-in page will not load, showing either "Navigation to the webpage was canceled" or "Can't connect securely to this page." The documented cause is that the server is sending network requests over TLS 1.0 or 1.1 because PKCS cryptography is disabled.

Only the first key above is documented by Microsoft as a connector-specific cause. The ODJConnectorSvc keys are ordinary Windows service plumbing, shown here because they are the fastest way to read the connector logon account and binary path without opening a console. Microsoft does not document a registry-backed configuration surface for the connector itself. Its settings live in two .config files instead, which is why this post has no full registry reference table.

The service account changed, and the direction matters

One more thing to get right, because it is frequently stated backwards. The legacy connector ran under the server computer context, which is why the legacy guidance says the server running the connector needs permission to create computer accounts. The updated connector moved to a low-privileged Managed Service Account (MSA). The installer creates it, names it in the format msaODJ#####, and that MSA is what needs the Create Computer objects delegation on your target OU.

How to verify: six checks, five of them local

Verification order matters. Confirm the tenant view first, because it is fastest, then work down onto the server.

Check 1: the portal status page

1. Sign in to the Microsoft Intune admin center.
2. Select Devices in the left pane.
3. Under By platform, select Windows.
4. Under Device onboarding, select Enrollment.
5. Under Windows Autopilot, select Intune Connector for Active Directory.
6. Confirm the server appears under Connector name and shows Active under Status.
7. Confirm the version is greater than or equal to 6.2501.2000.5.

If the page is empty, do not assume the connector was never installed. Remember the 30-day cleanup.

Check 2: the connector event log

The connector logs to a nested channel, and that channel moved at some point, which trips people up. The Microsoft FAQ states it directly. The connector originally logged in Event Viewer directly under Applications and Services Logs in a log called ODJ Connector Service. Logging has since moved to Applications and Services Logs, then Microsoft, then Intune, then ODJConnectorService.

The event text above is illustrative. That matters, because Microsoft publishes no Event ID catalog for this connector. It does publish one for the Certificate Connector for Microsoft Intune, where connector health events occupy the 5000 to 5999 range. That is the other product, and reusing those IDs here would be wrong. For the ODJ connector, treat the channel as the reference rather than the ID.

Check 3: the service, the version and the certificate

Everything below is read-only. Run it elevated on the connector server.

Check 4: the outbound path, including inspection

If manage.microsoft.com presents a certificate issued by your own inspection appliance rather than a public certificate authority, stop and fix that first. Nothing else you do to the connector will hold.

Checks 5 and 6: the two config files, and the tenant record from Graph

The two files that hold connector configuration both live under the install root, normally C:\Program Files\Microsoft Intune\ODJConnector\. The service uses ODJConnectorSvc\ODJConnectorSvc.exe.config. The enrollment wizard uses ODJConnectorEnrollmentWizard\ODJConnectorEnrollmentWizard.exe.config, which is also where the OU allow-list key OrganizationalUnitsUsedForOfflineDomainJoin lives, and where ODJConnectorUI.log is written.

Finally, the piece that makes real monitoring possible. Microsoft Graph exposes the connector record, so you can poll it instead of visiting a page.

The fix: re-enroll, then close the renewal path

There is no documented renew button for this connector. Microsoft manual-update guidance for Intune connectors is to reinstall, so that is the shape of the fix. Do it in this order, because reinstalling into a broken network path just recreates the same failure with a fresher timestamp.

Step 1: fix the network path first

1. Confirm outbound 443 to the Intune core service endpoints, including manage.microsoft.com and *.manage.microsoft.com.
2. Exclude those hostnames from SSL inspection. This is a support requirement, not a preference.
3. If you use a proxy and WPAD is not available, declare the proxy in both .config files. The documented options are to bypass the proxy with a defaultProxy enabled="False" element, or to pin a specific proxy with a proxy proxyaddress element.
4. Copy the original .config files before editing them, then restart the connector service from services.msc.
5. If PKCS key exchange was explicitly disabled, remove that value. The documented command is reg.exe delete "HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS" /v Enabled /f from an elevated prompt.

Step 2: stand up a second connector before you touch the broken one

This is the step people skip, and it is the one that saves deployment day. Multiple connectors are supported, with documented constraints. One connector per server, one connector instance per domain, and if one connector fails the requests go to another connector on another server within the same domain.

Step 3: reinstall and re-enroll the connector

1. Sign in to the server as a local administrator, using a domain account that can create msDs-ManagedServiceAccount objects in the Managed Service Accounts container.
2. Uninstall the existing connector through the Settings app.
3. Run ODJConnectorBootstrapper.exe again and select Uninstall if prompted. Microsoft documents that Settings alone does not always fully remove it, and that the bootstrapper version must match the installed connector version.
4. Download a fresh ODJConnectorBootstrapper.exe from Intune Connector for Active Directory, then Add, in the admin center.
5. Install it, and tick Launch Intune Connector for Active Directory at the end.
6. On the Enrollment tab, select Sign In and authenticate with an Intune administrator account that holds an Intune license.
7. Note the MSA name from the confirmation dialog. It is in the format msaODJ#####.
8. Aim for version 6.2504.2001.8 or later. From that build the sign-in wizard uses WebView2, so Internet Explorer Enhanced Security Configuration no longer has to be turned off.

Step 4: re-grant the MSA its OU permission

A new install means a new MSA, and a new MSA has no delegation. By default an MSA can only create computer objects in the Computers container, and Active Directory caps any single account at ten domain joins without a delegation. Add the OUs to OrganizationalUnitsUsedForOfflineDomainJoin in the wizard config, then use Configure Managed Service Account. If the installing admin lacks OU rights, someone who has them must grant the MSA the Create Computer objects permission on the target OU through DSA.msc.

Step 5: confirm the domain still matches

The fully qualified domain name and OU in your Domain Join profile must live in the same domain as the connector. Microsoft documents error 0x80070774 during ESP as exactly this mismatch, where the connector is installed on one Active Directory domain but devices are configured for another. If you rebuilt the connector on a different server, re-read the profile before you trust it.

Proof it worked: what a healthy connector looks like

The companion script gathers every check above into one verdict, so you can schedule it rather than remember it.

Then confirm the outcome in the places a stakeholder will actually accept.

One closing point on honesty. If somebody asks you exactly how long the connector credential lasts, the correct answer is that Microsoft does not publish it. That is not a gap in your knowledge, it is a gap in the documentation, and the mitigation is the same either way. Measure the expiry you actually have, alert on it, run a second connector, and never let deployment day be the thing that tells you the connector died.

References

Microsoft official documentation, each page read while writing this post:

• Enrollment for Microsoft Entra hybrid joined devices, Windows Autopilot, for the connector requirements, install flow, MSA creation, event log path, 30-day cleanup and uninstall steps.
• Install the Intune Connector for Active Directory, tutorial step 2, for the version floor 6.2501.2000.5, the WebView2 build 6.2504.2001.8 and the custom MSA options.
• Configure proxy settings for the Intune Connector for Active Directory, for the two .config files, the defaultProxy examples and the service restart step.
• Windows Autopilot troubleshooting FAQ, for the moved event log path, ODJConnectorUI.log, the SCHANNEL PKCS fix and error 0x80070774.
• Intune Connector for Active Directory installed but does not appear, for the OdjServiceBaseUrl error and the proxy resolution.
• Network endpoints for Microsoft Intune, for the Intune core service endpoints and the statement that SSL traffic inspection is not supported for the manage.microsoft.com endpoints.
• deviceManagementDomainJoinConnector resource type, for the state, version and lastConnectionDateTime properties.
• List deviceManagementDomainJoinConnectors, for the GET request and the DeviceManagementConfiguration.Read.All permission.
• Overview of Certificate Connector for Microsoft Intune, cited only for contrast, including the documented rule that it must not share a server with the Intune Connector for Active Directory.

No community or MVP deep-dive is cited in this post. Several were checked, and none of the pages that loaded were specifically about the connector credential lifecycle or its ongoing health monitoring, so the table was left out rather than padded with something off-topic.