Resolving Hybrid DNS Failures for Entra ID Hybrid-Joined Devices

#Operational requirement

When a device is hybrid-joined to Entra ID, it still depends on your on-premises Active Directory

The production consequence is real. Broken UNC path access to file shares, failed Group Policy

#Prerequisites and required permissions

You need the following in place before you touch a live device:

• Domain Admin or delegated DNS Admin rights on the on-premises Active Directory-integrated DNS zone.
• Network Contributor or DNS Zone Contributor role in the Azure subscription that hosts the Azure Private DNS zone, the VPN Gateway, or the ExpressRoute circuit.
• Intune Administrator role, or a scoped custom role with Configuration Profile permissions, in the Microsoft Intune admin centre.
• Local admin or remote PowerShell access to at least one affected hybrid-joined test device, ideally reached via Remote Help or a jump host rather than the production user’s live session.
• Confirmation that a maintenance window or change record exists before you modify DNS server addresses on client-facing Group Policy or Intune profiles, since this affects every device in scope, not only the one you are debugging.

If you do not hold DNS Zone Contributor in Azure, stop and obtain it before Step 3. Editing conditional forwarders without matching Azure-side records is exactly how a split-brain condition

#Step 1: Confirm the symptom and scope the affected population

Do not assume the fault is DNS until you have proven it. Run the following from the affected device, over the same VPN or corporate connection the user was using at the time of the fault:

1Resolve-DnsName fileserver01.corp.kbytech.local -Type A
2Resolve-DnsName login.microsoftonline.com -Type A
3Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Format-Table

Expected result if healthy: the internal FQDN resolves to a private RFC1918 address on your on-premises subnet, and the Microsoft 365 FQDN resolves to a public Microsoft-owned address. If the internal name fails with a name-not-found response, or simply times out, while the public name resolves without issue, you are looking at a split forwarding fault, not a general network outage. A frequent gotcha here: a device that recently resumed from sleep may still hold a stale cache from a previous network, so run ipconfig /flushdns before trusting a failing result. Capture the output as your first piece of evidence, and note the interface name and DNS server addresses returned by Get-DnsClientServerAddress.

Scope the affected population before you fix anything. Check whether this is one device, one VPN profile, or every hybrid-joined machine that connected after a specific date. Pull affected device counts from Intune:

1Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
2Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows'" |
3  Select-Object deviceName, lastSyncDateTime, managementState

Checkpoint: you should now know whether this is an isolated client fault or a systemic delegation problem affecting a cohort. Do not move to Step 2 until scope is confirmed, because the remediation path differs depending on the answer.

#Step 2: Validate on-premises DNS zone delegation and conditional forwarders

On a domain controller hosting the DNS role, confirm the conditional forwarder for your Azure-hosted zones, commonly used for AWS-hosted or Azure-hosted application namespaces, is present and pointing at the correct resolver addresses:

1Get-DnsServerConditionalForwarderZone -ComputerName DC01
2Get-DnsServerZone -ComputerName DC01 | Where-Object {$_.ZoneType -eq "Forwarder"}

A common legacy trap here: older AD DS estates often carry a conditional forwarder configured against a static IP address for an Azure Private DNS Resolver inbound endpoint that has since been rebuilt with a new address after a subscription migration. The forwarder entry looks perfectly valid but actually points at a dead or reassigned address. Confirm the current inbound endpoint address in the Azure portal, or via CLI:

1az network private-dns resolver inbound-endpoint show 
2  --resource-group rg-network-prod 
3  --dns-resolver-name dnsres-corp-prod 
4  --name inbound-ep-01 
5  --query "ipConfigurations[0].privateIpAddress"

If the address returned does not match what is configured in the on-premises conditional forwarder, that mismatch is your root cause. Fix it with:

Set-DnsServerConditionalForwarderZone -Name "privatelink.azure.kbytech.local" -MasterServers 10.20.0.10 -ComputerName DC01

Checkpoint: re-run the Resolve-DnsName test from Step 1 against a resource behind that forwarder. If it now resolves correctly, you have confirmed root cause and can move on to remediating the client fleet. Record the old and new master server IP addresses in the change ticket immediately; you will need them for rollback if this fix causes unexpected side effects elsewhere in the estate.

#Step 3: Confirm VPN and Azure-side connectivity for the DNS path

DNS forwarding only works if the underlying VPN or ExpressRoute path is actually up between your on-premises DNS servers and the Azure Private DNS Resolver’s inbound endpoint. Confirm reachability from the domain controller itself, not from a client:

1Test-NetConnection -ComputerName 10.20.0.10 -Port 53
2tracert 10.20.0.10

