Active Directory Sites and Replication

Even in the smallest of domains Microsoft recommends that there is more than one Domain Controller. This provides fault tolerance and can enhance performance for clients. Every Domain Controller contains a read/write copy of the Active Directory Database. Each Domain Controller must store the same database. In order for the Active Directory database to remain constant, Replication must take place.

Use the buttons below to navigate through the lesson

A system administrator can make a change to any domain controller in the domain and the change will eventually be propagated to the other domain controllers. This type of replication is known as multi-master. There are no primary or secondary domain controllers for the domain, i.e. all domain controllers have equal control over the Active Directory Database.

Replication

Windows NT 4.0 used a different method for replication. NT 4.0 Domains contained Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). Under NT4, Changes to the domain could only be made on the PDC. The BDC stored a backup copy of the PDC. Windows 2003/2008 Domain Controllers make no such distinction. All Domain Controllers have equal control.

Under Windows Server 2008, changes can be made to any domain controller, and these changes will be replicated to all the others accordingly. However, under NT 4.0, changes can only be made to the Primary Domain Controller! Within Windows Server 2008 there are two levels of replication : Domain Wide and Forest Wide. With Domain Wide replication all data about the domain is replicated to all other domain controllers within the domain. Forest Wide Replication is carried out by the global catalog servers and they are responsible for the replication of:

• The Schema for the forest
• Forest configuration information
• A stripped down version of all objects within the forest

As global catalog servers are also Domain Controllers they also replicate domain data.

Elements of Active Directory Replication

As previously shown, in a Windows Server 2008 network, changes can occur on any Domain Controller. Two types of changes can occur: an originating update and a replicated update. An originating update is the first time a change is made to a property in Active Directory. e.g. You have two Domain Controllers, and you log on and change a user’s password. At this point, no other Domain Controller is aware of the change. This is known as the originating update. A replicated update on the other hand is a change made to the Active Directory that did not originate at that copy of the database. i.e. Because the change occurred at another Domain Controller, the change is considered to be a replicated update.

Every change to the directory is given a USN (Update Sequence Number). The USN is incremented every time a change is made on the domain controller. The DC keeps a record of its own USNs and the USNs of its replication partners. This table is known as a High-Watermark Table. Every 5 minutes (default) the DC asks its partners for any changes since the last USN which it has records of, for each DC. The partners then respond with their changes and the first DC updates its USN accordingly.

Both Domain Controllers currently store the same Active Directory Database. Now imagine a new user account is created on Server1:

Server1 now has a USN of 2 showing that it now has a more up-to-date copy of the database. Later on a change is made to the database from Server2. The end result is that all domain controllers will contain up-to-date information.

Server1 will notify Server2 that it has changes and replication will take place. Server2 will then have an updated database.

Replication Partners

Every Domain Controller can accept changes and it can also replicate these changes around the network. However, In Windows Server 2008, every Domain Controller doesn’t talk directly to every other Domain Controller, instead each Domain Controller has either one or several other replication partners. If a Domain Controller sends data directly to another Domain Controller then the two Domain Controllers are said to be replication partners.

This is ideal in situations where Domain Controllers are spread across remote offices. If every Domain Controller was replicating with every other Domain Controller then the available bandwidth would quickly be depleted.

Luckily, Active Directory creates its own replication topology. The Knowledge Consistency Checker (KCC) service creates replication links between all of the Domain Controllers with the enterprise.

The Knowledge Consistency Checker (KCC)

The KCC links Domain Controllers together using a two-way ring topology. This ensures that each Domain Controller has more than one route for replication. The KCC also ensures that the Domain Controllers it connects are never more than three hops away from each other. The KCC will periodically re-evaluate its topology ensuring that dynamic networks can be accommodated. If any changes occur to the network (such as the addition of a Domain Controller), then the KCC will recalculate an optimal path and reconfigure Windows automatically. KCC unlike some other services can quite happily work by itself without any configuration.

Although each Domain Controller has a high watermark table which stores a list of the USN numbers for its replication partners, another table is needed, this is known as the Up-To-Date Vector Table.

The Up-To-Date Vector Table stores a record of every DC on the network including the type of write, i.e. Originating or Replicated. This is used to prevent replication loops and any unnecessary replication.

Property Version Numbers

Every object in the Active Directory also has a Property Version Number (PVN) every time a change is made to the object its PVN number is increased. The PVN value is used to make sure that two replicated changes arriving at a DC have a method of working out precedence. The key here is that a higher version number has precedence over a lower version number.

There is more to the Active Directory replication process than has been shown here. The full process is beyond the scope of this course, but while it’s not required for the exam it certainly rewards further study!

Active Directory Sites and Subnets

In an ideal world everything would be connected with a high-speed network connection and users would be able to access resources regardless of where it was located, unfortunately this just isn’t the case. There are a two things to consider when setting up large networks with multiple sites:

1. Network Bandwidth: Network Bandwidth refers to the amount of data that can pass through the cable at any given time. For example, a standard modem may only be able to pass 56Kpbs (kilobits per second) of data through a cable whilst a 100Mbps UTP Cable can pass a lot more.
2. Network Cost: High speed links between remote sites can be very expensive and most companies may have to settle for slower, less reliable connections. This can cause a lot of problems for Active Directory since replication can generate a lot of replication traffic.

With these factors in mind network administrators have to be careful of how they setup Active Directory. (Imagine 1000 users logging on over a 56k Modem!)

