What DNS Zone type should I use, a Stub, Conditional Forwarder, a Forwarder, or a Secondary Zone?? What’s the Difference??

By Ace Fekay
Originally Published 2012
Updated 3/20/2018

Intro

Ace again. DNS is a basic, yet important requirement that many still having problems wrapping their head around it.

Besides design, a huge part of DNS is understanding the differences between the zone types. Many have asked, when do I use a Stub zone, a Conditional Forwarder, or a Forwarder? Or better, what’s the difference?

I thought to put this simple comparison together compiled from past posts in the TechNet Forum.

Partner Organization DNS Resolution: What should I use, a Stub, Conditional Forwarder or Forwarder?

Secondary Zone

Secondary zones are read only copies “copied,” or “zone transferred” from a Master zone. This makes the zone data available locally (as read only, of course), instead of querying a DNS server across a WAN link. However, in many cases Secondaries are not used due to many limitations and security concerns, such as exposing all DNS zone data that a partner may not want to divulge.

In addition, Secondaries can’t be AD integrated, and the zone data is stored in a text file. So you would have to manually create a copy on all of your DNS servers.

Stub Zone

Organizations own their own AD zones. When business partners need to resolve data at a partner’s organization, there are a few options to support this requirement. Years ago, prior to Stub or Conditional Forwarders, there weren’t many options to handle this other than to use Secondary Zones and keep copies of each others zones via zone transfers.  While the solution worked well in regards to name resolution, it was not the best security-wise, due to trust level between partners, because zone data is fully exposed at the partner. This became a security concern because the partner is able to see all of their business partner’s records. When the zone was transferred to partners, who knows what they were doing with the information. If the information was made public, attackers would have a field day with all of the IPs for the networked devices.

When stub zones were made available, it became a solution to overcome this security issue. What is also beneficial about Stubs, is you can AD integrate them instead of manually creating a Stub on each individual DC. This way the zone will be available domain or forest-wide, depending on replication scope.

However, some may say due to the fact that the SOA records are included in the zone file, it may be a concern that the SOA and NS data is exposed. In such high security concerns, the better solution would be to use a Conditional forwarder.

Conditional Forwarder

This option is heavily used, and many look at them as the best regarding security concerns with zone data exposure, because no data is exposed. This option has worked very well in many environments.

With Conditional Forwarders, no information is being transerred and shared. The only thing you would need to know is one or more of your business partner’s DNS server IPs to configure it, and they don’t have to be the SOA, rather any DNS server that hosts the zone or that has a reference to the zone.

However, it does require open communication and let each other know when their DNS server IPs may change, because you must manually set them.

Windows 2003 introduced Conditional Forwarders, but it did not have the option to make it AD Integrated. If you have 10 DNS servers, you must create the Conditional Forwarder on each server manually. The AD integrated option was added to Windows 2008 or newer DNS servers, so you don’t have to manually create them on each DNS server. THis way the Conditional Forwarder will be available domain or forest-wide.

Parent-Child DNS Zone Delegation

Delegation can be used in a situation where a child domain host their own DNS zone.  Therefore in the forest root domain, you would create a delegation zone with the IPs of the DNS servers in the child domain.  This is normally performed when the child zone have their own administrators. It’s also useful they do not have access to “see” all of the forest root DNS records.

Summary

I hope this helps! If you have any questions, and I’m sure you do, please feel free to reach out to me.

Major revision – Published 3/20/2018

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2012|R2, 2008|R2, Exchange 2013|2010EA|2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Mobility

As many know, I work with Active Directory, Exchange server, and Office 365 engineer/architect, and an MVP in Active Directory and Identity Management, and I’m an MCT as well. I try to strive to perform my job with the best of my ability and efficiency, even when presented with a challenge, and then help others with my findings in case a similar issue arises to help ease their jobs. Share the knowledge, is what I’ve always learned.

I’ve found there are many qualified and very informative websites that provide how-to blogs, and I’m glad they exists and give due credit to the pros that put them together. In some cases when I must research an issue, I just needed something or specific that I couldn’t find or had to piece together from more than one site, such as a simple one-liner or a simple multiline script to perform day to day stuff.

