DC trying to generating DNS records for old Active Directory domain

About 3 years ago, I changed my Active Directory domain name from 'old.local' to 'new.com'. As far as I can tell, I did everything at the time to make sure DNS and the whole AD infrastructure reflected this change. As far as I recall, dcdiag brought up everything as ok.

I've had some recent issues, potentially with AD, and this has caused me to run dcdiag again. The result is:

"Dynamic registration or deletion of one or more DNS records associated with DNS domain 'old.local.' failed.  These records are used by other computers to locate this server as a domain controller (if the specified domain is an Active Directory domain) or as an LDAP server (if the specified domain is an application partition)."

In addition:

"The dynamic registration of the DNS record '_ldap._tcp.gc._msdcs.old.local.' 600 IN SRV 0 100 3268 DC1.new.com.' failed on the following DNS server"

I've tried various things, including deleting the file C:\Windows\System32\config\netlogon.dns (which was full of entries for the old domain, merged in with the new). I then ran a fresh ipconfig /registerdns, followed by restarting the netlogon service. A few mins later, the new netlogon.dns file is regenerated, but with all the same incorrect entries.

I've also gone through all AD tools I can think of to check there isn't lingering entries for the fold domain, including AD Domains & Trusts, AD Sites and Services, ADSI Edit and LDP.exe. Nothing flags up as troublesome :-(

Any thoughts on where else to look, or what else to do is much appreciated!
Who is Participating?
bluemercuryConnect With a Mentor Author Commented:
It would seem the main registry entry that needs altering is found in:


AlternateComputerNames was the entry containing the old DC name, which I altered.

In addition, I also browsed to:


and altered the OptionalNames entry. This appeared to be correct (as it was listed as a NETBIOS style name that hadn't changed) but dcdiag was grumbling about it being wrong, so I changed it to the full DNS host name like the above, and it seemed to like that.

Then I restarted the system.

Following this, I browsed to %windir%\System32\config and renamed netlogon.dns and netlogon.dnb with '-old' suffixes in the name, just in case they were needed again.

Then fired up a command prompt, and did the following:

Ipconfig /flushdns
Net stop netlogon
Net start netlogon
Ipconfig /registerdns

This generated new netlogon.dns and netlogon.dnb files, and on opening netlogon.dns with notepad, I now don't see any records generated for the old domain. If I run dcdiag, in this regard it is now happy.

I did this over an hour ago, and it has retained settings correctly, so I'm assuming this is fixed.

I used sections of the two articles below to come to this solution:

Thanks to everyone for their input - will sum up and award points now
No MoreCommented:
When you open DNS snap-in can you see old forward lookup zone there ?
bluemercuryAuthor Commented:
Nope, no forward lookup zone in place, I think it was deleted and replicated to other DC a long time ago. I have noticed there are lots of reverse DNS A records for the old domain - any way this could be relevant? There didn't seem to be a way to delete individual records though :-(

Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

No MoreCommented:
Well you should remove any records of old domain

_msdcs.domain.local open this forward lookup zone and check everything for old records and remove them
You shouldn't have any zones for old.local if the domain rename was completed.

Check your DC's primary DNS suffix (easy way, run ipconfig /all).  Make sure it is not old.local.

Using ADSI Edit, check the msDS-AllowedDNSSuffixes attribute.
-Double-click the domain directory partition for the domain you want to modify.
-Right-click the domain container object, and then click Properties.
-On the Attribute Editor tab, in the Attributes box, double-click the attribute msDS-AllowedDNSSuffixes.
What do you have there?
bluemercuryAuthor Commented:
Hi footech.

Yep - concur with you points on there shouldn't be any 'old.local' DNS zones - from memory, the AD name change was ultimately a complete success (short of the problem I'm currently suffering, clearly!)

I'd already run ipconfig /all before posting, but just to double check I've run it just now and it lists the primary DNS suffix correctly as the 'new.com' domain.

In ADSI Edit, I can obviously only see things for the new.com domain (should I create a host records for the old DC hostname in the HOSTS file, to see if it can find any remnants of the old AD in ADSI Edit?). I've followed your instructions for the current domain, and the msDS-AllowedDNSSuffixes has no entries at all in this. Is this normal behaviour? I suspect like you, I hoped to see our old domain there, but alas no :-(

Many thanks
cmlbaeteConnect With a Mentor Commented:
Hi Bluemercury

I'm wondering if you have any old registry entries that make refer to the old domain. A slight Stab in the dark but ties in with an issue I had recently.
No, changing the HOSTS file would have no effect on what you see in ADSI Edit.  It looks at the AD database, which is the same one both before and after the rename.
Yes, that attribute should be blank (generally).  Just double-checking to make sure rendom /clean was ran.

BTW, you can remove individual (or multiple) DNS records (like the old PTRs that you mentioned) just by selecting them and pressing the Delete key (or right-clicking and choosing Delete).
bluemercuryAuthor Commented:
Thanks cmlbaete. Really appreciate the input - I hadn't thought beyond the AD infrastructure / schema itself, and that of course some rogue entries could be sitting in the local registry of the DC.

I think this has led to a solution, along with finding some finer details on other websites - I went down this path having got your comment.

Many thanks, will be posting details and awarding points shortly :-)
bluemercuryAuthor Commented:
Thanks footech - thought that was probably the case with AD DB not being depedent on the host name.

You'll see above (sorry for the cross-over, just saw your message) that cmlbaete's comment lead me down the path of reviewing the registry, which indeed seems to be where the problem lay. So I'm going to award them the points, although really appreciate your efforts in trying to help me :-) Cheers
Glad you got it worked out.
bluemercuryAuthor Commented:
Closing comment - my own solution details what needs to be done for anyone else searching for this, but it was cmlbaete who suggested problem might reside in the registry, which indeed appeared to be totally the issue, so awarding points to them. Many thanks to all for your help :-)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.