Let's listen we'll talk about how aid is replication works within a site.
We'll talk about connection objects the knowledge consistency checker notification and polling.
These are the concepts relating to internal site replication so into a site replication is a tedious
replication within a single site that the cures automatically.
However you also can configure it to cure manually if application in your environment require a more
specific replication schedule.
As I have mentioned the concepts relating to interim site applications are connection objects.
The knowledge consistency checker notification and Pauline first connection objects a domain controller
that replicates changes from another domain controller is called a replication partner connection objects
link application partners a connection object represents a replication path from one domain controller
to another connection objects are one way representing inbound totally bool replication to view and
configure connection objects.
You have to open active directory sites and services and then select A.D. as certain container of a
domain controller server object.
You can force replication between two domain controllers by right clicking the connection object and
then select and replicate.
Now note that replication is inbound only so if you want to replicate both domain controllers you need
to replicate the inbound connection object of each domain controller.
No the knowledge consistency checker the replication pass that connection objects built between domain
controllers create the forests replication topology you do not have to create the replication topology
manually by default the s create at apology that ensures effective replication the topology is two way.
Which means that even the main controller fails replication continues uninterrupted.
The topology also ensures that no more than three network cops a cure between and it domain controllers
on each domain controller a component of a deed is called The Knowledge consistency checker helps generate
and optimize the replication automatically between domain controllers within aside the knowledge consistency
checker evaluates the domain controller as an aside and then creates connection objects to build the
two way 3 Hope topology that was described earlier if you add or remove a domain controller or if a
domain controller is not responsive.
The knowledge consistency checker rearranges the topology dynamically adding and deleting connection
objects to rebuilt an effective replication topology the knowledge consistency checker runs at intervals
that you specify and runs every 15 minutes by default it designates a replication roads between domain
controllers that are the most favorable connections available at the time you can create connection
objects manually to specify a replication path that should persist however create and a connection object
manner that typically is not required nor it is recommended because the knowledge consistency checker
does not verify or use the manual connection object for fe lower their knowledge consistency checker
also will not remove manual connection objects which means that you must remember to delete connection
objects that you create manually.
The next concept of intercept replication is notification.
So when a change occurs eurozone an active directory of partition on a domain controller the domain
controller use the change for replication to its partners by default the source server waste waits 15
seconds to notify its first group location partner of the change notification is a process by which
an upstream partner informs its downstream partners that a change is available.
By default the source domain controller then waits three seconds between notifications to additional
partners these delays or the initial notification delay and the subsequent notification delay Star or
the network traffic that entire site replication can cause.
After receiving the notification the downstream partner requests the changes from the source domain
controller and the director or replication agent pulls the changes from the source domain controller.
For example supposed domain controller DC 1 initiates a change to a tedious when DC to receive the change
from DC 1.
It makes the change to its director DC to learn to use the change for application to its own downstream
partners.
Next suppose this is 3 is a downstream replication partner of DC 2.
After 15 seconds the city notifies DS 3 that it has a change DC 3 makes the replicator change to its
director and then notifies its downstream partner.
The change has made two hops from DC one to this two and then from DC 2 to DC 3.
The replication topology ensures that no more than three hops a cure before all domain controllers in
the site receive the change at approximately 15 seconds or hope the change fully replicates in the site
within one minute and the last concept of interim site replication is bawling.
Sometimes a domain controller might not make any changes to its replicas for an extended time particular
or duration of hours.
Suppose this is the case with DC 1.
This means that DC to its downstream replication partner will not receive notifications from DC one
DC one also might be off line which would prevent it from sending notifications to DC 2.
It's important for DC to to know that its upstream partner is on line and simply doesn't have any changes.
This week yours through a process called Poland during Poland.
The downstream replication partner contacts the upstream replication partner with Waris as to whether
any changes are queued for replication.
By default the Poland interval for in drug site replication is once per hour.
You can configure the Poland frequency from a connection object properties by clicking change schedule.
Although it's not recommended even upstream partner fails to respond to repeated Poland whereas the
downstream in the Downstream partner launches the knowledge consistency checker to check the replication
topology.
Even the upstream Sora is indeed off line their knowledge consistency checker rearranges the site's
replication topology to accommodate the change.
Now I'd like to recap this lesson as there are lots of figures here and important time information.
But before the recap I'd like you to answer the following question please describe the circumstances
that result when you create a connection object manually between the main controllers within a site.
Press pause here and think about the answer on this question and the answer is it's not recommended
that you create a connection object manually nor is it required typically because the knowledge consistency
checker does not verified or use the manual connection object for fail over the knowledge consistency
checker also does not remove manual connection objects which means that you must remember to delete
connection objects that you create manually.
Now in this lesson we've discussed the role of knowledge consistency checker in grade and connection
objects to create an efficient three hope maximum and robust two way topology.
I'd like to emphasize that there are few reasons to create connection objects manually within a site.
In fact administrators have very few options by which they can modify the replication topology within
a site.
I'd like to mention that within a single site the replication goal is to update all domain controllers
as quickly as possible.
However when I change a Eurozone a domain controller the domain controller waits as long as 15 seconds
to notify its partners of the change.
This increases the efficiency of replication.
If additional changes occur you're on the partition.
I'd like to point out that with a maximum of 15 seconds.
This means that on average changes replicate every 7 dot 5 seconds a maximum of 3 hopes means that within
45 seconds or an average of 20 2.5 seconds the entire society is updated with a change.
Also I'd like to point out that all partitions that replicate between two domain controllers on a connection
object replicate simultaneously.
There is no way to time the partition differently.
The replication traffic is not compressed because it is assumed that all domain controllers in the same
side will be connected with a fast network connection with abundant available bandwidth.