Active Directory Replication Design

Posted on

Active Directory Replication Design – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, active-directory, windows-server-2012, windows-server-2012-r2, .

Primer/Environment:

  • Sites: Santa Clara (data center), San Francisco (office), Seattle
    (office), Boston (office)
  • Two Domain Controllers at each site.
  • All sites are able to talk to San Francisco but not each other.
  • No other services are shared/provided to the sites.
  • Only AD/LDAP authentication
  • IP subnets are assigned in AD Sites and Services
  • Default-First-Site is used in San Francisco

Problem:

When a new DC comes up it creates an Connection to a Site/DC that it cannot actually talk to. For example: A new DC in San Jose, lets call it SJC-DC02 has a Connection to a DC in Seattle, SEA-01 BUT it cannot actually connect to SEA-01. It can only (by design) talk to SFO-DC01 and SFO-DC02. I am having to manually create the connections from SJC-DC02 to SFO-DC01 and SFO-DC02.

Question 1:

How do I get rid of these “automatically generated” Connections once and for all? (They come back if you just simply delete them)

Question 2:

Remind me, should all Connections be bidirectional? Example: SJC-DC02 to SFO-DC01 and SFO-DC02 as well as SFO-DC01 to SJC-DC02 and SFO-DC02 to SJC-DC02

Solution :

I’ll start w/ an assumption: I’m assuming, based on your bullet points, that you’ve created Site and Subnet objects in Active Directory (AD) that represent your physical locations and subnets. If you haven’t that’s the first thing you need to do.

You really should be allowing AD to create replication connections automatically. I understand why you’ve been overriding it, but fortunately Microsoft has already accounted for the scenario you have. Making a configuration change should cause it to work properly with automatically-generated connections.

By default, AD assumes transitive network connectivity across your entire enterprise. That is to say it considers inter-site links to be “bridged”.

Your situation, however, causes that assumption to be invalid. Disabling the “Bridge all site links” option will cause AD to create a replication topology that assumes network connectivity only between directly-adjacent sites.

If you’re patient you can make this change at the “hub” site and wait for AD to replicate the change. You can also force the replication. Once the copies of AD in the other sites have received the change you can delete your manually-created connection objects and force the Knowledge Consistency Checker (KCC) to recalculate the replication topology (with the “Check Replication Topology” function). You should see AD automatically build a replication topology that meets your requirements.

If you end up with partial transitive network connectivity in your network later you can always use the “Site Link Bridge” functionality to inform AD of this partial transitivity. If you continue to have intransitive connectivity, however, you don’t need to worry about this.

To answer your second question:

The replication connections are one-way. If you continue manually creating them you will need to be sure that you have a replication connection for each partition of the directory “pointed” in both directions from each site.

I do think you should try getting automatic topology generation working, though. You’ll be pleased with it once it’s working properly.

This is what is commonly called a “hub and spoke” topology; you should tell Active Directory how it looks like, and then AD itself will take care of setting up replication conections accordingly.

In order for this to work, you need to define multiple sites:

  • Create an Active Directory site for each city.
  • Map the local IP subnet(s) to each site.
  • Define site links between each site and San Francisco.
  • Place already existing domain controllers in their respective sites.

When you add a new DC to the domain, it will detect the site it belongs to (based on its IP subnet) and it will automatically define its replication connections in the most appropriate way, i.e. to other domanin controllers in the same site and/or to domain controllers in the San Francisco central site.

Leave a Reply

Your email address will not be published.