Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones

Revisions:

Original publication 3/2006
Recompiled 6/10/2010
Updated 12/9/2010
Updated 8/31/2014
—

Prologue

Ace here again. I’m cleaning up my blogs for technical and syntax errors. If you see anything that needs correction, please let me know.

Preface and Scope Of this Article

This blog explains how to use ADSI Edit to determine if duplicate zones exists in the AD database and to delete them.

When  using ADSI Edit, the duplicate zones show up in the partitions with names that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number. You will be checking EACH DC. When you find them, you will simply delete them. because they are useless and cause substantial problems.

This blog also explains how duplicate zones will appear to make zone records disappear.

Introduction to Duplicate Zones

Duplicate zones can cause numerous issues for the mere fact that the DNS zone that DNS is showing you on a specific DC may not have the latest up to date data. It literally may be missing data that you see on other DCs. If there are duplicate or conflicting zones, the zone data can’t replicate, resulting in each DC may have a different copy of the zone, which then results in unreliability and AD issues.

And to further complicate it, there are three different storage locations that AD can store AD integrated DNS zones – DomainDnsZones, ForestDnsZones, and the DomainNC partitions. You can read more on specifics in one of my other blogs:

DNS Zone Types Explained, Storage Locations in the AD database, and their Significance in Active Directory.
https://blogs.msmvps.com/acefekay/2013/04/30/dns-zone-types-explained-and-their-significance-in-active-directory/

Symptoms?

You may have a duplicate zone or a conflicting zone if a zone exists in both the Domain NC and/or in one of the Application Partitions. Some of the symptoms include:

• Trying to change the replication scope, you receive an unusual error message stating, “The name limit for the local computer network adapter card was exceeded.”

• Event ID 4515
• An admin may see the data on a different DC is not there and will manually create records.
• Zone data is disappearing, or it appears to be. This can be caused by:

• Someone is intentionally or unintentionally deleting the data (usually unlikely but can occur). If you think someone is deleting zone data, enable auditing.
  DNS Records Disappearing and DNS Auditing
  http://msmvps.com/blogs/acefekay/archive/2010/12/09/dns-records-disappearing-and-dns-auditing.aspx

Causes?

• You’ve installed DNS on another DC and you don’t see the zone under DNS that is on the other DCs, so you manually created the AD zone because you didn’t have the patience to wait for replication to occur, which it would have automatically populated.
• You’ve promoted a new DC in another site and didn’t have the patience to wait for the zone data to replicate.
• Antivirus not configured to exclude AD communications (common cause).
• At one time, or currently, the AD environment is a mixed Windows 2000/2003/2008 environment and DNS is installed on all operating system versions. On Windows 2000, if the zone is AD Integrated, it is in the DomainNC partition of the AD database, and should be set the same in Windows 2003’s or newer DC/DNS server to keep the zone data compatible and allow both operating system versions to be able to read and use them.
• Someone must have attempted to change it in Windows 2003 or 2008 DNS to place the zone in the DomainDnsZones partition no realizing the implications, hence the duplicate. In a scenario such as this where you want to use the Windows 2003 application partitions, you then must insure the zone on the Windows 2003 is set to the DomainNC, then uninstall DNS off the Win2000 machine, then once that’s done and AD replication has been given time to occur, you can go to the Windows 2003 or newer DNS and change the partition’s replication scope to one of the application partitions.
• A new domain controller was promoted into the domain, and the administrator manually created the zone name in DNS. This causes a duplicate. The proper way was to simply install DNS, and allow AD replication to occur. The zone will auto-populate into DNS.

I usually don’t want to assume someone’s deleting data. That’s would be the far end of the spectrum, especially if more than one DC is showing inconsistent zone data.

I feel the best approach to find out which is occurring is to first find out if there is a duplicate zone. This is because auditing is time consuming, and you need to parse through all the events generated in the Event Security Logs. It’s easier to run ADSI Edit to find if there are duplicates. Once you’ve determined it’s not a duplicate zone issue, then you can move on to DNS auditing. If it is a duplicate zone issue, follow the procedure below to remove them.

