One of my all-time favorite group policy settings is DNS Servers in the Network / DNS Client node under Administrative Templates. Now this policy setting only applies to XP and while I don’t know the exact reason, I can speculate.
While I was doing a migration I was presented with a challenge. I needed to migrate some workstations by business unit rather than by subnet or DHCP scope. So, I may have two machines sitting right next to each other that each used the same DHCP server and were part of the same scope but were not part of the same domain. We wanted each machine to have its DNS servers be a domain controller in their own domain . The options for DNS that were being handed out by DHCP were for a domain controller in the legacy domain.
We didn’t have a lot of traction with the network team so we decided to use this group policy instead. It worked great for what we wanted but we did find what to us was a very odd behavior.
Clients in both domains continued to get their DHCP lease and options from the existing DHCP server as expected. For workstations in the target domain we added the policy to set the DNS server to our domain controllers acting as DNS servers.
At some point, we were called on to troubleshoot something on one of these workstations that we thought was name resolution related. We got on and ran an IPCONFIG. We were shocked to find that the DNS servers were not the ones that we set through group policy but rather they were the legacy DNS servers. Well, we thought we had our smoking gun. Policy wasn’t applying to this machine.
Then we launched NSLOOKUP. Guess what we found? The DNS servers that we tried to contact for name resolution were the servers we configured through policy. To confirm the behavior we took a network trace and validated that the GPO-configured DNS servers were being used for name resolution.
The policy doesn’t touch the adapter – which is what ipconfig shows. The policy setting is applied to the machine and the DNS resolver obeys the policy configured. Look for a future post from Jared where he explains why it has to be this way.
This policy is not effective in Vista or Win7 (or any server operating systems). While it was helpful to us, it was a little disarming as it made our expectations of a troubleshooting standard, ipconfig, unreliable. It also caused a functionally damaging issue which you can see in the note below. Just imagine all of the confusion you can cause with that policy setting in a large environment. Fun.
NOTE 1: There are other problems with this policy which are much more challenging. The policy setting is global and applies to all adapters. When your users take their laptops home and connect to their network, they aren’t able to function very well. That’s because the cached policy continues to override the DNS settings handed out by their home router. They need admin rights to override this.
NOTE 2: The other funny thing is that if you accidently fat finger the DNS address, the only way to get your box to pick up a new policy or setting is to go to the box (locally or remotely) and delete the policy from history. Or I suppose you could stand up a DNS server with the erroneous address and duplicate zone data. With the wrong DNS server listed, the client will never be able to find the domain in order to find and apply new policy settings.
Now after reading that, are you surprised that Microsoft doesn’t support this policy setting in Vista, 7, or any future operating systems?