Replication 2

Offline Domain Controllers

Some companies decide to keep a spare domain controller off the network as a last resort backup, in case all of their active domain controllers somehow become corrupted or fail in some fashion. Some companies also ship new domain controllers to new branch offices, and unforeseen circumstances keep the domain controller offline for longer than intended. Unfortunately keeping an offline domain controller can cause deleted objects to return from dead, here's what happens a domain controller is taken offline, obviously it is no longer replicating with the other domain controllers an AD object is deleted by an administrator. This causes the object to be tombstone for 60 days if the offline domain controller is returned to the network the results will depend on exactly when it is returned.

If the domain controller is returned within the tombstone lifetime, then the domain controller will replicate the tombstone and the object will not reappear. If the domain controller is returned after the tombstone lifetime, than the formerly offline domain controller will have a copy of an object that doesn’t exist on other domain controllers. Thus most of the domains domain controllers don’t have the object, which means they don’t have a USN for it. Any USN is better than none so the formerly offline domain controller will replicate the object within AD and all other domain controllers will be happy to accept it. The object reappears.

How replications occur between domain controllers?

Replication tracking:

Tracking changes and determining which objects need to be replicated are done using a combination of several methods.

ü  Update sequence numbers (USNs)

ü  TimeStamp

What is Intrasite and Intersite Replication?

Intrasite is the replication within the same site and

Intersite is the replication between the sites.

Intrasite replication

Intrasite replication takes place between domain controllers in the same domain and in the same site, the knowledge consistency checker (KCC) uses an algorithmic process to map the logical pre-existing network topology between the domain controllers, and determines when they should replicate and with whom they should replicate.

The guiding principles involved is the Rule of 3, which states that no single domain controller should be more than three net work hops away from an originating domain controller.

 This topology is fully automated and does not require administrator information.

A site containing more than one subnet requires the KCC to determine which domain controllers belong in each site.

The subnet mask identifies which domain controllers are located logically closet to each other, providing the KCC with the necessary information to determine replication partners.

The KCC is a service that runs on domain controllers as part of the local security authority (LSA) service. It cannot be deactivated or removed.

The connections created between domain controllers by the KCC are named Connection Objects

The connection objects function as one way path with in a site.

Viewing connection objects:

Active directory sites and services

Expand the sites, folders, the desired sites and the server’s folders.

Expand the server name for which you wish to view connection objects and right click and NTDS settings and select properties,

Select the connection tab and note the replication partners.

The KCC runs every 15 minutes and analyzes the best path and placement for “connection objects”                

If a domain controller or a link between domain controllers has failed, the KCC automatically updates the Topology, removing this connection from the list of possible replication paths.

By default, Intrasite replication is configured to minimize latency to allow changes to take place quickly.

The KCC will works at ring topology. If one domain fail automatically redirect opposite direction.       

As the site grows, additional connection objects are created to ensure that no more than three hops. For replication exist between domain controllers.

Intrasite replication traffic is not compressed.

Each domain controller will hold a changed for five minutes before forwarding it.

Since the maximum number of hops between domain controllers are three.

The maximum replication latency for changes to reach their final destination is 15 minutes.

Intersite Replication

If all active directory information was replicated only within a site, there would be no way to share object information in the global network.

One domain controller within each site runs the Intersite Topology Generator (ISTG) process. ISTG is a derivative of the KCC and is responsible for selecting a bridgehead server and mapping the topology to be used for replication between sites.

Administratively created site links have the following characteristics.

ü  There must be two or more sites that need to communicate using the

 Same Protocol.

ü  The site link objects are manually defined.

ü  The site link objects correspond to the WAN links connecting the sites.

ü  The ISTG uses the site links to establish replication between locations.

ü  Intersite replication can be configured to compress the replication information to assist in minimizing the link utilization.

ü  When the site link objects are created they require three attributes to be configured to allow administrator to control replication

Ø  COST

Ø  Schedule

Ø  Frequency

COST

Cost assignments will determine which path is chosen first. A lower numbered cost value represents a preferred path over a higher numbered cost value; cost value can use a value of 1 to 99,999.

The default cost value is 100.

Frequency

Frequency provides the how often information regarding the replication schedule. Replication will take place only during scheduled hours. But within that scheduled time, it can be place as often as the frequency attributes permits.

The default frequency is 180 minutes, but it can be configured for as little as every 15 minutes and as much as once per week.

Intrasite versus Intersite Replication

Intrasite Replication	Intersite Replication
Replication within sites is not compressed and is optimized to reduced latency.	Replication between sites is compressed to optimized WAN bandwidth utilization.
Normal replication takes place at 15 minutes intervals, security sensitive changes triggered immediate replication	Bridgehead servers are responsible for collecting replication data, compressing it, and sending it across site links.
The KCC checks for site topology changes every 15 Minutes.	Site links must be configured for replication to take place between sites.
Replication uses the RPC Over IP protocol within a site.	The default replication schedule is set for every 180 minutes, seven days a week.
	If two or more site are configured for fault tolerance, the cost settings determine the preferred path
	RPC Over IP or SMTP can be used as the Transport Protocol. RPC Over IP is the Preferred choice for most situations.

What are the Protocols used on replication?

There are Two Protocols used to replicate AD.

1)     Remote Procedure Call (RPC)

2)     Simple Mail Transfer Protocols (SMTP)

Remote Procedure Call (RPC):

Normally Remote Procedure Call (RPC) is used to replicate data and is always used for intrasite replication since it is required to support the FRS. RPC depends on IP

For transport.

Simple Mail Transfer Protocol (SMTP):

Simple mail transfer protocol (SMTP) may be used for replication between sites.

The “Active Directory Sites and Services” is used to manage Active Directory replication. Replication data is compressed before being sent to minimize bandwidth Use. SMTP cannot replicate the domain partition, however therefore the remote site would need to be in another domain to be able to effectively use SMTP for carrying replicate data.

“Bridgehead server” - A domain controller that is used to send replication information to one or more other sites.