Let's look at configuring and managing AD DS replication.
First, we recall that in Windows Server,
a domain controller is a specialized post that contains the Active Directory
database. And I had mentioned that AD DS consists of a number of partitions, and
these partitions are scoped differently in terms of the replication partners.
The configuration partition is forest‑wide,
so this partition is going to contain references to the overall
structure of the forest. You may have just a single forest,
single domain, or within your forest,
you may have a domain tree or multiple domain trees.
All of that metadata is in the configuration
partition, and hopefully it makes sense.
You want that to replicate to all domain controllers
across all domains in the forest.
The schema partition is also forest‑wide. This tracks all
of the objects and their attributes.
Again,
this is critical. If you extend the Active Directory schema in your forest,
you want all DCs across all domains in that forest to be aware of that update
as soon as possible. Within each domain, we have the domain partition, and
this partition is domain‑specific. It contracts all of your domain user group
and organizational unit information.
And so this isn't as necessary to have in all domains. It's just each domain,
this is its working partition. Then we have the application partition.
This is going to be used for two different purposes.
One, administrators can create their own custom application
directory partitions where you can have line of business data and
then control the domain controller scope, in other words, within a
domain or across the entire forest on how you want to spread that
application partition data.
Now, when you're doing Active Directory‑integrated DNS,
which I certainly hope you are, the AD integration happens by means
of two special purpose application partitions.
There's forestDnsZones that replicates your DNS forest‑wide and
domainDnsZones, and you can control the scope. Again, in a forest where
you're just using the default trust relationships among domain trees
and within parent and child domains,
it would make sense that you would replicate those zones forest‑wide,
but you can control that as an administrator.
There's the two partitions, as you can see on the slide.
Now let's look at some fun facts with Active Directory replication.
As I mentioned,
the Knowledge Consistency Checker is the component or process
that dynamically builds connection objects between the sites
that you define as an administrator.
The default intra‑site replication interval is 15 seconds.
That means, within a site, it's assumed that all
domain controllers have high speed,
low‑latency connectivity, so they can update basically whenever they
want to. Between sites, remember, the reason why you define separate
sites is so that you can put more control, and context, and bounds on
that replication traffic. The default inter‑site replication interval
is 180 minutes, or 3 hours.
A site link is defined as a transitive logical connection
between sites and their bridgehead servers.
The idea with the site link,
particularly the site link and connection objects that are
built dynamically by the KCC, is that full inter‑site
connectivity is assumed. In other words,
you have a fully routed network.
If your network environment is not fully routed,
you may have to go to manually creating site links and site link bridge objects.
A site link bridge is an administrator‑defined connection between domain
controllers and sites that don't have direct connectivity.
The old Windows Server 2003 and 2008 exams used to get into the
weeds on site links and site link bridge.
That shouldn't be an issue anymore with AZ‑800 and
803 because dollars to donuts,
you have full routing connectivity among all of your sites.
What are some common Active Directory replication troubleshooting
tools? Well, some that have been around since the beginning are old
compiled command line tools like Repadmin. This is a great Swiss Army
Knife to diagnose replication issues.
There's also Dcdiag, which can look at replication, as well as Active
Directory DNS, your FSMO roles, site connectivity.
Those are great. Nowadays though,
we're pretty much standardized on PowerShell. There's at least three
PowerShell commands in the Active Directory module that you should be
aware of. Get‑ADReplicationConnection.
In fact, all three of these are gets, so you're basically
just getting data back in a report.
Show me the replication connection,
show me replication failures. You can run
Get‑ADReplicationPartnerMetadata against a particular
server to see what its replication partner is, what your bridgeheads are, this sort of stuff.