Recently, I received an email from an administrator asking for help with an issue concerning Active Directory replication configuration. It was such an interesting case that I decided to share it in this article to benefit others who might face this situation. The admin (I'll call him Jack) said he was writing in response to an article I'd written some time ago, in which I detailed a failed Active Directory replication design where multiple sites were put in single site links.
That article stated that putting multiple sites in a single site link was permissible for the core site link, housing sites that form the hub of the AD replication topology. Jack said he wanted to use that strategy to permit his four domain controllers in four core sites to achieve convergence within (hopefully) one Active Directory replication cycle.
The configuration was pretty simple. He had four core sites (each with a single DC) and about 45 remote sites (all without a DC). In order to get quick Active Directory replication convergence, he had experimented with creating a ring of four sites with a full mesh of site links, with each site replicating with the other three, shown in Figure 1. He felt that this would provide instantaneous replication to all sites when changes were made at any one of them -- but unfortunately it didn't work.
Next, he attempted to put all sites in a single site link. When he contacted Microsoft, the company said it did not recommend more than three sites per link, since more than that would produce unpredictable results. I told him that Microsoft's concern was exactly what my previously article stated, but putting several sites into a single site link probably wouldn't generate any problems. After all, with one site, there isn't any intersite replication (only intrasite). The case study in my article had a failed design because they had multiple site links, each with more than two sites in them.
Remember that Jack's goal was to get as close to instantaneous replication as possible. We had seen that the flexibility of intersite replication really didn't allow us to accomplish that goal. So we considered intrasite replication, which would be achieved by putting all four DCs in a single site.
A look at intrasite Active Directory replication interesting
Consider these note-worthy intrasite replication features:
- No data compression -- This improves replication performance since there is no compression/decompression, but the network will take a hit. With adequate bandwidth, this can be a good thing.
- More frequent replication
- Urgent Replication for LSA secrets, RID pool changes and account lockout notification -- This means that there is a lot more chatter than there would be if the DCs were in separate sites.
- Not possible to schedule or cost replication -- So we lose a bit of control here. This can be a negative with the DCs connected by a WAN rather than a LAN.
In general, putting DCs that are in different physical locations on the WAN into a single site will put a heavier load on the network, but today's high-speed/high-performance networks can likely handle it.
In the design of Compaq's Windows 2000 Active Directory, they determined that when combining multiple physical locations to a single site, they needed at least a 2 megabits per second (Mbps) link. That's barely over a T1 link. Compaq was able to reduce more than 800 locations to about 80 Active Directory sites, so using intrasite replication in this manner really does work.
Currently, Hewlett-Packard has a Windows Server 2003 test forest that sits on the corporate network. We have seven domain controllers located in Atlanta, California, England, Ireland, Boston, Holland and Houston. They are all in a single site and site link. To test the latency, I deleted a user object, then I used the Repadmin command to see how fast the replication got around.
Using the following command allows us to see which DCs still have the user object "Joe":
repadmin /showobjmeta * "cn=joe,ou=people,dc=corp,dc=net"
The " * " option will search every domain controller for the object specified. On the DCs where the object exists, you'll get a dump of the attributes. On DCs where it has been deleted, you get an error. When you get errors from all DCs, replication has completed.
I did this on our test forest. I had the command ready so as soon as the object was deleted, I hit "Enter" on the Repadmin command. Even at that, replication was so fast, all DCs reported the object deleted. Granted HP has a very high-speed network, but we have DCs all over the globe, so it's impressive that it would happen that fast. The point of course is that with a fast network, putting all sites in a single site link can provide very impressive replication performance.
If you put the domain controllers in separate sites and then put them in a single site link and enable change notification (also referred to as urgent replication) between sites, there would be at most two hops for convergence, which is the same as if there were four DCs in a ring topology of a single site.
Note: With multiple DCs in a single site, the Knowledge Consistency Checker (KCC) will form them in a ring for replication. Thus, there is no advantage to putting DCs in multiple sites and then putting the sites in a single site link.
M anaging intrasite replication is very simple because there is nothing to manage. Interestingly enough, as we have seen here, intrasite replication is not only the easiest to manage, but is also the most efficient for Active Directory replication in the situation described in this article.
In the end, the solution was to collect all DCs into a single site and use intrasite replication. While you can't guarantee that all changes on any domain controller will replicate in a single cycle, it will replicate fast enough.
Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at [email protected]. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.