I hope you’ve found this blog post helpful, along with my future scripts blog posts, especially with AD, Exchange, and Office 365.

clip_image0023 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163

Complete List of Technical Blogs
https://blogs.msmvps.com/acefekay/

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


 

Active Directory’s Reliance on DNS – Why not to use your ISP’s DNS

Intro

Ace again. Time to re-hash why DNS is important, or actually, NEEDED for Active Directory, and Azure AD .

Consider this….

You wake up and get ready for work. You sit down and have a bowl of cereal. You crack open a full gallon of milk. Now there’s a little less in the gallon, but you know you have plenty of milk for the next couple of days. You walk out of your house and drive off to work. Upon returning, you find the milk is missing. You know you had some milk left over when you left for work in morning. You walk out front and see your neighbor just happens to be outside. You walk over to him and ask him, “Do you know what happen to my milk?” He just stares at you not knowing what you’re talking about.

Can your neighbor, an outside entity to your internal household, respond to that? The same thing is occurring when you use an outside DNS server in your NIC properties (whether on the DC, member servers and/or client machines). If  the machines are set to use an outside DNS address, then your machines are literally asking an outside entity, “What’s the IP address of my domain controller?” The outside DNS servers do NOT have that answer.

Using an ISP’s DNS

What will happen if you use an ISP’s DNS address, or a router as a DNS address on a DC or client machine, is the machine (whether a DC or client), will ask the ISP’s DNS, “What is my DC’s IP address? I need to know because I would like to send a logon request.” The ISP’s DNS doesn’t have that answer. Their DNS servers do not host the your internal AD zone name therefore, they have no information about your internal AD network. It’s like me asking that guy down the street that I’ve never met, “Hey you, where did all the beer or milk go in my refrigerator?” He won’t have that answer either. 🙂

I’ve read and responded to numerous newsgroup and forums posts requesting assistance, as well as new customers I’ve been called upon to fix issues, with such complaints as taking a long time to login, can’t access printers or mapped drives, Outlook fails to find the Exchange servers, among other issues.

I’ve also seen other errors such as GPOs not working, can’t find the domain, RPC issues, Exchange profusely failing and its services not wanting to start, users complaining they can’t get their emails, etc, when the ISP’s DNS servers are listed on a client, DCs and/or member servers, or with  DCs.

After a short investigation, I’ve come to find that the domain controllers network properties have included either an ISP’s DNS address, the ISP’s router’s IP address, or some other external DNS server as an IP address in the NIC’s properties. I’ve also observed that using a non-internal DNS addresses were also found on internal company desktops and laptops, whether the IP configuration was set by a static entry, or from DHCP (DHCP Option 006).

This type of configuration can and will lead to numerous issues with a Active Directory, from authentication issues, replication issues, to much more.

I hope this explanation provides a greater understanding on how it all works and exemplifies to not ONLY use the internal DNS server for all internal machines, but as well as in the VPN’s DHCP service for VPN clients. Keep in mind, a client machine plugged in at home, using an air card, or say sitting at Starbucks, will probably be configured with an ISP’s anyway if outside the network. That is fine. If using a VPN connected to the office, the VPN client will use that DNS to find the VPN server for your network. But once the VPN authenticates and connects, the VPN will be configured with your company’s internal DNS servers on its interface, and because the VPN interface by default is the first in the binding order, therefore the first interface it will use, will be able to logon to the domain and authenticate to the domain in order to access internal resources, which is what you want it to do.

The Usual Suspects That Can Cause Issues with AD Communications, long logon times, etc

Here is a summarized list of possible causes, but NOT limited to:

  1. Single label name Active Directory DNS domain name (extremely problematic).
  2. SRV records missing. This can be due to DNS or network interface card (NIC) mis-configuration.
  3. Disjointed namespace.- AD domain name doesn’t match the Primary DNS Suffix and/or the zone name.
  4. Using an ISP’s or some other DNS server that is not hosting the AD zone or that doesn’t have a reference to it, in IP properties of the DCs and clients.
  5. DHCP Client service disabled on the DCs (a required service even if statically configured)
  6. DCs are possibly multihomed. A multihomed DC has more than one unteamed NIC, more than one IP and/or RRAS installed such as for VPN purposes, which makes it problematic if not configured properly (more info on this below).
  7. A third party firewall or security application is installed blocking traffic.
  8. Antivirus software blocking functionality
  9. Antispyware blocking functionality