Active Directory provides a solution to this problem, known as Sites. Sites take a network’s physical infrastructure into account to control replication traffic. The following Active Directory Objects are used to manage replication traffic:

Subnets: A subnet is a division of the network. Subnets are normally connected through routers or bridges. All computers on the same subnet are generally well connected. Computers are assigned to sites based on their location in a subnet or a set of subnets. Subnet information is used to locate the nearest DC for logon and for AD Replication to determine the best routes between domain controllers.

Sites: An Active Directory Site contains Domain Controllers linked by a high-speed, reliable, and cheap connection. Domain Controllers within a site all replicate using the notification process described earlier. Because there is no concern about replication speed or cost within a site, all domain controllers replicate whenever they need to instead of adhering to a fixed schedule.

The schedule used to determine the best time for replication between sites is based upon available bandwidth and cost. A site contains one or more subnets. By default all domain controllers become a member of a site called Default-First-Site-Name. The first domain controller created is always a member of this site (which can be renamed). New domain controllers are automatically added to the site (if any) containing their subnet.

Site Links: In order for replication to take place a site-link must be created. A schedule is applied to the site-link to state when the link is available. A site link can involve more than two sites. A default site-link using the IP protocol is created when Active Directory is first installed. This is called DEFAULTIPSITELINK. Different replication protocols are available for site-links (more later).

Sites are used in Active Directory to reduce replication traffic between remote locations across slow, expensive and unreliable WAN links. In the network shown there are three sites each connected with slow WAN Links. The Domain Controllers within each site have high-speed connections (10Mbps or above). They can quite happily replicate within a site without swamping bandwidth. However, UK Domain Controllers attempting to replicating with French ones over the slow 56k Link drastically reduce WAN bandwidth due to the large amount of replication traffic that AD generates. Sites prevent this by only replicating changes at specified times. Also, each site has a global catalog which users can access instead of using the site-link. A site can contain multiple domains or a domain can be a member of multiple sites. Consider the case when some site links are upgraded to 10Mbps connection. Germany is now a member of two sites. The UK / France link will rarely be used because a) the UK is not in the same site as France b) replication can be configured to use a Site Link Bridge.

Site Link Bridges

Site-link Bridges link two or more site-links into a new link. In the example above, it is quicker for the UK to communicate with France by using 2 site links, UK-GERMANY and GERMANY-FRANCE.  A new site-link bridge can be created using these two links. The UK site will now use the site-link bridge to replicate with France rather than the 56k connection. WAN traffic will be redirected through Germany.

Bridgehead Servers

Sites further reduce replication traffic by restricting the use of the WAN link to one Bridgehead Server in each site. Bridgehead servers are solely responsible for propagating changes to the directory to bridgehead servers in all other sites. Bridgehead servers at the dispersed sites are then responsible for distributing the changes to Domain Controllers in the remote sites.

Replication Traffic

There are two types of replication in Active Directory:

Intrasite Replication is the synchronisation of the Active Directory database between domain controllers within the same site. Machines inside a site normally have a high-speed connection.

Intersite Replication is the synchronisation of Active Directory between domain controllers in different sites. Intersite Replication is optimised to minimize the amount of traffic between sites.

Intrasite Replication

Intrasite Replication is normally very simple. All Domain Controllers within the site will replicate with each other ensuring a consistent copy of the database. It is always presumed that all domain controllers within a site have a high-speed, reliable connection. Domain Controllers within a site replicate using the Remote Procedure Call (RPC) protocol. The RPC protocol is optimised for transmitting and synchronizing data on a fast and reliable network. Non of the data is compressed.

Intersite Replication

Intersite replication is optimized for low-bandwidth connections which are less reliable, e.g. a 56Kpbs site-link. Intersite Replication can work with two different protocols to provide communication: RPC over Internet Protocol (IP) and Simple Mail Transfer Protocol (SMTP). RPC over IP is used when a fairly reliable connection is available. RPC over IP based connections require a constant connection between two or more domain controllers in different sites. SMTP is the protocol that is most commonly used for sending e-mails on the internet. SMTP will store the information if the receiving end is unavailable and attempt to resend it at a later period. SMTP is commonly used for dial-up connections that aren’t always available. The replication traffic can be resent at later intervals when the connection is available. N.B. To use SMTP for Intersite Replication a Windows Certificate Authority must be made available for security purposes. Intersite Replication can also be controlled using Active Directory Sites and Services. Replication schedules can be configured to control when replication is allowed to take place. E.G. “don’t replicate between 9am-5pm”. When configuring replication schedules time-zones need to be taken into consideration. It may be off-peak hours in England but it may be 4pm in the USA. A schedule must be created that will accommodate all sites.

Universal Group Membership Caching

When a user logs onto a domain in an Active Directory environment a global catalog server must be available to provide universal group membership information. If one is not available the user will not be able to logon. In Windows 2000 networks it was highly recommended that you placed a global catalog server in each site to prevent universal group membership information traversing slow WAN links. Although global catalog servers speed up response time they can also cause a lot of replication traffic. Windows Server 2003/8 domains introduce a new feature called Universal Group Membership Caching.

A Windows Server configured to use Universal Group Membership Caching will firstly contact a global catalog server for a user logging on and then store it so that subsequent requests will not need to be handled by a global catalog server.

This can greatly improve response time for logon requests, however a global catalog server must still be available for the server to obtain the user’s information. The server will also update this information every 8 hours. Universal Group Membership Caching does not eliminate the need for Global Catalog servers however they do help speed up logon requests.