If Test-NetConnection reports the port as unreachable, check the VPN Gateway connection status in Azure and the corresponding site-to-site tunnel state on the on-premises firewall. A tunnel that shows Connected in the Azure portal can still be silently dropping UDP port 53 traffic if a network security group or route table was edited during an unrelated change and inadvertently narrowed the allowed port range. This is the single most common false negative in this whole runbook: the tunnel reports healthy, but the specific port your DNS traffic depends on has quietly been blocked. Cross-check the rule set directly rather than trusting a portal summary view, since summary views can lag behind rules applied through a pipeline:

az network nsg rule list --resource-group rg-network-prod --nsg-name nsg-dns-subnet --query "[?destinationPortRange=='53']"

Where possible, add a monitoring check that alerts on DNS query failure rate rather than tunnel state alone, since a tunnel that reports healthy can still be dropping port 53 traffic, exactly as shown above.

#Step 4: Correct and redeploy the DNS client configuration via Intune

Once the server-side forwarding is proven correct, check whether the Intune-deployed network profile is pushing the wrong DNS server order to hybrid-joined devices. Open the Microsoft Intune admin centre, navigate to Devices, then Configuration profiles, and locate the Wired, Wi-Fi, or VPN profile applied to the affected device group. Confirm the DNS server list places your on-premises domain controllers first, with Azure Private DNS Resolver addresses only as secondary entries where the architecture genuinely requires it.

If the profile is wrong, correct it and force a policy refresh from the client for testing, rather than waiting for the standard sync interval:

Start-Process "ms-device-enrollment:?mode=sync"

Checkpoint: after sync completes, re-check Get-DnsClientServerAddress on the test device and confirm the new order has actually applied, not merely queued. Intune policy application can lag behind portal changes by several sync cycles, so do not declare success until the client-side value has genuinely changed. A device that still shows the old order after two sync attempts usually indicates a conflicting profile assignment rather than a sync delay, so check for profile conflicts before waiting any longer. Document the profile version number you changed to in the change ticket, since Intune retains version history you will need for rollback.

#Step 5: Retest end-to-end from a representative hybrid-joined device

Repeat the exact commands from Step 1 on the same test device, and additionally validate that Group Policy and hybrid-join health are unaffected:

1dsregcmd /status
2gpresult /r

Confirm AzureAdJoined and DomainJoined both report YES, and that Group Policy last applied successfully within the expected refresh window. A DNS fault that persists long enough will also break Group Policy processing, so this step catches secondary damage the original ticket never mentioned. Repeat the full test on a second device from a different subnet or office if one is available; a fix that only works on your test machine’s subnet usually means the forwarder or route change was scoped too narrowly.

#Verification

Retain the following as closure evidence, attached to the change or incident record:

• Before-and-after output of Resolve-DnsName for both an internal FQDN and a Microsoft 365 FQDN.
• Screenshot or export of the corrected conditional forwarder configuration and the matching Azure inbound endpoint address.
• Test-NetConnection output confirming port 53 reachability across the VPN or ExpressRoute path.
• The Intune configuration profile version history showing the corrected DNS order and the device sync timestamp confirming application.

Where your organisation runs centralised logging, also attach the relevant Log Analytics or SIEM query results showing DNS query success returning to baseline after the fix.

#Failure Modes

Use this table to triage quickly once initial diagnosis is complete:

#Rollback

If the conditional forwarder change causes wider resolution failure than the original fault, revert immediately using the exported prior configuration:

Set-DnsServerConditionalForwarderZone -Name "privatelink.azure.kbytech.local" -MasterServers 10.20.0.5 -ComputerName DC01

If the Intune profile change causes broader client impact, restore the previous profile version from Configuration profiles, then Version history, in the Intune admin centre, assign it back to the affected device group, and force a sync. Do not delete the faulty profile version; retain it with an annotation explaining why it was reverted, since it forms part of the change record. Confirm rollback success using the same Resolve-DnsName and Get-DnsClientServerAddress checks used in Step 1 before closing the rollback action.

#Operational Summary

This fault pattern recurs because hybrid DNS depends on two independently managed systems, on-premises Active Directory DNS and Azure Private DNS, staying synchronised across every network change either side makes. A subscription migration, a firewall rule tidy-up, or an Intune profile edit made in isolation will eventually break the other half of the split. Deliverable for this exercise: a completed diagnostic pack for one affected device containing the Step 1 baseline, the corrected forwarder or profile configuration, and the Step 5 retest confirming both internal and Microsoft 365 resolution succeed alongside healthy hybrid-join status. Close the associated change record only after this evidence is attached, not before, since an unclosed change with no evidence is indistinguishable from an unverified fix during a future audit. Keep the pack once closed; it is the template you will reuse every time this ticket reappears, and it will reappear.