AD & DNS Configuration

When I’ve visited a customer site to fix issues and noticing the DNS entries are incorrect on the DC(s), upon interviewing the parties involved that had configured the machines, simply stated they were not aware of this requirement.

Usually it simply comes down to a simple misunderstanding of AD and how DNS works, as well as the Client Side Resolver Service.  Some ISPs will tell their customers that they need to use the router as a DNS address, or that they need to use their DNS servers out on the internet, or they warn them that they will not resolve internet names. The ISP customer service reps are not well versed with how AD and DNS works, and frankly provide misguided advise.

Keep in mind, if a DC goes down for whatever reason, or simply not be available because the clients can’t “find” the DC,, so will your Exchange server, AD domain functions, mapped drive access, printer access, etc. If the DC actually went down, such as hardware failure, this is a worst case scenario and wouldn’t matter to config your machines with the ISP’s DNS. If you need, you can configure your own workstation to the ISP’s during such a crisis in case you need outside communication to research the problem, but you must change it back to your internal DNS once you’re done researching the issue and/or you’ve fixed the problem.

FYI about AD, DNS, authentication, finding the domain, GPOs, RPC issues,ISP’s DNS servers, etc

Active Directory stores it’s resources and service locations in DNS in the form of SRV records (those folder names with the underscores in them). These records are used for a multitude of things, such as finding the domain when a client logons, domain replication from one DC to another, authentication, and more.

If the ISP’s DNS is configured in the any of the internal AD member machines’ IP properties, (including all client machines and DCs), the machines will be asking the ISP’s DNS ‘where is the domain controller for my domain?”, whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP’s DNS does not have that info and they reply with an “I dunno know”, and things just fail. Unfortunately, the ISP’s DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

Therefore, with an AD infrastructure, all domain members (DCs, clients and servers), must only use the internal DNS server(s).

If for instance a user wanted to log on, part of the logon process involves the machine to find where the DCs are. The machine will ask DNS, “Where is my domain controller?” If the machine is properly set to use only the internal DNS servers, it will be able to respond with an answer, thus the user can logon.

If the machine asks the 4.2.2.2 DNS server, “Where is my domain controller?”, will it have that answer? No, unfortunately not.

Also, it is highly recommended to not use your firewall or router as a DNS or DHCP server. If you are using your NT4 as a DNS server in your AD domain, change it over to Win2003 DNS. Same with DHCP. NT4 DNS cannot support AD’s SRV requirements and dynamic updates. Windows DHCP service supports additional features for DNS Dynamic updates, as well as other features, that a router or firewall’s DHCP server does not support.

 

Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider’s (ISP’s) DNS servers or any other DNS other than the DNS hosting the AD zone, otherwise…
http://smtp25.blogspot.com/2007/05/do-not-configure-dns-client-settings-on_818.html

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (whether it was upgraded or not, this is full of useful information relating to AD and DNS, among other info):
http://support.microsoft.com/?id=555040

The DNS Client Side Resolver Service

Another question that has come up is, “Why can’t I use the ISP’s address as the second entry?” This will cause problems as well, due to the way the client side resolver works, which is the resolver service that runs on all machines – DC or workstation – that queries DNS and what to do with the answer. Yes, the domain controller, too, after all the domain controlleris also a DNS client, because it will query DNS to “find” itself.

The Client Side Resolver will query the first DNS server listed in the NIC’s properties. If that server doesn’t respond, it will remove it from the ‘eligible resolver list” for 15 “minutes and go on to the next one in the list. So say if the client happens to try to authenticate to AD in order to access a printer, and it’s stuck on the ISP’s, it will fail to connect until the 15 minute time out period expires and the list resets.

