Windows Active Directory Family---Configuring and monitoring AD Domain replication (1)

What is the site link for the ad domain?

To exchange replication data between two sites, they must be connected through a site link. A site link is a logical path that is used by the KCC or ISTG to establish replication between sites. When you create another site, you must select at least one site link to connect the new site to the existing one. If there is no site link, the KCC cannot allow computers in different sites to connect to each other and cannot replicate between sites.

A site link has a very important concept, which represents an available path for replication. A single site link is not able to control the network route being used, when you create a site link and add a site to it, you tell the ad domain to replicate between sites associated with the site link. ISTG creates connection objects, which then determine the actual replication path, although the replication topology established by ISTG enables efficient AD domain replication, but such a replication topology is not necessarily optimal for your network topology.

In order to better understand the site link, you can refer to this case, when you create a forest, will automatically generate a default site link object Defaultipsitelink, each new added site will be added by default to defaultipsitelink this site link. This default site link and any new site link default cost value is 100, replication frequency is 180 minutes, now the company has a data center HQ in headquarters, and there are three branches a, B, C, three branches and headquarters through a dedicated line connection, now each branch office to establish a site, Each branch site and headquarters are associated to the Defaultipsitelink site link object. Since four sites are in the same site link, the ad domain can replicate with each other in these four sites, such as a can replicate change data from B, B can replicate change data from C, and then C can replicate the change data from HQ, and then HQ replicates the change data from a. In these replication paths, replication traffic in network traffic, from one branch office through headquarters to another branch office, a single site link is unable to create a central diverging shape of the replication topology, even if your network topology is a center diverging shape.

To combine your network topology with AD replication, you must create a specific site link so that you can manually establish a site link to correspond to the replication topology you need. For the previous case, you need to establish three site links: 1. Hq-a 2.hq-b 3.hq-c.

After the site link is created, ISTG will use this topology to establish a replication topology between the sites, which connects to all sites and then automatically creates connection objects to configure the replication path, and best practices recommend establishing the correct site topology to avoid manually creating connection objects.

What is a site-linked bridge?

After you've created a site link and ISTG generated the linked object, you've almost done what you need, and in most environments, especially when the network topology is relatively simple, site links are enough to manage replication between sites, but in complex networks you can configure some additional components and replication properties.

Automatic site link bridging

All site links are bridged by default, such as a and HQ sites are linked together, then HQ and b sites are linked together, then A and b are linked together, but A and B is a to HQ and then to B plus the link overhead. In theory, if the DC for HQ is not available, ISTG can establish a direct connection between A and B DC, which needs to be implemented in the network topology distributed by the hub.

You can turn off the IP transport properties in the "Intersite transports" container and clear the "Bypass for all site links" check box so that you can disable automatic bridging of site links.

Site link bridge:

A site link bridge can connect to two or more two site links, which in a sense creates a delivery link. The site link bridge is only used when you clear the "Bridging all site links" in the transport protocol. Because site link auto-bridging is enabled by default, the site link bridge is not actually needed, but you can use automatic site link bridging for some of the main sites, or you can manually configure site link bridges for some of the most expensive sites. For example, suppose you have multiple sites, A and B are directly connected to HQ HQ, and the default cost value is 100,HQ with a backup datacenter Hq-ha, which uses a site link of 100 for three sites with Hq,a,b, and if all the DCs in the Hq-ha site are unavailable, But you want a site to still reach the B site, you can bridge A and B site links so that between A and B can be kept unblocked, so you need to configure a site link bridge between A and B, this link is greater than A and B to hq-ha the value of the site link is 100 of the delivery cost, But less than the delivery overhead of not establishing a site link bridge and directly from a to Hq-ha to B, if you do not establish a site link bridge, the link cost from a to B is a to hq-ha 100 overhead plus the hq-ha to B 100 overhead, with a total cost of 200, However, if a site link bridge is established between the two site links from a to hq-ha and hq-ha to B, the cost from A to B will be an intermediate value of 150. The purpose of a site link bridge is to allow two or more sites that are not directly connected to connect through a site link bridge, and the KCC will create a corresponding connection object from the site link bridge to adjust the replication topology of the ad domain.

Universal group membership cache:

When you configure AD domain replication, you may want to consider whether you need to set all DCs to GC. Because a GC server is required when a user logs on to a domain, deploying a GC in each site can improve your user experience. However, if you deploy a GC at a site, you may incur additional replication traffic, with limited network bandwidth between sites, and some network problems when replicating large numbers of objects from other domains within the forest, to avoid this problem, you can deploy a 2008-level DC at each site. And the universal group membership cache for this site is enabled.

