Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have inhertied an issue where my AD Integrated DNS Zone was deleted and there are no system state backups available. I have checked in AD, under DNS and there are no records there. However, under the Zone (as listed in DNS) most records are present. On one of my DCs, I manually increased the SOA record and restarted the netlogon service, this has got the "zone" replicating again. I have also repopulated the GUIDs under the _MSDCS folder. Under the properties of the Zone, it is still listed as AD integrated.

My question is: If I change the properties to "Primary" it should create the txt file in System32\DNS. Assuming I allow replication time etc, can I just change it back to AD and will that repopulate the AD side of things?

Or will I need to export the contents of the txt file, then delete the zone and recreate?

Also, one further question: My Forest Root Domain has a broken delegation in DNS to the child Domain - again inherited and down to poor administration. The delegated namespace is the same as the AD integrated zone that I have the issue with above - if I repair this (by putting "Live" DCs within the delegated options) will this affect the other AD zone? Or is this a symptom of the above issue?

If you need further info, or if I have not been specific enough please accept my apologies and I shall endeavour to supply what you need.

Many thanks in advance for your assistance.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

You mentioned that it's replicating again - is it back in the AD container now?

Keep in mind that there's two different locations that AD will keep zones - Legacy (Win 2000 compatible) zones are stored in the default directory partition (CN=MicrosoftDNS,CN=System,DC=example,DC=com), while there's two different directory partitions for modern-style integrated zones - DC=DomainDNSZones,DC=example,DC=com and DC=ForestDNSZones,DC=example,DC=com. This was done so that the zone data can be replicated only to the AD servers that are serving the zones, as opposed to all AD controllers (regardless of whether they were DNS servers) when the data was stored in the default partition.

Yes - toggling the zone to local and back should rebuild its directory objects - but make a backup of the zone file while it's in text format, just in case.

For the delegation, just manually create the NS records in the parent zone (putting them in the delegation tab does the same) - this is probably an unrelated issue that has never been right from the day it was created.

share|improve this answer
    
Thanks for your reply. This is what is confusing me, as the data is still not in AD - I checked AD users and Computers, using advanced features, and noticed it was empty. I have just confirmed with ADSIEDIT that it is still empty. The other areas "DomainDNSZone" doesn't exist, so I am assuming that this is due to it being an "old" style zone. I will make the change to the Zone type this Friday, just in case - thanks. I'll repair the delegation tonight. Thanks for your input and I will advise progress. James –  Zoidberg Aug 1 '11 at 15:54
    
The newer-style partitions aren't visible through Users and Computers - to view, you'll need to fire up ADSIEdit or another raw-LDAP type of tool, then enter the partition path (DC=DomainDNSZones,DC=example,DC=com) manually in the connection window. You can check where the storage should be by pressing "Change" on the location section of the zone's properties - the top two options correlate to the separate partitions, while the legacy option sets the legacy partition. –  Shane Madden Aug 1 '11 at 16:04
    
THANKS! It's in there - there are two, the working one listed correctly - the non working one with a square followed by CNF: then some hieroglyphics! I assume that once I have a good system state backup, I should delete the "empty" one - or, given what has transpired, should I just let "sleeping DNS Zones lie..." James –  Zoidberg Aug 1 '11 at 16:14
    
Oh, those CNF objects mean there was a naming conflict at some point - you usually see them with, say, local groups from promoted DCs that conflicted with existing groups, or from migrated objects; I can't say I've ever seen that from a DNS zone. Given the strangeness that you're seeing from it, I'd say make sure you've got all your bases covered in case of issues, then try to nuke it! –  Shane Madden Aug 1 '11 at 16:24
    
Thanks again for your help - all working. I think I'll leave it for a while then kill it :-) –  Zoidberg Aug 2 '11 at 9:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.