Now let's turn our attention from trust relationships to
configuring sites and services with Active Directory.
Remember from the previous module I said that Active
Directory has logical and physical components.
Sites and subnets are examples, and domain controllers, for that
matter, are example of physical manifestations of Active Directory.
I mean, your business has physical campus locations. In this
example, company.pri has Denver,
Las Vegas, and Phoenix, and so we can model the
physical topology of our environment here.
Now, when you have multiple regions in your business,
does that mean by definition you need multiple domains?
No, not necessarily.
Does it mean that you need multiple forests again?
Absolutely not.
I just want to repeat that with network bandwidth being so plentiful
nowadays and with Active Directory being able to scale into the billions
of objects, you really should consider, if you already are sprawling in
your Active Directory forest structure,
begin the process of consolidating as much as you possibly can.
In this example, we've got within a single domain three geographical locations.
Now,
admittedly, these three locations aren't on opposite sides of the
world. There, you might want to consider going beyond one domain,
because we have to think in terms of those domain controllers in each
domain. You'll want to deploy at least two in each physical location
for high availability purposes.
And, as I said,
the idea of Active Directory replication is within a domain, those domain
controllers are communicating all the time, every 3 minutes I think it is,
they're looking to update and synchronize their Active Directory databases,
and then there's the SYS file contents as well.
So, sure, if you've got one location in Denver and the
states and another in Melbourne, Australia,
then you certainly, even with the Internet being as strong as it possibly is,
you're going to at least want to do multiple sites, if not
consider multiple domains, because, again,
within a single domain,
those domain controllers want to communicate all the time.
That having been said,
the benefit of setting up sites and subnets in Active Directory allows
you to inform Active Directory of the IP ranges of each of your domain
controllers and your physical sites.
And this means that when client devices attempt
authentication based on the client's IP address,
they will be directed to their site where they will have, presumably, the
lowest latency connection to their local domain controllers.
And by allowing Active Directory components to build
that replication link topology,
you can then adjust the default interval if you find that the domain
controllers are still being too chatty over your site links. You can actually
build your own site links, but the general practice nowadays is to let Active
Directory determine those site links itself.
There's two components to Active Directory replication. There's
the Knowledge Consistency Checker, which determines least paths
between sites and determines your site link structure, and the
intersite topology generator,
or ISTG, and that's the component in Active Directory that nominates a
server in each site for each domain to serve as a bridgehead. Because it's
not like every domain controller in a site is sending replication updates
or requesting updates, more particularly, from remote sites, it's just a
designated bridgehead in each site that's responsible for that polling and
update process.
And, once again,
the ISTG dynamically determines the best bridgehead server and the KCC
dynamically determines the best site link infrastructure. That's the best practice now in 2021, 2022. Don't mess with success.