We're planning to move users and devices to Entra ID, but internal DNS looks like one of the biggest hidden dependencies. Our applications and VPN currently rely on resolving internal names through on-premises DNS servers. If we eventually remove or retire the Active Directory DNS servers, how should devices, applications, and VPN clients resolve internal resources? What other dependencies should we identify before making the move, and how can we address them?
4 Answers
Before removing Active Directory, inventory anything depending on it: domain authentication, LDAP, Kerberos, Group Policy, service accounts, certificates, SMB file shares, print services, scheduled tasks, scripts, management tools, VPN authentication, and applications that use hard-coded domain names. Entra ID can replace identity and device management in many cases, but it isn’t a drop-in replacement for every traditional AD function.
If the goal is only to move identities and devices to Entra ID, you may not need to remove on-premises DNS at all. Keep AD and internal DNS for the remaining on-premises services, and gradually migrate those services separately. If you do retire AD later, first provide replacement DNS and authentication paths, such as private DNS zones, conditional forwarding, a site-to-site or client VPN DNS configuration, and modern authentication for applications that support it.
Don’t treat endpoint DNS registration as the main issue. Losing automatic hostname records can make troubleshooting and management less convenient, but it usually isn’t the core blocker. The real question is whether clients can resolve and authenticate to the resources they need. A reliable RMM can still report device IP addresses, while internal applications and VPN clients need a deliberately designed name-resolution path.
Entra joining devices doesn’t automatically eliminate the need for internal DNS. If you still have on-premises servers, private cloud resources, internal applications, file shares, or VPN services, you’ll need to keep DNS infrastructure that can resolve those names. That could be your existing domain DNS, dedicated internal DNS servers, or a cloud/VPN DNS solution. The important part is that clients receive the correct DNS servers and search suffixes through Intune, VPN configuration, DHCP, or the relevant networking platform.
It’s worth testing each application from an Entra-joined device while connected both on and off the VPN. That usually exposes hidden dependencies such as old DNS suffixes, NTLM authentication, certificate trust, or applications that only work when the device is domain joined.