Windows Server 2016-active Directory replication Concepts (ii)

This chapter continues to complement the concept of Active Directory replication, as follows:

Connection object:

A Connection object is an Active Directory object that represents a replication connection from the source domain controller to the destination domain controller. A domain controller is a member of a single site and is represented by a server object in Active Directory Domain Services (AD DS) in the site. Each server object has a child NTDS Settings object that represents the replication domain controller in the site.

The Connection object is a subkey of the NTDS Settings object on the destination server. To replicate between two domain controllers, one of the server objects must have a Connection object that represents inbound replication from another. All replication connections for a domain controller are stored under the NTDS Settings object as connection objects. The connection object identifies the replication source server, contains the replication schedule, and specifies the replication transport.

The Knowledge Consistency Checker (KCC) automatically creates connection objects, but they can also be created manually. Connection objects created by the KCC as < auto generate > appear in Active Directory Sites and Services snap-in, and are considered sufficient under normal operating conditions. The connection object created by the administrator is a manually created Connection object. Manually created connection objects are identified by the name specified by the administrator at the time of creation. When you modify < automatically generate > connect an object, it is converted to an administrative modified connection object, and the object appears as a GUID. The KCC does not change manually or modified connection objects.

KCC:

The KCC is a built-in process that can run on all domain controllers and generate replication topologies for Active Directory forests. The KCC creates a separate replication topology based on whether replication occurs within a site (within a site) or between sites (between sites). The KCC also dynamically adjusts the topology to accommodate the addition of new domain controllers, the removal of existing domain controllers, the movement of domain controllers into the site, changes in costs and schedules, and domain controllers that are temporarily unavailable or in an error state.

Within a site, connections between writable domain controllers are always arranged in a two-way loop, with additional shortcut connections to reduce the latency of large sites. On the other hand, intersite topologies are hierarchies of spanning trees, which means that there is one intersite connection between any two sites in each directory partition and usually does not contain shortcut connections.

On each domain controller, the KCC creates a replication route by creating a one-way inbound connection object that defines a connection from another domain controller. For domain controllers in the same site, the KCC automatically creates connection objects without administrative intervention. If you have more than one site, you can configure site links between sites, and a single KCC in each site automatically creates connections between sites.

Windows Server-RODC KCC improvements:

There are many KCC improvements that can be adapted to the newly provided read-only domain controller (RODC) in Windows Server 2008. A typical deployment scenario for an RODC is a branch office. In this scenario, the most commonly deployed Active Directory replication topology is based on the hub-spoke design, where branch domain controllers in multiple sites replicate using a small number of bridgehead servers in the central site.

One of the benefits of deploying an RODC in this scenario is one-way replication. Bridgehead servers do not need to replicate from the RODC, which reduces administration and network usage.

However, on previous versions of the Windows Server operating system, one of the administrative challenges highlighted by the Hub-spoke topology is that after the new bridgehead domain controller is added to the hub, There is no automatic mechanism to redistribute a replication connection between a branch domain controller and a branch domain controller a hub domain controller can take advantage of a new hub domain controller.

The normal functionality of Windows Server RODC,KCC provides some rebalancing, eliminating the need to use other tools such as Adlb.exe. The new feature is enabled by default. You can disable it by adding the following registry key on the RODC:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

"Random BH loadbalancing Allowed"

1 = Enabled (default), 0 = Disabled

Failover Features:

The site ensures that replication is routed around network failures and offline domain controllers. The KCC runs at a specified time interval to adjust the replication topology for changes that occur in AD DS, such as when a new domain controller is added and a new site is created. The KCC checks the replication status of an existing connection to determine if any connections are not working correctly. If the connection does not work because of a domain controller failure, the KCC automatically establishes a temporary connection to other replication partners, if available, to ensure replication occurs. If all domain controllers in the site are not available, the KCC automatically creates a replication connection between the domain controllers in the other site.

Subnets:

A subnet is part of a TCP/IP network that points to a set of logical IP addresses. Subnets to group computers in a way that identifies the physical proximity of the network. The subnet object in AD DS identifies the network address that is used to map the computer to the site.

Site:

A site is an Active Directory object that represents one or more TCP/IP subnets that have a highly reliable and fast network connection. Site information allows administrators to configure Active Directory Access and replication to optimize the use of physical networks. Site objects are associated with a set of subnets, and each domain controller in the forest is associated with an Active Directory site, depending on its IP address. A Web site can host domain controllers from multiple domains, and domains can be represented in multiple Web sites.

Site Links:

