When Autopilot Meets Infoblox: A Deep Dive into a Hidden DNS Roadblock

Modern device provisioning promises a smooth, cloud-first experience in recent years; until it runs headfirst into on-premises "why is this still being used" realities. 😉

Recently, I worked on deploying Windows Autopilot for hybrid Entra join in an enterprise environment that was also (unbeknownst to me at the time) rolling out Infoblox as their new DNS platform. What started as a relatively straightforward and planned hybrid join rollout became a multi-week diagnostic effort revealing how one overlooked DNS migration detail can quietly derail the entire process.

The Hybrid Join Dilemma

In many enterprise environments, the initial scoping conversations around Entra hybrid join deployments typically revolve around a fundamental question; why implement hybrid join for new machines when a modern, cloud-native option exists?

Microsoft has shown no signs of changing their stance on not recommending Autopilot with hybrid join, with some online discussions hinting at the possibilities of hybrid join via Autopilot being deprecated entirely (although nothing has been officially confirmed yet); instead, recommending Entra join as the preferred cloud-native option. But many enterprises still depend on it — usually because of legacy Group Policy (which was the case with this customer), on-prem authentication dependencies, or compliance restrictions.

The architecture looked solid on paper:

• Windows Autopilot configured for hybrid Entra join.

• Zscaler ZPA as a required pre-installation app for VPN connectivity during and after OOBE for line-of-site to a domain controller.

• Entra Connect for OU-based filtered sync and hybrid computer object enrolment.

However, for reasons unknown at the time, Autopilot test devices would not successfully hybrid join; and so, began and extended journey of trial and error to determine the cause, only to ultimately overlook the root cause of the problem.

Hint: Remember, it’s almost always DNS 😉

The Initial Investigation

The first clue emerged after reviewing the initial test devices in Entra ID. Devices that went through Autopilot were appearing as Entra joined only, not hybrid Entra joined. There were no errors in Intune provisioning, but the expected hybrid-joined status never showed up.

Hmm……...

At first glance, this looked like a synchronisation timing issue with the Automatic Device Join scheduled task that runs at user login (i.e. allowing the traditional offline domain join when the user is on the domain/connected to a VPN, completing the hybrid join). However, after 1-2 days of re-enrolment and log review, the pattern was consistent: the initial object in Entra ID remained as cloud-only (Entra joined).

No corresponding on-prem join entry existed; meaning the device registration phase never reached Active Directory.

Once the DNS issue (detailed below) was resolved, new enrolments began producing the expected behaviour — but with a twist: a duplicate device object appeared in Entra ID for each affected machine. Microsoft actually acknowledges this in their documentation: Duplicate device objects with hybrid Entra ID deployments

Which they essentially summarised as: “Yes, this will happen. Goodbye.” That’s the official stance — duplicate entries are a known and “expected” side effect of the way Autopilot hybrid join processes device registration. Not elegant but at least documented (and more or less easily addressed with Device Cleanup rules).

Digging Deeper

After confirming that everything was properly configured at the Intune-level, I decided to start checking endpoint-level logs, starting with the highly useful dsregcmd /status command. After running the command, an interesting discovery was made while reviewing the Diagnostic Data section:

AD Connectivity Test: PASS
AD Configuration Test: FAIL

For those that may not know, a failing “AD Configuration Test” almost always points to an SCP (Service Connection Point) issue — either missing or misconfigured. So, I double-checked everything related to the SCP:

• Verified the CN=Device Registration Configuration container in Active Directory.

• Confirmed the Service Connection Point object existed under CN=Services, CN=Configuration.

• Validated that its ServiceBindingInformation value correctly referenced the organisation’s tenant ID.

• Ensured permissions were correctly set for machine accounts to read it.

Everything checked out perfectly. That meant the SCP wasn’t the problem; even though the error strongly suggested it was.

With SCP ruled out, attention turned to what could cause the device to see the domain but fail to query its configuration. If the device could reach a domain controller (Connectivity = Passed) but couldn’t read the domain configuration pointing to the Entra tenant (Configuration = Failed), something was blocking LDAP discovery or SRV record resolution — despite the Service Connection Point (SCP) being verified in Active Directory.

The next logical suspect was DNS. Running:

nslookup -type=SRV ldap.tcp.dc._msdcs.domain.local

The lookup failed; no domain controllers found. The device could reach the network and ping domain controllers by name, but it couldn’t dynamically discover them. That’s when we learned that the client was simultaneously migrating their internal DNS to Infoblox, and it wasn’t yet forwarding or delegating SRV record requests properly.

What initially looked like an SCP problem turned out to be a DNS visibility issue masquerading as a configuration error.

Resolution

Once the DNS ownership shift was clear, we worked with the network and identity teams to correct it. The fix involved:

1. Re-establishing proper zone delegation from Infoblox to the authoritative AD DNS servers.

2. Adding conditional forwarders in Infoblox for all AD-related zones.

3. Ensuring SRV records were resolvable through both Infoblox and AD DNS.

4. Updating Zscaler ZPA DNS policies to use the proper Infoblox grid members and route domain queries correctly.

5. Revalidating DNS discovery:

nslookup -type=SRV ldap.tcp.dc._msdcs.domain.local
dsregcmd /status

After these changes, the AD configuration test correctly queried the SCP information, and the full hybrid join eventually completed successfully.

Key Lessons Learned

Autopilot and hybrid join

Hybrid Entra join can work, but it’s fragile in the sense of there being so many moving parts; any of which that if they stop working, will cause the process to fail. It depends on DNS, LDAP, and domain controller availability; all components the modern management stack is trying to phase out.

Unless you have a hard requirement for on-prem identity, go cloud-only Entra join. It’s cleaner, faster, and officially recommended.

Autopilot and infrastructure

When this Autopilot rollout began, I was under the assumption the environment was relying on standard AD DNS; the unknown migration to Infoblox caused unnecessary delays to what would have been a rather standard deployment.

Always verify the current state of DNS, on-prem networking, and directory services before starting Autopilot or Intune projects; especially when infrastructure ownership is shared across different teams.

Dsregcmd and troubleshooting

A passed “AD Connectivity Test” can be misleading if “AD Configuration” fails. The former only confirms the DC is reachable; not that it can be queried properly. Pair dsregcmd /status with DNS and LDAP validation early in the troubleshooting process.

Hybrid deployments multiply dependencies

Every new integration layer introduces another potential failure point; and every environment is different, so what works as a fix for one may not be easily replicated in another. Similarly, with so many interwoven dependencies, any one of the services experiencing downtime will affect your Autopilot enrolment as well.

My Final Thoughts

Hybrid Entra join is often unavoidable in some cases; especially in established, large scale enterprises but it requires precise coordination, stable infrastructure, and clear communication across teams.

In this project, the simple assumption that “DNS is still the same” caused days of confusion; all stemming from one uncommunicated migration. The Infoblox adjustments described earlier were ultimately a temporary workaround to restore functionality; the long-term, recommended resolution is to implement full Kerberos integration with Infoblox and retire DNS services from the domain controllers altogether.

That, however, is another extensive topic deserving of its own deep dive in a separate article 🙂.