To summarize, if there are multiple DNS entries on a machine (whether a DC, member server or client), it will ask the first entry first. If it doesn’t have the answer, it will go to the second entry after a time out period, or TTL, which can last 15 seconds or more as it keeps trying the first one, at which then it REMOVES the first entry from the eligible resolvers list, and won’t go back to it for another 15 minutes at which time the list is reset back to the original order. This can cause issues within AD when accessing a resource such as a printer, folder, getting GPOs to function, etc. Now if the ISP’s is the first one, obviously it will be knocked out when a client is trying to login. This can be noticed by a really really logon time period the client will experience before it goes to the second one, your internal DNS. Therefore, the first one is knocked out for 15 minutes. Then let’s say the client decides to go to an internet site. It will be querying the internal DNS at this point. As long as the internal DNS is configured with forwarders to an outside DNS, or using it’s Root Hints, it will resolve both internal and external internet addresses.

In summary, based on the way the client side resolver service algorithm works, you simply can’t mix an ISP or some other DNS server that doesn’t host the AD zone name or have some sort of reference to it, whether using a conditional forwarder, stub, secondary or general forwarder, or expect problems. Read the following for more detail and understanding of the client side resolver service algorithm.

DNS Client side resolver service
http://technet.microsoft.com/en-us/library/cc779517.aspx

The DNS Client Service Does Not Revert to Using the First Server in the List in Windows XP
http://support.microsoft.com/kb/320760

Then if I don’t use the ISP’s DNS address in my machines, how will it resolve internet names?

For Internet resolution, the Root Hints will be used by default, unless a root zone exists. The root zone actually looks like a period that you normally type at the end of a sentence, such as a  dot “.” zone. If a root zone exists, delete it, and restart the DNS server service.

Therefore, the recommended “best practice” to insure full AD and client functionality is to point all machines ONLY to the internal server(s), and configure a forwarder to your ISP’s DNS server properties (rt-click DNS servername, properties, Forwarders tab). This way all machines query your DNS and if it doesn’t have the answer, it asks outside. If the forwarding option is grayed out, delete the Root zone (that dot zone). If not sure how to perform these two tasks, please follow one of the articles listed below, depending on your operating system, for step by step.

300202 – HOW TO Configure DNS for Internet Access in Windows Server 2000 (Configure Forwarding) :
http://support.microsoft.com/?id=300202

323380 – HOW TO Configure DNS for Internet Access in Windows Server 2003 (Configure Forwarding) :
http://support.microsoft.com/?id=323380

How to Configure Conditional Forwarders in Windows Server 2008
http://msmvps.com/blogs/ad/archive/2008/09/05/how-to-configure-conditional-forwarders-in-windows-server-2008.aspx

Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2
http://technet.microsoft.com/en-us/library/cc754941.aspx

DNS Conditional Forwarding in Windows Server 2003
http://www.windowsnetworking.com/articles_tutorials/DNS_Conditional_Forwarding_in_Windows_Server_2003.html

825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003
http://support.microsoft.com/?id=825036

 

Multihomed Domain Controllers

Another issue I’ve encountered is when a non-SBS domain controller has been configured with mutiple NICs, IP addresses, and/or RRAS. This is another problematic configuration that is dubbed as a “multihomed domain controller.” Multihomed DCs are extremely problematic if not configured correctly, however to configure one correctly involves a multitude of steps including registry changes to alter DNS registration. However, this blog is not intended to discuss multihomed DCs, rather to discuss using an ISP’s DNS address in your network. For more information on multihomed DCs, please read the following link to my blog on it, and how to configure it.

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters:
http://blogs.dirteam.com/blogs/acefekay/archive/2009/08/03/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

 

Summary

If you have your ISP’s DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). This will cause numerous problems with AD.

 

Related Links

291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS
http://support.microsoft.com/?id=291382

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (whether it was upgraded or not, this is full of useful information relating to AD and DNS, among other info):
http://support.microsoft.com/?id=555040

Domain Controller’s Domain Name System Suffix Does Not Match Domain Name:
http://support.microsoft.com/?id=257623

Clients cannot dynamically register DNS records in a single-label forward lookup zone:
http://support.microsoft.com/?id=826743

300684 – Information About Configuring Windows 2000 for Domains with Single-Label DNS Names
http://support.microsoft.com/?id=300684

828263 – DNS query responses do not travel through a firewall in Windows Server 2003:
http://support.microsoft.com/?id=828263

============================================================

Summary

I hope this provided a good understanding of DNS!!!

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