*

AD Integrated Zones Storage Locations

First, a quick review on the partitions. Hopefully you’ve taken a few moments to read my blog link that I posted above to understand the partitions. If not, I’ll just touch base on it here so you understand it and can relate to it. For specifics and the nitty gritty, read my other blog above.

Windows 2000:

the physical AD database is broken up into 3 logical partitions, the DomainNC (Domain Name Context, or some call the Domain Name Container), the Configuration Partition, and the Schema Partition. The Schema and Configuration partitions replicate to all DCs in a forest.

The DomainNC is specific only to the domain the DC belongs to. That’s where a user, domain local or global group is stored. The DomainNC only replicates to the DCs of that specific domain.

When you create an AD Integrated zone in Windows 2000, it gets stored in the DomainNC. This causes a limitation if you want this zone to be available on a DC/DNS server that belongs to a different domain. The only way to get around that is for a little creative designing using either delegation, or secondary zones. This was a challenge for the _msdcs.contoso.com zone, which must be available forest wide to resolve the forest root domain, which contains the Schema and Domain Name Masters FSMO roles.

Windows 2003 and newer:

There were two additional storage locations added to the AD database for DNS storage use. These areas are called “partitions,” specifically the DomainDnsZones and ForestDnsZones Application Partitions, specifically to store DNS data. They were conceived to overcome the limitation of Windows 2000’s AD Integrated zones. Now you can store an AD Integrated zone in either of these new partitions instead of the DomainNC. If stored in the DomainDnsZones app partition, it is available only in that domain’s DomainDnsZones partition. If you store it in the ForestDnsZones app partition, it will be available to any DC/DNS server in the whole forest. This opens many more design options. It also ensures the availability of the _msdcs.contoso.com zone to all DCs in the forest. By default in Windows 2003, the _msdcs.contoso.com zone is stored in the ForestDnsZones application partition.

Selecting the Replication Scope in Windows 2003 and newer:

When selecting a zone replication scope in Win2003, in the zone’s properties, click on the “Change” button. Under that you will see 3 options:

• “To all DNS servers in the AD forest example.com”  The top button. This option puts the zone is in the ForestDnsZones Application Partition. This setting will allow the zone data to replicate to all domain controllers to every domain in the forest, including if additional Trees exist in the forest.
• “To all DNS servers in the AD domain example.com”  The middle button. This option means the zone is in the DomainDnsZones Application Partition. This setting allows the zone to be stored and replicated in the DomainDnsZones Application Partition in the specific domain that it exists in. This setting is not compatible with Windows 2000 domain controllers. If Windows 2000 domain controllers exist in the domain, then the bottom option (below) will need to be used.
• “To all domain controllers in the AD domain example.com”  The bottom button. This option means the zone is in the DomainNC (Domain Name Context) portion of the actual AD database. This is only for Windows 2000 compatibility, that is if you have any Windows 2000 domain controllers in that specific domain you are administering.
  

If you receive an Event ID 4015 or the following error, it may indicate there is a duplicate or conflicting zone that exists in the DomainNC, the DomainDnsZones Application partition and/or in the ForestDnsZones partition.

*

Non-AD Integrated Primary and Secondary Zones

A Primary or Secondary zone that is not stored in AD is stored in a text file in the system32\dns folder. This type of zone storage has nothing to do with the above types ONLY unless it is truly a secondary with the Master being a DC transferring a copy of the zone. This types of zone storage is obviously not secure.

Now **IF** you did manually create a zone (whether intentionally or unknowingly) on one DC while it already existed on another DC, then you may have a duplicate.

*

Duplicate zone names will start with the letters,  “CNF…” or “InProgress…”

If there is a duplicate, you can use either ntdsutil or ADSI Edit to take a look. I will outline in this article on how to use ADSI Edit to look for the duplicate.

