Welcome back with episode 3 of series: Manage Sites and Active Directory Replication, you guys!
According to part 2, we understand the key that participates in the sync/replication process: Global Catalog; a genius feature can be used in conjunction with Sites (on GC server): Universal Group Membership Caching to power its design; how DNS can help enforce Site's theory, and the actual data are being distributed/synchronized: directory partitions of the LDAP database.
Wait for part 3 of Manage Sites and Active Directory Replication to configure the replication through ADSS and see it in action.
I want you to know that, by implementing Sites, you are in the right way to maximize your domain infrastructure, because from now; it will work automatically by default.
[00:11] Remember that, network infrastructures are variable, so, you should find your domain has its own specific requirements: traffic timeline, connection priorities, structure designs, etc.
That's why Windows Server of Microsoft give us options to customize the Site design, one of them is the Connection Object.
Connection Objects act as intermediaries between domain controllers with abilities to changing schedules of communications, priority them by "Cost" options, etc.
[00:16] Before you start, let's contemplate Active Directory replication concepts: connection objects, site links, bridgehead server, intersite, etc.
Basically, for replication to occur between two domain controllers, the server object of one must have a connection object (CO) that represents inbound replication from the other.
Though COs will be generated automatically by KCC, however, users can manually create connection objects to customize the network`s topology or decrease the number of hops from one domain controller to another particular domain controller.
I have 2 Sites taken place; we can create a connection object between servers of them (SNOOPY-SERVER, SNOOPY-SERVER-2) by using "New Active Directory Domain Services Connection" from NTDS Settings of the Servers section.
[00:43] Give this connection object a name to identify it for further customizations in replications.
Check this tutorial for step-by-step instructions:
Now, switch to a greater concept (site-to-site rather than DC-to-DC), the Link:
a site link object represents a set of sites that can communicate at uniform cost through a specified intersite transport.
It's kind of grouping so that DCs of sites in the same Link can replicate directory changes with each other.
[01:19] We must name Links and optionally, write down its description to serve management purposes later.
[01:42] Create the HQ-BRANCHA-2 site link with default options about Cost and Replication Interval so that KCC can reference later and generates connection objects among these selected Sites.
According to Microsoft TechNet: "When two sites are connected by a site link, the replication system automatically creates connections between specific domain controllers in each site that are called bridgehead servers. All domain controllers in a site that host the same directory partition are candidates for being selected as bridgehead servers by KCC."
The Knowledge Consistency Checker (KCC) could possibly not designate a bridgehead server that is the most optimal domain controller in a site. In cases like this, manually designate a preferred bridgehead server(s) to improve performance.
Add the IP Transport to a preferred list of this server.
(SMTP replication will not be supported in future versions of AD DS; therefore, creating site link objects within the SMTP container is not recommended.)
We are dividing our domain into Sites to indicate geographic locations, then connect/group them with Links; so that, at least, in this case, a Link represents a WAN connection that has low-bandwidth, high-latency characteristics (compare to the local LAN connection).
We should tweak default settings of Links to suit basis of our network environment, physical location, and business needs.
[02:36] You can indicate a Link is a slow one (low-speed, dial-up connections) by specifying a high-Cost number, so that, our backbone Links, which have lower Cost can have priorities to be used.
Furthermore, you can control topology by setting the costs on-site links.
A schedule that determines during what time periods the link is available for replication. For example, you might schedule a site link for a dial-up line to be ready during off hours (when telephone rates are low) and unavailable during high-cost regular business hours.
[02:58] Mark these timeline blocks as blues to make it happen; the white one is a blocker.
Finally, enter a Replicate interval value (a multiple of 15) for this Link to specify how often replication can occur during Schedule time.
In conjunction with Cost and Schedule, you should find how easy it is to control the topology and timeline of our Site replication!
[03:42] I'm sure that you have knowledge about Site's roles in our Active Directory domain network as well as usages/relationships of its entities: Links, COs, GC, UGMC, etc. that can help us deploy on every kind of network topology.
Remember that, Sites work automatically by default, so this part 3 is only recommended to admins who know it best, misunderstands can destroy the theory of Sites dramatically.
Claim your confident with this advanced guide:
Just make sure you already read my explanations and included links about best-practices, notes, step-by-step guides.
There are a bunch of Active Directory's awesome things on my channel are waiting for you :3