clip_image0023[2] clip_image0043[2] clip_image0063[2] clip_image0083[2] clip_image0103[2] clip_image0123[2] clip_image0143[2] clip_image0163[2]

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

Active Directory Firewall Ports – Let’s Try To Make This Simple

Preamble

Ace here again. I thought to clean up and re-publish my blog on AD ports requirements. Yes, they are extensive, to the dismay of the network group in your organization. But it is what it is, and it is what we need to follow to make AD work.

RPC server not available? Replication errors in the Event viewer? Sound familiar?

If so, you’ve been succumbed to the fact and realization there are possibly necessary ports being blocked causing these familiar AD communications errors. Whether between locations with firewall/VPN tunnel port blocks, Windows Firewall (which is usually not the culprit because they will auto-configure for the role of the machine and it’s current network location), or even security software or antivirus apps with some sort of “network traffic protection” feature enabled that is causing the problem.

Simply speaking, if there are replication or other AD communication problems, and you have an antivirus software installed on the endpoints or installed on all of  your DCs, disable it, or better yet, uninstall it. Uninstalling it is the best bet, so you know there are no traces of other subcomponents that are active that may still be causing the block. If after uninstalling it, and you find replication now works, well there you have it. At that point, you’ll need to contact your antivirus vendor to ask them the best way to configure it to allow AD communications and replication.

If it’s not your antivirus or security app, and disabling the Windows firewall doesn’t do the trick, then it’s obvious it’s an outside factor – your edge/perimeter firewalls.

Also to point out, when testing for port blocks, tools such as telnet is not a good tool to test AD/DC to DC connectivity, nor is any sort of standard port scan, such as using nmap, or a simple ping, resolving with nslookup (although resolving required records is a pre-requisite), or other tools. The only reliable test is using Microsoft’s PortQry, which tests specific AD ports and the ephemeral ports, and the required responses from the services on the required AD ports it specifically scans for.

AD through a NAT? Nope. Period.

Oh, and don’t expect to get this to work through a NAT. NATs cannot translate the encrypted RPC traffic therefore bonking LDAP communications.

Description of Support boundaries for Active Directory over NAT
http://support.microsoft.com/kb/978772

How to configure RPC dynamic port allocation to work with firewalls”
AD communications won’t work through a NAT port translation, such as you cannot use DCOM through a NAT firewall that performs address translation (e.g. where a client connects to virtual address 198.252.145.1, which the firewall maps transparently to the server’s actual internal IP address of, say, 192.100.81.101). This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it will not work.”
Quoted from: http://support.microsoft.com/kb/154596/en-us

Windows 2000 NAT Does Not Translate Netlogon Traffic (this applies to all DCs)
Quoted: “Windows 2000 NAT does not support Netlogon and translate Kerberos. If you have clients that are located behind a Windows 2000-based NAT server and need access to domain resources, consider creating a Routing and Remote Access virtual private network (VPN) tunnel for Netlogon traffic, or upgrade the clients to Windows 2000.”
Quoted from: http://support.microsoft.com/kb/263293

*

Ok, let’s find out if the ports are being blocked

Now you’re thinking that your network infrastructure engineers know what they’re doing and opened up the necessary ports, so you’re thinking, this can’t be the reason? or is it? Well, let’s find out. We can use PortQry to test it. And no, you don’t want to use ping, nslookup, nmap or any other port scanner, because they’re not designed to query the necessary AD ports to see if they are responding or not.

So let’s run PortQry:

First, download it:

       PortQryUI – GUI – Version 2.0 8/2/2004
       http://www.microsoft.com/download/en/details.aspx?id=24009

Then run the “Domains & Trusts” option between DCs, or between DCs and any machine (other servers you want to promote, or even from a client machine), or from the bridgeheads in each site to the other bridgehead in the other site., pretty much anywhere that you want to test if there are any blocked AD ports.

The point is, you’ll want to run it in any scenario where a DC must communicate to another DC or to a client.

If you get any errors with “NOTLISTENING,” 0x00000001, and 0x00000002, that means there is a port block. Take note on which ports they are.

You can ignore UDP 389 and UDP 88 messages. If you see TCP 42 errors, that just means WINS is not running on the target server.

