This one was a fun one that really threw me for a loop. DNS is an issue no matter where you go. Recently facebook showed the world how DNS can take everything down. DNS in your domain is very important to keep alive and healthy. Having items sit in your DNS is deadly to your org. That is why something called DNS Scavenging exists. This story is a story about DNS and how it directly affected group policy.
Scenario – Wrong Server!
A client called and stated that group policy wasn’t applied to a single machine. He said he couldn’t even log into the machine with new accounts, just accounts that were on there from the day before. He went as far as to say that a user that just changed his password had to use his old password. Very interesting combo of items.
Who, What, Where, When, How
- Who: Anyone using this computer. Users who never signed into the machine, and users who has signed in but changed their passwords recently.
- What: Login with thier current passwords, Login, Group Policy not applying.
- Where: This single machine, later on discovered another.
- When: One week before the issue started. (After DHCP was edited)
- How: When they log in.
When I first came in, I looked at the machine in question. I ran an IPconfig /all on the machine to get basic information. I marked down the IP, subnet, mac address, DNS servers, and the DHCP server. I then ran the gpresult /r and the command errored out saying the group policy server did not respond. Hum… I pinged the DNS I noted and the ping came back. I ran NSLookup on the dns server’s IP address to get a hostname. The hostname came back as “xxx-bobsmacbook”. Well now, that’s not the DNS server. I asked the client for the DNS server information. He gladly gave it to me. I RDPed into the DNS server. The DNS server was also the DHCP server and the AD server. All the fsmo roles were on this machine. Sigh… Ok, other than that, I deep-dived into DNS because the NSLookup came back as someone’s mac book. Sure enough, there was an entry into DNS from about 2 years before for bobsmacbook at the IP address the machine believed was the DNS server. Infact, every IP address in the subnet was inside there. Most of them were years old.
I looked at the client and asked why their DNS was so full of old records. He replied with, that’s our archive. It took everything in me not to facepalm. I mean, my hand moved instinctively to my face. After explaining the importance of DNS to the client, the client agreed to enable DNS Scavenging. Wouldn’t you know it, after the first rotation, the entire company started to move much quicker. Requests to the IIS server took only seconds instead of minutes. Copying files across the network just generally did better. NSlookup worked. The computer in question group policy was updated correctly. When DNS breaks, everything suffers. In this case, DNS was a young man covered in trash bags.
How to enable DNS Scavenging
DNS Scavenging is an windows feature that finds old stale records and removes them. This ensures environments with DHCP do not detect multiple devices based on bad/multiple DNS entries for the same device. Here are the steps to enable it.
- Start > Programs > Administrative tools > DNS > DNS Manager.
- Right click the DNS Server
- Click set Aging/Scavenging for all zones.
- Check box the “Scavenge Stale Resources Records
- Select the No-refresh and Refresh intervals totals combined equals to or is less than the DHCP lease. If the lease is 8 days, set the rates at 4 each.
- Click Ok.
- On the Server Aging/Scavenging Confirmation screen, check box the “Apply these settings to existing active directory intergrated zones.”
- Click ok
- (Optional) Right click the DNS server and click the “Scavenage State Resource Records” to start the process.
There you have it. The DNS records will be purged when the time comes. This allows DHCP to issue IP addresses with no problems and DNS stays clean.
As always, if you have any questions, feel free to ask.