MCITP 70-640: Active Directory Replication

Uploaded by itfreetraining on 15.04.2012

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.