PortQry References

Knock Knock Is That Port Open?
By Mark Morowczynski [MSFT] 18 Apr 2011, Quick tutorial about PortQry GUI version.
http://blogs.technet.com/b/markmoro/archive/2011/04/18/knock-knock-is-that-port-open.aspx

“At times you may see errors such as The RPC server is unavailable or There are no more endpoints available from the endpoint mapper …”
http://blogs.technet.com/b/askds/archive/2009/01/22/using-portqry-for-troubleshooting.aspx

How to use Portqry to troubleshoot Active Directory connectivity issues
http://support.microsoft.com/kb/816103

If you want to use the command line only version:

Download details: PortQry Command Line Only Port Scanner Version 2.0
http://www.microsoft.com/downloads/en/details.aspx?familyid=89811747-c74b-4638-a2d5-ac828bdc6983&displaylang=en

Understanding portqry and the command’s output: New features and functionality in PortQry version 2.0
http://support.microsoft.com/kb/832919

Description of the Portqry.exe command-line utility
http://support.microsoft.com/kb/310099

Portqry Remarks
http://technet.microsoft.com/en-us/library/cc759580(WS.10).aspx

*

DC to DC and DC to client communications Require Numerous ports

There’s no secret to this. That’s the simplest I can put it.

And, the list of ports required is long, to the dismay of network infrastructure engineering teams that must bequest ports to allow AD to communicate, replicate, etc., these ports must be opened. There really isn’t much that can be done otherwise.

Here’s the list with an explanation of each port:

Protocol and Port
AD and AD DS Usage Type of traffic 
TCP 25 Replication SMTP
TCP 42 If using WINS in a domain trust scenario offering NetBIOS resolution WINS
TCP 135 Replication RPC, EPM
TCP 137 NetBIOS Name resolution NetBIOS Name resolution
TCP 139 User and Computer Authentication, Replication DFSN, NetBIOS Session Service, NetLogon
TCP and UDP 389 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP
TCP 636 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP SSL
TCP 3268 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP GC
TCP 3269 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP GC SSL
TCP and UDP 88 User and Computer Authentication, Forest Level Trusts Kerberos
TCP and UDP 53 User and Computer Authentication, Name Resolution, Trusts DNS
TCP and UDP 445 Replication, User and Computer Authentication, Group Policy, Trusts SMB, CIFS, SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc
TCP 9389 AD DS Web Services SOAP
TCP 5722 File Replication RPC, DFSR (SYSVOL)
TCP and UDP 464 Replication, User and Computer Authentication, Trusts Kerberos change/set password
     
UDP 123 Windows Time, Trusts Windows Time
UDP 137  User and Computer Authentication NetLogon, NetBIOS Name Resolution
UDP 138 DFS, Group Policy, NetBIOS Netlogon, Browsing DFSN, NetLogon, NetBIOS Datagram Service
UDP 67 and UDP 2535 DHCP (Note: DHCP is not a core AD DS service but these ports may be necessary for other functions besides DHCP, such as WDS) DHCP, MADCAP, PXE

And We Must Never Forget the Ephemeral Ports!!

And most of all, the Ephemeral ports, or also known as the “service response ports,” that are required for communications. These ports are dynamically created for session responses for each client that establishes a session, (no matter what the ‘client’ may be), and not only to Windows, but to Linux and Unix as well.

See below in the references section to find out more on what ‘ephemeral’ means.are used only for that session. Once the session has dissolved, the ports are put back into the pool for reuse. This applies not only to Windows, but to Linux, Unix and other operating systems, as well. See below in the references section to find out more on what ‘ephemeral’ means.

The following chart shows what the ephemeral ports are depending on the OS version, and what they are used for.

Window 2003, Windows XP, and Windows 2000

TCP & UDP

1024-5000 Ephemeral Dynamic Service Response Ports
Windows 2008/Vista and newer TCP & UDP 49152-65535 Ephemeral Dynamic Service Response Ports
TCP Dynamic Ephemeral Replication, User and Computer Authentication, Group Policy, Trusts RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS
UDP Dynamic Ephemeral Group Policy DCOM, RPC, EPM

If the scenario is a Mixed-Mode NT4 & Active Directory scenario with NT4 BDCs, then the following must be opened:

