Welcome to the next free video in the Active
Directory training course. In the last video I looked at how to create sites and subnets.
In this video I will look at how these sites can be configured to replicate Active Directory
traffic in an efficient way that matches the current state of your network.
First of all I will start with just the New York site. In this particular case let’s
say the New York site has 7 Domain Controllers in it. If a client were to login to the network,
they would be authenticated by one of the Domain Controllers. If the user then changed
their password and logged off and logged on a second time, they may be authenticated by
a different Domain Controller. For this reason you want replication within a site to happen
quickly. This type of replication is called intrasite
replication. Intrasite replication is replication that happens between Domain Controllers in
the one site. You will be happy to know that Active Directory handles this kind of replication
without any configuration. It does this by connecting all the Domain Controllers in that
site together in a ring. You can see that the 7 Domain Controllers are each connected
to two other Domain Controllers. This gives some redundancy and also reduces the number
of connections required in sites with a large number of Domain Controllers.
In Windows Server 2003 and above, intrasite replication will start 15 seconds after a
change has been made on a Domain Controller. With such a small delay, all Domain Controllers
on this network will receive the change in less than a minute.
If the number of Domain Controllers on this network were increased to 8, the delay for
a change to replicate to every Domain Controller starts to increase. Each Domain Controller
will wait 15 seconds before sending replication data to the next Domain Controller.
To reduce the delay, Active Directory will automatically create additional connections
between some of the Domain Controllers when you have 8 or more Domain Controllers in the
one site. This ensures that there are no more than 3 hops between one Domain Controller
in the site and any other Domain Controller. The extra connections ensure that changes
in the site are propagated to each Domain Controller in less than a minute. All these
connections are created automatically in Active Directory inside the site so you never need
to worry about configuring replication inside an individual site.
The next part of replication in Active Directory is between sites. This kind of replication
is called intersite replication. In this example consider the link between New York and Washington.
In order for these two sites to replicate changes between each other there must be a
site link connecting the two sites. This is not created automatically and needs to be
created by an administrator. In this example New York has 7 Domain Controllers
and Washington has 3 Domain Controllers. In order for replication to occur, Active Directory
will automatically pick a Domain Controller in each site to act as what is called a bridge
head server. The bridge head server in each site will replicate changes between the sites.
When a change is made on a Domain Controller, it will be replicated to all other Domain
Controllers in that site. When the change reaches the bridge head server, the bridge
head server is responsible for replicating that change to the other bridge head server
in the other site. This system is a lot more efficient than individual Domain Controllers
attempting to replicate changes to other sites. Active Directory will automatically choose
a Domain Controller in each site to act as a bridge head server for you. If that Domain
Controller is shut down or is no longer available, a new Domain Controller will be chosen. In
some cases you may have a particular Domain Controller or Domain Controllers that you
want to use as the bridge head server. Active Directory allows you to select a Domain Controller
or Domain Controllers to be the bridge head server for that site. These are called preferred
bridge head servers. Be warned however, if you choose your own bridge head servers and
these servers are not available, no replication will occur between the two sites until one
of those preferred bridge head servers comes back online.
Once you have a site link configured, you can configure some options on that site link.
The first option allows a schedule to be configured which will determine when replication will
occur. In some cases, companies may configure this replication to happen after business
hours. The next setting allows a cost to be configured
for that site link. The cost is a numerical value that is applied to a site link telling
Active Directory what priority these links should be used. To better understand how costs
work, let’s now consider what happens when the London Office is added to the network.
The London office is connected to the New York office by a direct link. In order for
replication to occur a site link is created between London and New York.
The link between London and New York is unreliable and at times will go down for hours at a time.
For this reason another link is established between Washington and London. This link is
more reliable but is charged according to how much traffic is transferred over it and
thus the company only wants to use this link when they have to.
In this example the London to New York site link and the New York to Washington site link
are given a cost of 40. The site link between Washington and London is given a cost of 100.
The cost of transferring data between sites is calculated by adding up the value of the
sites links. The route with the lowest cost will be used.
In order for data to go from Washington to London the lowest cost would be via New York.
Why? The Washington to New York site link and the New York to London site link add up
to a value of 80. This is lower than the cost of the link between Washington and London
which has a value of 100. If the link between London and New York was
to go down then the Washington to London link would now become the link with the lowest
cost. Traffic from New York to London would now travel over the Washington to London Site
link. If the link between New York and London were
to come back up, it would be seen once again as the route with the lowest cost and thus
the site link between Washington and London would no longer be used.
The last option to consider when creating a site link is which transport the site link
will use. The two options for this are RPC over IP and SMTP. RPC over IP is often referred
to as just IP and supports everything Active Directory needs. In the real world you are
more than likely only going to use the IP transport for Active Directory as it supports
everything. The second transport, SMTP, supports everything
except file replication services. At the domain level, file replication is used to replicate
the SysVol share containing all the login scripts and group policies. For this reason
you can’t have a functional domain infrastructure using just the SMTP transport. Items like
the login scripts and group policy would simply not be replicated between Domain Controllers
using only the SMTP transport protocol. Items like Active Directory changes can be replicated
using the SMTP transport as well as changes in the schema. For these reasons the SMTP
transport could be used between different domains in the forest. Using the SMTP transport
will not replicate everything at the domain level.
The fundamental difference between the SMTP and IP transport is that SMTP transport uses
asynchronous communication whereas IP uses synchronous. Asynchronous communication can
send replication information without the need to get a response back. If you have an unreliable
network a large block of SMTP information could be sent over the network without waiting
for the other side to confirm that it has received anything. IP in contrast uses synchronous
communication which means that it waits for a response each time data is sent. If no response
is received, it stops sending data. With network speeds getting better and more
reliable, in the real world I would just use the IP transport for your site links. In the
old days, the SMTP transport was used mainly for networks that were unreliable or not directly
routable using the IP protocol. Now days with the IP protocol being the default protocol
used in computing, there is unlikely to be a need to use the SMTP protocol on the vast
majority of production networks. Active Directory replication tends to be quite light on the
bandwidth as only changes are replicated and thus even on slow unreliable links I would
personally still give the IP transport a go before using the SMTP transport. For your
information, the choice of transport only applies to intersite site replication. Domain
Controllers in the same site are always replicated using the IP transport.
The last thing that I want to cover before I look at how to configure replication in
Windows Server 2008 is the Knowledge Consistency Checker or KCC. Once you configure your sites
and site links, the Knowledge Consistency Checker will automatically make connections
between the sites for you. If a network goes down between two sites, the KCC will automatically
reconfigure the connections between the sites to ensure that Active Directory replication
will happen. In our previous example, when the link between
New York and London went down, the KCC’s job was to create a connection between Washington
and London for replication to occur. The KCC does this in the background and does not need
to be configured. You can create your own connections in Active Directory as well, but
on most networks it is simpler and easier to allow the KCC to perform these steps for
you. The KCC also creates the connections that are used for intrasite replication and
determines which Domain Controllers will be used for Bridge Head Servers.
The KCC does this with information from the Active Directory database. If the same copy
of the Active directory database is in multiple locations the KCC will always come up with
the same result. If two different Domain Controllers have a different copy of the Active Directory
database, that is some changes have not yet replicated, the result the KCC comes up with
may be different. What this means is that on a network that
is replicating well all Domain Controllers given enough time will create the same links
between sites and their Domain Controllers. If you are finding that connections are not
being made between your Domain Controllers, check for replication errors in the event
viewer and also DNS related errors. Replication problems can stem from Domain Controllers
having difficulty resolving the IP address of other Domain Controllers.
I will now change to my Windows Server 2008 R2 Domain Controller to look at how to configure
replication. I have already created sites and subnets in
the previous video, so all that is left to be done is to create the site links for these
sites to replicate over. To do this, I will open Active Directory Sites and Services from
administrative tools under the start menu. To configure the sites links, I will expand
down to Inter Site Transports. There are two transports available under here, IP and SMTP.
When I open IP there is already a default site link called default site link. This is
created by default when Active Directory when it is first installed.
If you never create any additional site links in Active Directory all of your sites that
you create will be linked to each other using the default site link. When this occurs, the
Knowledge Consistency Checker will ensure that all your sites replicate with each other;
however, the replication may not be a good match for your network topology. Microsoft
recommends that you do not put more than 3 sites in the one site link.
First of all I will rename the default site link to New York to Washington. You are free
to rename the default site link or create a new site link and remove the default site
link or simply leave the default site link in Active Directory unused.
To match my network topology I need to create two more site links. To do this, I will right
click IP under inter site transports and select the option new site link. This site link I
will call New York to London. Once I enter in the name, I need to add the sites that
will use this site link, in this case London and New York.
In this case I will be adding only 2 sites to each site link; however, there is nothing
stopping you from adding more. As you will see in a minute, the Knowledge Consistency
Checker will determine which connections to create based on which sites are in the site
links. Finally I need to create one more site link
for my back up link from Washington to London. This is created the same way I created the
other site links. Once the site links are created, I need to configure them.
First of all I will open the properties for the New York to London site link. At the bottom
notice the cost value assigned to this site link is 100, the default value. I will change
this value to 40 so this site link will get preference over the backup site link that
I just created. Under this is how often replication will occur
over this site link. The default is 180 minutes or every 3 hours. This setting can be as low
as 15 minutes. At the bottom is a button to change the replication
schedule. When I press this I can select the times that Active Directory replication will
occur and can also configure it to be disabled at certain times. For example, I could disable
replication if I wanted to do for Monday through Friday during business hours.
Now that I have finished configuring this site link, I will exit out of here and open
the properties for the New York to Washington site link. Since this site link was originally
the default site link, all 3 sites are in here so I will remove the London site since
it is no longer required in this site link. I will also change the replication cost to
40 so this site link is favoured over the backup site link from Washington to London.
Now my 3 site links are created. The Washington to London site link I will leave on the default
cost of 100. It will only be used if one of the other site links is not available. By
default, the Knowledge Consistency Checker will create links that connects sites together
that are connected by other sites. For example, since New York is in two different site links,
the Knowledge Consistency Checker knows that Washington can reach London via New York.
The Knowledge Consistency Checker will do this automatically but if your own site link
bridges, you can select the option new site link bridges. By default site link bridges
will be created automatically and creating a manual bridge will be ignored anyway unless
you disable automatic site bridging. When I open the properties of the IP transport,
you will notice the tickbox to ignore schedules. This is a quick and easy way to override any
schedules that have been configured. Under this is a tick box for bridge all site links.
If you deselect this, you will need to manually create all the site links bridges between
your sites. Unless you have a good reason for doing this I would leave this option ticked.
It is generally easier to allow the Knowledge Consistency Checker to work out the site link
bridges from your site links. If you have configured them correctly it should make some
good choices for these site link bridges. When I right click on the SMTP transport,
you will notice that I have the same options as IP. Given the choice of transports I would
always use the IP transport where possible, but on some networks you may see the SMTP
transport used. Configuring of the SMTP transport is the same as the IP transport the only difference
is the functionality that it supports is different. For this reason I won’t configure any SMTP
transports. If I now expand down to NY DC 1 and open the
properties for the server, on the general tab I can see which transports this server
will use. By default IP and SMTP will both be enabled so the Knowledge Consistency Checker
will create both types of connection where required. In this case I have not created
a transport for SMTP and assigned any sites to it. Until I perform this step the Knowledge
Consistency Checker will not create any SMTP connections.
By default the Knowledge Consistency Checker runs every 15 minutes so I will pause the
video and return later to allow it some time to run.
Now that the Knowledge Consistency Checker has had some time to run, I will expand down
until I see NTDS settings which contains the settings for this server. When I open the
properties for the NTDS settings and go to the connections tab, you can see all the incoming
and outgoing connections from this server. All of these are created automatically by
the Knowledge Consistency Checker. When I exit out of the properties, you will
notice here that I can see a list of all the incoming connections. On the left hand side,
notice that these are automatically generated. These are created by the Knowledge Consistency
Checker and assuming that everything else is configured correctly, that is your sites,
subnets, site links and transports, these should be created automatically for you.
When I right click the NDTS settings, notice the option new Active Directory Domain Services
connection. Selecting this option allows me to create a manual connection between two
Domain Controllers. Once this connection is created this will appear with the other connections.
On most networks there should not be a need to create a manual connection as the Knowledge
Consistency Checker will create the required connection automatically.
If you do find that a connection is missing and do not want to wait for the Knowledge
Consistency Checker to run again, right click NTDS settings, select all tasks and then select
the option check replication topology. This option will force the Knowledge Consistency
Checker to run. Windows will give you a confirmation dialog telling you that the Knowledge Consistency
Checker was run and you may need to refresh the screen.
Looking at the connections, notice that a connection was made to London. This means
the knowledge consistency checker has decided to make this server a bridge head server.
If you want to force a replication, right click the connection and select replicate
now. You should not need to force a replication to another Domain Controller in the same site
as the replication should happen very quickly. Notice that forcing a replication will give
me a confirmation dialog telling me that the replication was successful. This is a fast
way of testing the replication in your Active Directory environment to ensure that it is
working correctly. To better understand the connections that
the Knowledge Consistency Checker has created, I will show a graphical view of the connections
on the screen as I go through them. Next notice the two connections that have been made to
NY DC 6 and NY DC 7. Remember the connections shown here are incoming connections originating
from the other Domain Controller. Outgoing connections from this Domain Controller are
not shown here. If I expand down to the next Domain Controller,
two connections have also being automatically created. Expanding into NY DC 3 shows another
two connections; however, notice that there is now a connection traveling in both directions
from NY DC 2 to NY DC 3. It is important to remember that the direction of the connection
does not determine which way replication occurs. The direction only refers to who created the
connection. Like the telephone, one party needs to call the other party to create the
connection but once done, both parties are free to talk to the other.
Expanding into NY DC4 shows another 2 connections. Expanding into NY DC5 shows that 3 connections
have been created. One of the connections is to Washington. This Domain Controller has
been selected as a bridge head server. This goes to show that multiple bridge head servers
can be selected in the same site. The important thing to remember is that only one bridge
head server is responsible for all replication to each remote site.
If I expand into the connection for NY DC 6 and then NY DC 7, notice that this now completes
a ring for the connections. Each Domain Controller has two connections forming a ring going into
each direction. This allows replication to occur inside the one site even if one Domain
Controller were to fail. Replication to the Washington and London site will go through
the one exit point respectively. If a Domain Controller was to become unavailable for a
long enough period the knowledge consistency checker would delete and add connections as
required. The process does take longer than the 15 minutes as the Knowledge Consistency
Checker does not remove connections immediately when it runs. This is done to account for
Domain Controllers being taken off line for a short period of time for maintenance or
small network outages. Microsoft also provides a command line tool
called RepAdmin which can be used to perform some of the tasks I performed in the gui.
If I open a command prompt and run the command RepAdmin slash KCC, this will force the Knowledge
Consistency Checker to run. In this case it will run only on this Domain Controller, but
if I add the parameter site colon site name, this will force the Knowledge Consistency
Checker to run on all Domain Controllers in that site.
If you want to force a replication to occur, you can run RepAdmin slash SyncAll. There
are other parameters as well with this command, but the last one I will look at is Bridge
heads. This will show all Domain Controllers working as bridge head servers in your Active
Directory environment. Well that’s everything you need to know
about sites and Active Directory replication. In the next video I will look at user accounts
in Active Directory. Thanks for watching another free video from IT Free Training. Please consider
subscribing to us on YouTube to get notified when we release new videos.