A site link is an Active Directory object that represents the logical path that the KCC uses to establish a connection for Active Directory replication. A site link object represents a set of sites that can communicate at a uniform cost through a specified inter-site transfer.

All sites included in a site link are considered to be connected by the same network type. A site must use a site link to manually link to another site so that a domain controller in one site can replicate directory changes from a domain controller in another site. Because site links do not correspond to the actual paths that are used by network packets on the physical network during replication, you can increase the efficiency of Active Directory replication without creating redundant site links.

When two sites are connected through a site link, the replication system automatically creates a connection between the specific domain controllers that are called bridgehead servers in each site. In Windows Server 2008, all domain controllers in a site that hosts the same directory partition are selected as bridgehead servers. Replication connections created by the KCC are randomly distributed across all candidate bridgehead servers in the site to share replication workloads. By default, when a connection object is first added to a site, the random selection process occurs only once.

Site link bridge:

A site link bridge is an Active Directory object that represents a set of site links to which all sites can communicate using public transport. Site link bridges allow domain controllers that are not directly connected through communication links to replicate with each other. Typically, a site link bridge corresponds to a router (or a set of routers) on an IP network.

By default, the KCC can form delivery routes through any and all site links that have some common sites. If this behavior is disabled, each site link represents its own unique and isolated network. Site link bridges can be used to express a set of site links that can be treated as a single route. Each bridge represents an isolated communication environment for network traffic.

A site link bridge is a mechanism that logically represents the transfer of physical connections between sites. The site link bridge allows the KCC to use any combination of included site links to determine the cheapest route to interconnect the directory partitions in those sites. The site link bridge does not provide an actual connection to the domain controller. If the site link bridge is removed, replication will continue through the combined site link until the KCC removes the link.

A site link bridge is required only if the site contains a domain controller for a managed directory partition, and the directory partition is not hosted on a domain controller in a neighboring site, but the domain controller that hosts the directory partition is located in one or more other sites in the forest. Adjacent sites are defined as any two or more sites that are included in a single site link.

The site link bridge creates a logical connection between two site links, providing a delivery path between two disconnected sites by using a staging site. For intersite topology Builder (ISTG), bridging means a physical connection by using a staging site. A bridge does not mean that a domain controller in the staging site will provide a replication path. However, this can happen if the staging site contains a domain controller that hosts the directory partition that you want to replicate, in which case the site link bridge is not required.

The cost of each site link increases, creating a total cost for the resulting path. If the staging site does not contain a domain controller for the managed directory partition and there are no lower cost links, the site link bridge will be used. If the staging site contains a domain controller that hosts directory partitions, the two disconnected sites will be set up to replicate connections to the staging domain controller instead of using a network bridge.

Site link transitivity:

By default, all site links are transitive or "bridged." When site links are bridged and timesheets overlap, the KCC creates replication connections to determine the domain controller replication partners between sites, where the site is not directly connected through a site link, but is directly connected through a set of public sites. This means that you can connect any site to any other site through a combination of site links.

Typically, for a fully routed network, you do not need to create any site link bridging unless you want to control the process of replicating changes. If your network is not fully routed, you should create a site link bridge to avoid an impossible replication attempt. All site links for a particular transport imply a single site link bridge belonging to that transport. The default bridging of site links occurs automatically, and no Active Directory objects represent the bridge. The Network Bridge all site link settings found in the properties of the IP and Simple Mail Transfer Protocol (SMTP) intersite transport container Enable automatic site link bridging.

Note: SMTP replication is not supported in future versions of AD DS; Therefore, creating a site link object in the SMTP container is not recommended.

Global Catalog server:

A global catalog server is a domain controller that stores information about all objects in the forest so that applications can search AD DS without referencing the specific domain controller that stores the requested data. As with all domain controllers, the global catalog server stores a full writable copy of the schema and configuration directory partition, and a full writable copy of the domain directory partition of the domain to which it is hosted. Additionally, the global catalog server stores a partial read-only copy of each other domain in the forest. A partial read-only domain copy contains each object in the domain, but contains only a subset of the properties (those that are most commonly used for search objects).

Universal group member Cache:

The universal group membership cache allows domain controllers to cache the user's universal group membership information. You can use the Active Directory Sites and Services snap-in to enable domain controllers running Windows Server 2008 to cache universal group membership.

Enabling universal group membership caching eliminates the need for global catalog servers at each site in the domain, minimizing network bandwidth usage, because domain controllers do not need to replicate all objects that reside in the forest. It also reduces logon time because the authentication domain controller does not always need access to the global catalog to obtain universal group membership information.

Windows Server 2016-active Directory replication Concepts (ii)