A duplicate zone name will appear in ADSI Edit that starts with an “In Progress….” or “CNF…” with a long GUID number after it.

• The “CNF…” means it’s in conflict due to a duplicate in the AD database.

• The “In Progress….” means it is trying to replicate, but it can’t because there’s another identical zone name but with a different USN version number (USNs are used for replication control between DCs) on another domain controller, which also means there’s a duplicate zone.

You can simply delete them, which will clean up the whole problem. Yep, a simple deletion. The “CNF” data is not used by AD, but yet it will conflict with the zone that is actually used, and needs to be deleted.

But before doing anything about it just yet, let’s read on to explain more about this and what may have caused it.

*

Preventing Duplicate Zones

AD Integrated Zones will auto-populate when adding replica domain controllers

If an AD integrated zone exists on a DC, and the DNS service is install DNS on another DC in the domain or forest, depending on the replication scope, it will automatically appear on the new DNS installation without any interaction on your part. You may have to wait a certain period of time for it to populate depending on if the other DC is in the same AD Site or not, but it WILL AUTO-POPULATE.

However, if you attempted to manually create the zone, believing that you need to do this to make the zone available on that DC, then you’ve just introduced a duplicate zone in the AD database. It doesn’t matter if the zone say originally exists in the DomainNC, and you manually create the zone on the other DC and put it into the DomainDnsZones application partition, AD will still recognize it in the AD database.

Duplicate zones cause numerous AD communication and access problems.

The point is, AD is smarter than you think. Let it do it’s thing.

*

An Example of what an AD Duplicate Zones looks like in ADSI Edit

This image shows “In Progress…” entries. They need to be deleted.

*

Using ADSI Edit to look at  your AD Partitions

This is a manual step by step. For a screenshot step by step, see the next section.

This section assumes you have a little familiarity withe ADSI Edit. If not, I suggest to get yourself familiar with it once you’ve connected into the various partitions as outlined below. Be careful deleting anything, for once deleted, it’s a destructive process and basically it’s gone. There is no “Back Button” or “Undelete,” or “Undo”  button. To restore data, you will need to run an Authoritative Restore from your backup program restoring that specific object that was deleted.

Determine if there are any duplicate zone.

While in ADSI Edit, if you see the same exact named zone in multiple partitions, such as seeing the same zone name in the Domain NC (Name Container) Partition, in the DomainDnsZones App partition), and/or in the ForestDnsZones application partition, you have duplicate zones. If this is the case, then you must choose which zone you want to keep.

I will select a DC that isn’t having a problem and delete the duplicates and conflicts off all other DCs.

Multiple domains or multiple tree forest?

If the AD forest is a multidomain forest with child domains and/or multiple trees, you must look at each domain’s DomainNC and DomainDnsZones partition, because each domain has one.

To view the DomainNC Partition (Default Naming Context)

• In ADSI Edit, rt-click ADSI Edit, choose “Connect To,” in the Connection Point click on “Well known Naming Context”, then in the drop-down box, select “Domain”.  If this is Windows 2003 or newer, this option shows up as “Default Naming Context”
• Expand DomainNC or Default Naming Context, then expand your domain name. Drill down to CN=System. Under that you will see CN=MicrosoftDNS.
  You will see any zones that are in the DomainNC partition under the MicrosoftDNS folder.
• If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!
•  

To view the ForestDnsZones Application Partition:

[ForestDNSZones]

1. Click Start, click Run, type adsiedit.msc, and then click OK.
2. In the console tree, right-click ADSI Edit, and then click “Connect To.”
3. Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK:
   DC=ForestDNSZones, DC=contoso, DC=com
4. In the console tree, double-click DC=ForestDNSZones, DC=contoso, DC=com.
   Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
5. You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

To view the DomainDnsZones Application Partition

[DomainDNSZones]