How the universal group membership cache works:

A DC in the site has a universal group membership cache enabled, and when a user first attempts to log on, the DC stores the information for the universal group locally, and the DC obtains the user's universal group membership information from the GC server in the other site, and then caches and periodically refreshes the information. The next time the user tries to log in, the DC obtains the user's universal group membership information from the local cache without needing to link to the GC in the other site for information. Universal group membership information that is cached in the DC is refreshed by default 8 hours, and when the cache information is refreshed, the DC sends a universal group membership acknowledgment request to the specified GC. You can enable universal group membership caching in the site settings in the NTDS Site setting property.

The universal group membership cache does not need to connect to a GC to authenticate when logging on to the ad domain, so it reduces the time to authenticate users to a remote site that does not have a GC at the logon domain. However, we also need to consider the security risks of enabling universal group membership caching, because when an administrator removes a user from a universal group, the universal group membership cache refreshes at 8 hours (even if the WAN network is unable to communicate and the DC cannot get the latest information from the GC to flush the cache). It also does not refresh the cached information based on the copy operation, and if the user accesses it within 8 hours, it poses a risk to the resource. In addition, this caching method has some unexpected problems, when the user first log in at the remote site, exactly at this time the GC is also in an unusable state, the user's verification process and the previous logon verification process is different, it can not get the user's authentication information from the GC. Because of these problems, the universal group membership cache is deprecated and Microsoft recommends that all DCS be configured as GC.

Configuration options for intersite replication

When you create a site link, you can configure several options to help manage replication between sites, including:

1. Site link cost. When replication traffic for a site has multiple routes, the site link overhead is used to manage the flow of replication traffic, and the lower the cost, the higher the site link priority. You can configure the cost value on a specific site link to meet certain requirements or conditions, such as using a site link is faster and more reliable, then we can set the cost of the link is lower, let this link first use. We usually set the cost value of the slow link to a higher, lower the cost value of the quick link, and the default cost for the site link is 100.

2. Replication frequency. Replication between sites can only be done by polling, and replication partners will, by default, poll their upstream replication partners every 3 hours to check for change data. For some enterprises, this time interval may be too long, they want the directory change data can be copied more quickly, we can modify the replication frequency in the properties of the site link object to meet this requirement, the minimum polling time interval is 15 minutes.

3. Copy the schedule. Replication schedules are performed 24 hours a day by default, but you can limit replication to a specific time, which requires modifying the replication schedule in the site link properties.

The RODC only requires replication for cached user and computer credentials, and they use a password replication policy to determine which user or computer credentials may be cached on the server, and if a password policy allows an RODC to cache the credentials of a user or computer, the RODC can authenticate and service ticket operations. For this issue, you can create an allow list that contains user and computer credentials, and if a credential is not cached on the RODC, the RODC references a writable DC to perform authentication and service ticket operations if the computer account for this site is not authenticated and the WAN link is not connected. Then no user can authenticate, because the user can only authenticate to the domain after the client computer is authenticated.

To access the Password replication policy, open the properties of the RODC in the domain controllers container of the ad user and computer console and click on the "Password Replication Policy" tab, the Password replication policy for the RODC is determined by the two multivalued properties of the RODC computer account, both of which are called "Allow List" and "Deny List". If the user, computer, or service account is in the Allow list, the credentials are cached on the RODC after the user logs on, and you can add groups to the Allow list, and the credentials of the users or computer members in the group can be deferred on the RODC. When an account is present in both the Allow list and the Deny list, the Deny list has priority and the credentials of the account are not cached on the RODC.

To help manage password replication policies, two domain local security groups are established in the Users container of the ad domain, one allowed RODC Password Replication Group, and members of this group can replicate passwords to all the RODC in the domain. This group is not a member of the group by default, so a new RODC will not cache any credentials, if you want to cache some account credentials to all the RODC in the domain, then you just need to add these accounts to the group. Another group is the denied RODC Password Replication Group, in which members of this group do not allow the password to be copied to all the RODC in the domain, which by default will include some security-sensitive accounts, including domain Admins, Enterprise Admins,schema Admins and so on.

Tools that you can use to monitor and manage replication:

After you have deployed the replication configuration, you need to monitor, optimize, and troubleshoot replication health, and there are two very useful tools to help report and analyze the health of replication, one for the Replication diagnostic Tool Repadmin.exe and the other for the Directory Server Diagnostic Tool Dcdiag.exe.