TCP & UDP 1024 – 65535 NT4 BDC to Windows 2000 or newer Domain controller PDC-E communications RPC, LSA RPC, LDAP, LDAP SSL, LDAP GC, LDAP GC SSL, DNS, Kerberos, SMB

See, wasn’t that simple?

 

The Short list without port explanations:

Protocol Port
TCP 25
TCP 42
TCP 135
TCP 137
TCP 139
TCP and UDP 389
TCP 636
TCP 3268
TCP 3269
TCP and UDP 88
TCP and UDP 53
TCP and UDP 445
TCP 9389
TCP 5722
TCP and UDP 464
UDP 123
UDP 137
UDP 138
UDP 67
UDP 2535
TCP & UDP 1024-5000
TCP & UDP 49152-65535

If the scenario is a Mixed-Mode NT4 & Active Directory scenario with NT4 BDC:

The following Ephemeral ports must be opened (yes, it’s pretty much the whole range):

TCP & UDP 1024-65535

*

Restricting Ports Across a Firewall

You also have the ability to restrict DC to DC replication traffic, and DC to client communications, to a specific ports. Keep in mind, it also depends on what ports and services you’ll want to restrict. When choosing this option, you must specify the correct ports for the correct service.

It depends on what ports and services you want to restrict?

1. Method 1

This is to used to set the specific AD replication port. By default it uses dynamic port to replicate data from DC in one site to another.

This is applicable for restriction AD replication to a specific port range.

Procedure:  Modify registry to select a static port.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Restricting Active Directory replication traffic and client RPC traffic to a specific port
 http://support.microsoft.com/kb/224196

2. Method 2

This is for configuring the port range(s) in the Windows Firewall.

Netsh – use the following examples to set a starting port range, and number of ports after it to use

netsh int ipv4 set dynamicport tcp start=10000 num=1000
netsh int ipv4 set dynamicport udp start=10000 num=1000

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
http://support.microsoft.com/kb/929851

3. Modify the registry

This is for Windows services communications. It also affects AD communications.
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc

How to configure RPC dynamic port allocation to work with firewalls
 http://support.microsoft.com/kb/154596/en-us

Here are some related links to restricting AD replication ports.

Reference thread:
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/76e8654a-fbba-49af-b6d6-e8d9d127bf03/

RODC Firewall Port Requirements
http://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx

Active Directory Replication over Firewalls
http://technet.microsoft.com/en-us/library/bb727063.aspx

 

RODC – “Read only Domain Controllers” have their own port requirements

Traffic
Type of Traffic
UDP 53 DNS DNS
TCP 53 DNS DNS
TCP 135  RPC, EPM
TCP Static 53248  FRsRpc
TCP 389  LDAP

TCP and UDP Dynamic
1025 – 5000
Windows 2000, Windows 2003, Windows XP Ephemeral Ports
TCP and UDP Dynamic 49152 – 65535 Windows 2008, Windows Vista and all newer operating systems Ephemeral Ports

Designing RODCs in the Perimeter Network
http://technet.microsoft.com/en-us/library/dd728028(WS.10).aspx

Restricting Active Directory replication traffic and client RPC traffic to a specific port
http://support.microsoft.com/kb/224196

Good discussion on RODC and firewall ports required:
http://forums.techarena.in/active-directory/1303925.htm

Further info on how RODC authentication works will help understand the ports:
Understanding “Read Only Domain Controller” authentication
http://blogs.technet.com/b/askds/archive/2008/01/18/understanding-read-only-domain-controller-authentication.aspx

 

References

How to configure a firewall for domains and trusts
http://support.microsoft.com/kb/179442

Active Directory and Active Directory Domain Services Port Requirements, Updated: June 18, 2009 (includes updated new ephemeral ports for Windows Vista/2008 and newer). This also discusses RODC port requirements. You must also make sure the ephemeral ports are opened. They are:
   TCP & UDP 1025-5000
   TCP & UDP 49152-65535
http://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx

Windows 2008, 2008 R2, Vista and Windows 7 Ephemeral Port range has changed from the ports used by Windows 2003 Windows XP, and Windows 2000. Default ephemeral (Random service dynamic response ports) are UDP 1024 – 65535 (See KB179442 below), but for Vista and Windows 2008 it’s different. Their default start port range is UDP 49152 to UDP 65535 (see KB929851 below).

Quoted from KB929851 (link posted below): “To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections in Windows Vista and in Windows Server 2008. The new default start port is 49152, and the default end port is 65535. This is a change from the configuration of earlier versions of Microsoft Windows that used a default port range of 1025 through 5000.”

Windows Vista, Windows 7, Windows 2008 and Windows 2008 R2 Service Response Ports (ephemeral ports) have changed.
http://support.microsoft.com/?kbid=929851

Active Directory and Firewall Ports – I found it hard to find a definitive list on the internet for what ports needed opening for Active Directory to replication between Firewalls. …
http://geekswithblogs.net/TSCustomiser/archive/2007/05/09/112357.aspx

Active Directory Replication over Firewalls, Jan 31, 2006. (includes older pre-Windows Vista/2008 ephemeral ports)
http://technet.microsoft.com/en-us/library/bb727063.aspx

How Domains and Forests Work
Also shows a list of ports needed.
http://technet.microsoft.com/en-us/library/cc783351(v=ws.10).aspx

Paul Bergson’s Blog on AD Replication and Firewall Ports
http://www.pbbergs.com/windows/articles/FirewallReplication.html

 

Exchange DS Access ports

Configuring an Intranet Firewall for Exchange 2003, April 14, 2006.
Protocol ports required for the intranet firewall and ports required for Active Directory and Kerberos communications
http://technet.microsoft.com/en-us/library/bb125069.aspx

 

Additional Reading

Restricting Active Directory replication traffic and client RPC …Restricting Active Directory replication traffic and client RPC traffic to a … unique port, and you restart the Netlogon service on the domain controller. …
http://support.microsoft.com/kb/224196

How to restrict FRS replication traffic to a specific static port – How to restrict FRS replication traffic to a specific static port … Windows 2000-based domain controllers and servers use FRS to replicate system policy …
http://support.microsoft.com/kb/319553

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based or Windows Vista-based computers
This KB indicates Checkpoint firewalls having an issue with AD communications.
http://support.microsoft.com/?kbid=899148

 

 

Checkpoint Firewall and AD, DNS and RPC Communications and Replication traffic

Checkpoint firewalls have a known issue if you are running version R55 or older. You will need to make a registry entry to allows traffic to flow between the 2 sites via the vpn. The preferred solution is to upgrade the Checkpoint firewall.

More info:

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based or Windows Vista-based computers
(This link relates to and helps resolve the Checkpoint issue)
http://support.microsoft.com/?kbid=899148

Note from one poster on the internet with a Checkpoint firewall:
For Windows 2003 R2 and non-R2 remote domain controller we added the Server2003NegotiateDisable entry in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc

 

 

I know you’ve enjoyed reading this.

Well, whether you did or not, at least you now know what to do to make it work.

Comments, suggestions and corrections are welcomed!

==================================================================

Summary

I hope this helps!

Original Publication Date: 11/1/2011
Updated 11/4/2014

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

clip_image00262 clip_image00462 clip_image00662 clip_image00862 clip_image01062 clip_image01262 clip_image01462

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

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

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.”

DNS Duplicate zone - Scope Replication error - The Replication scope could not be set- The name limit for the local computer network adapter 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:
  • The data on each DC is different, and you are wondering why replication isn’t brining the zone data up to date, but it won’t because replication will either not occur or won’t occur if AD sees a duplicate.
  • 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.

    DNS Duplicate zone - Scope Replication error - The Replication scope could not be set- The name limit for the local computer network adapter was exceeded.

    *

    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 anIn 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!
  • Click Start, point to All Programs, point to Administrative Tools, and then click DNS.
  • In the console tree, right-click contoso.com, point to All Tasks, and then click Restart.
  • Change the zone back to AD Integrated into the Replication Scope it’s supposed to be in.
  • Once the duplicates have been deleted, once again, you MUST allow AD replication to occur. If you had changed the Replication Schedule on the Site Connection objects to quicken AD replication, you will want to reset them to their original setting.
  • *

    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!