1. Click Start, click Run, type adsiedit.msc, and then click OK.
2. In the console tree, right-click ADSI Edit, and then click “Connect To.”
3. Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK: DC=DomainDNSZones,DC=contoso,DC=com.
4. In the console tree, double-click DC=DomainDNSZones,DC=contoso,DC=com
   Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
5. You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

*

Procedure with Screenshots:

.

.

.

.

.

.

.

.

*

Procedure to Delete the Duplicate zones

The easiest is to simply delete any duplicates you find in ADSI Edit. Choice #1, to delete them, can actually be safely done during production. Matter of fact, things may just start to work after you delete them! But Choice #2, which is a lengthy procedure, must be done during non-production hours.

Choice #1 (Recommended)

Just go into ADSI Edit and delete the duplicate zones you’ve found.

You can do this during production, and frankly, I’ve done it with a large infrastructure during production hours without any problems. This is my personal choice as long as there are no true duplicate zones, that is if there are duplicate zones without seeing any zone names prefixed with either an “In Progress….” or “CNF…” with a long GUID number after, and you truly see a duplicate of your actual zone, such as a domain.com in any of the partitions, then you must perform Choice #2.

Choice #2 (Not recommended)

This is a multi-step process to first change the zone to a Standard Primary Zone, which removes it from the AD database, allow AD replication to complete, delete the duplicates, then change the zone to AD integrated, and allow AD replication to complete.

• Choose only one DC to perform this action.
  • For example, if the duplicate is in the DomainDnsZones partition or DomainNC partition of a child domain, perform it only on a DC in that domain.
  • If the Duplicate is in the ForestDnsZones partition, you can choose any DC in the forest.
• Right-click the zone name, Choose Properties.
• Under the General  tab, click on the “Change” button next to the “Type” section.
• Then uncheck the box that says “Store the zone in Active Directory (available only if the DNS servers is a domain controller.”
• Click Ok, Don’t click Ok again just yet. Just click on Apply.
• IMPORTANT – You must allow AD replication to occur to replicate the change to all DCs that are in the replication scope of the zone. If you have DCs in another AD Site and have replication schedule set for example, to 3 hours, then you must WAIT for 3 hours.
• This action makes the zone a Standard Primary zone. This means it is now stored in the system32\dns\ZoneName.com.dns text file and is no longer in the AD database.
• You can also force replication, as well.  If there are AD Sites configured, and the replication schedule on the Site Connection objects is say 3 hours, you can reduce the replication schedule on the Site Connection objects to the minimal time allowed, which is 15 minutes. Then force replication by choosing the partner DC’s NTDS Setting, right –click, and choose Replicate Now.
• Once confirmed that replication has occurred, and refreshing the ADSI Edit window and seeing the zones no longer exist in any of the partitions, then you can now safely delete the duplicate zones.

• Note: Just to be clear, you will be deleting any zone names that you find that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number after it.
• Also Note: Deleting a zone is a destructive operation. Make sure you are only deleting duplicates!

*

References

DNS zone replication in Active Directory
http://technet.microsoft.com/en-us/library/cc779655(WS.10).aspx

Oops, our AD Integrated DNS zone’s are missing in Windows 2003!
http://blogs.technet.com/b/networking/archive/2007/05/10/oops-our-ad-integrated-dns-zone-s-are-missing-in-windows-2003.aspx

Directory Partitions:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbg_dat_favt.asp

kbAlertz- (867464) – Explains how to use ADSI Edit to resolve app partitions issues:
http://www.kbalertz.com/kb_867464.aspx

Event ID 4515 is logged in the DNS Server log in Windows Server 2003
http://support.microsoft.com/kb/867464

*

Summary

It seems like a lot of steps, but it really isn’t. Just read it over a few times to get familiar with the procedure. You may even want to change it into a numbered step by step list if you like. If you only have one DC, and one Site, then it’s much easier since you don’t have to mess with secondary zones or play with the site objects.

I hope that helps!

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs and Videos: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This blog is provided AS-IS with no warranties or guarantees and confers no rights.

Suggestions, Comments and Corrections are Welcomed!