Replication Diagnostic Tool Repadmin.exe:

Repadmin.exe is a command-line tool that can be used to report the replication status of each DC, Repadmin.exe generated information can help identify potential replication problems in the forest, and you can view information about the level of replication metadata detailed to specific objects and properties to help you find out at what time the ad domain was modified and where it caused the complex You can even use Repadmin.exe to create a replication topology and then force replication between DCs.

Repadmin.exe has a lot of commands to perform specific tasks, the specific command parameters we can use "Repadmin/?: Parameters" To see the function of a parameter can be achieved. We can perform some of the following replication monitoring tasks through Repadmin.exe:

1. Displays the replication partner for the specified DC. We can repadmin/showrepl dcname by command. By default, repadmin only shows inbound connections, and if you add a parameter/repsto you can show outbound connections at the same time, such as Repadmin/showrepl Dc01/repsto.

2. Displays the linked object for the specified DC. repadmin/showconn dcname This command is used to display a linked object for a specified DC, such as Repadmin/showconn DC01.

3. Displays metadata about the object, including the object's properties and replication. You can learn more about replication by examining the same objects on different DCs, based on the properties they already have and not on their respective DCs. Repadmin/showobjmeta dcname ObjectDN such as Repadmin/showobjmeta DC01 "cn=james,cn=users,dc=contoso,dc=com", You can also run this command on another DC02, and then compare the information displayed on both sides to see what is the same and different about the replicated data. The DC name of this command can be replaced with a *, which means that the data for this object is fetched from all DCs.

Repadmin.exe can also be used to modify your replication infrastructure, primarily with the following commands:

1. Initiates the KCC calculation. Use REPADMIN/KCC to force the KCC to recalculate the inbound replication topology of the server.

2. Force replication between two replication partners. You can force replication of a partition between the source DC and the destination DC through Repadmin.exe, the command format repadmin/replicate the destination DC name, the source DC name Partition name, such as Repadmin/replicate DC01 DC02 "cn=configuration,dc=adatum,dc=com", this command copies the configuration partition on the DC02 to DC01.

3. Synchronizes a DC with all replication partners. Use the command repadmin/syncall dc/a/E to synchronize the DC with all replication partners, including DCs that are not at this site. For example, Repadmin/syncall dc01/a/E, which means that all directory partitions on the DC01 are synchronized with all replication partners, including a cross-site DC, where/a represents all directory partitions, and if this parameter is not used, only the configuration partition is synchronized,/e indicates cross-site synchronization, Without this parameter, only the replication partners of this site will be synchronized.

Directory Service diagnostic tools:

Dcdiag.exe is a Directory services diagnostic tool that is used to test and report on the overall health status of AD Replication and security. If the command runs Dcdiag.exe with no parameters, a summary test is performed and the test results are reported, whereas if the parameter/C is taken, the command dcdiag/c executes almost all of the directory diagnostic tests, the reports of which can be exported to a file for viewing, and the files can have multiple types , such as Txt,xml.

You can also specify the type of test, which requires the use of the command dcdiag/test: Test name, some parameters that are directly related to replication are as follows:

1. Frsevent. Reports all FRS replication operation errors.

2. Dfsrevent. Reports the operation errors of all DFS Replication systems.

3. intersite. Check for error messages that prevent or delay site replication.

4. Kccevent. Identifies the error message for the KCC.

5. Replication. Check direct real-time replication of the DC.

6. Topology. Check that the replication topology is fully connected to all DCs.

7. Verifyreplicas. Verify that all application directory partitions on all DCs that have replicas are fully instantiated

Several PowerShell commands for AD replication:

Get-adreplicationconnection This command to obtain a link to the specified AD replication or a set of AD replication connection objects based on the filter criteria

Get-adreplicationfailure This command displays a description of the AD replication error

Get-adreplicationpartnermetadata This command to display replication metadata for the destination DC replication partner

Get-adreplicationsite gets the specified AD replication site or a set of replication site objects based on the filter criteria

Get-adreplicationsitelink to get the specified AD site link or a group of site links based on the filter criteria

Get-adreplicationsitelinkbridge to obtain the specified AD site link bridge or a group of site link bridges based on the filter criteria

Get-adreplicationsubet to obtain a specified ad subnet or set of ad subnets based on the filter criteria

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1588735

Windows Active Directory Family---Configuring and monitoring AD Domain replication (1)