1. Configuring replication

Goal: balance replication timelines and efficiency

1 )  Intrasite: optimized for high-speed, low-latency LAN links.

Intrasite replication can be initiated in one of two ways:

1. Notification: when a change is made to the AD database, the DC on which the change was made notifies its replication partners. Then the partners request replication from the notifying DC.
2. Periodic replication: To account for missed updates, DCs request replication from their partners periodically (once per hour). The interval can be configured in the connection object’s Properties dialog box.

Intrasite replication involves two main components: Knowledge Consistency Checker(KCC) and connection objects

Knowledge consistency Checker (KCC): a process that runs on every DC and builds a replication topology among DCs in a site and establishes replication partners.

The topology is designed to ensure that no more than two DCs lies in the replication between two domain controllers. Or data in a replication transfer doesn’t have to travel more than 3 hops to reach its destination DC.

Intervals: A domain controller waits 15 seconds after an active directory change before replicating with its partners, with a 3 seconds delay between partners.

The KCC recalculates the replication topology every 15 minutes.

Or manually recalculate : in Active directory Sites and Services, choose the DC under the Servers, in the right pane, right click the NTDS settings, , point to all tasks, and click Check Replication Topology, this will run the KCC algorithm.

Connection Objects 

An AD object created in Active Directory sites and services that defines the connection parameters between two replication partners. To find it, click the NTDDS settings , in the right pane, these objects are the connection objects.

To see the parameters, Right click a objects and choose properties.

• General Tab:
  • Change schedule: If you change the default schedule(hourly), you will be warned that the changes are overwritten by AD, unless you mark the object as not automatically generated.
  • Replicate Naming Context: (Not configurable)specifies which partitions are replicated and from where.
  • Partially Replicated Naming Context: (not configurable) If the DC is a GC and there are multiple domains in the forest, there is a domain name listed here. If the DC is not a GC, this text box is empty.
• Create connection objects: right click the NTDS settings, choose the New Active Directory Domain Services Connection…

Check the replication status: repadmin /showrepl  . For more command, use repadmin /?

Global Catalog Repplication:

Evidence of transferring the global catalog partition: in the properties of a connection object between global catalog servers, the Partially Replicated Naming Context(s) field shows ” All other domains”

RODC replication

• The connection between an RODC and a writeable DC is a one-way connection(Unidirectional) because changes can’t originate on a RODC. Unidirectional provides an extra level of security for network with branch office locations.Even if a server is compromised and someone is able to make malicious changes to AD on an RODC, the changes can’t be propagated to DCs in the rest of the network.
• Two RODCs can replicate with one another, as long as one has an incoming connection with a writeable DC
• The Domain directory partition can be replicated only to an RODC from a win08 or later DC.
  Win 03 DC can replicate other partitions to an RODC
• When upgrading a domain from win03, the first 08 DC must be writeable.
• To increase security of the AD data stored on a RODC, administrators can configure a filtered attribute set, which specifies domain objects that aren’t replicated to RODCs. The type of data to filter usually includes credential information that might be used by applications using AD as a data store. Any data that might be considered security sensitive can be filtered, except objects required for system operation. Filtered attribute sets are configured on the schema master. For more, check here: https://technet.microsoft.com/en-us/library/cc753459(v=ws.10).aspx
  https://technet.microsoft.com/en-us/library/cc755310(v=ws.10).aspx

Password Replication Policy (PRP)

By default, account passwords aren’t stored on an RODC, which includes both user and computer account passwords.

However, if the RODC stores no passwords, each user and computer in the same site with the RODC must be referred to a writable DC, most likely located across a WAN link. To prevent this problem, you can specify accounts for which passwords are replicated.

When an account pasword is replicated, its password is retrieved from a writeable DC the first time the account logs on, and thereafter, the password is retrieved from the RODC.

Password replication is also known as ” credential caching”

The PRP can be accessed in the Properties dialog box of the RODC computer account.

The PRP tab is only available on RODCs, there are two default group to which Admins can add users: Allowed RODC Password Replication group and Denied RODC Password Replication group. They have no members by default, if a user is member of both, the Denied takes precedence. Users who often visit where RODCs are used might be candidates for membership in the Allowed RODC Password Replication group.

Admins can customize the user/group list here, one useful usage is you can add all the computer accounts in the branch office to a group and add that group to the PRP as the allowed PRP group.

Sysvol replication

Sysvol replicates group policy template files, ADMX central store, and logon scripts. It uses DFSR for windows 2008 or later, user FRS for previous versions.

Group policy replication

Group policy object(GPO) is composed of a group policy template (GPT) and group policy container(GPC).

The GPT is stored in sysvol share, and GPC is stored in AD domain partition. Because they are in different places on a DC, different methods are required to replicate GPOs to all DCs. GPCs are replicated during AD replication, GPTs are replicated with FRS or DFSR.

Another issue is GPC and GPT can be out of sync. The Interval of AD replication is 15 seconds, while the Sysvol share occurs immediately after a change is made. Starting with Windows XP, client computer checks the version number of both components before applying GPO settings.

The most likely problem with GPO replication is a delay in clients receiving changes in policy settings, especially in multiple sites environment. You can diagnosed with GPMC by selecting the GPO in the left pane, clicking the status tab in the right pane, and clicking the Detect now button.

Fix replication for FSR: https://support.microsoft.com/en-in/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-servi

Upgrading to DFSR

If you domain includs windows server 2003 or older DCs, it uses FRS to replicate Sysvol. And you should migrate to more reliable DFSR asap. Even if you have upgraded all servers to Win2008 or later, FRS might still be running if your domain once contained older DCs.

Migration status:

• status 0 – start–The C:\Windows\SYSVOL folder is present and mapped to the SYSVOL share and is being replicated with FRS
• State 1- Prepared –The SYSVOL share continues to be replicated with FRS. A new folder named SYSVOL_DFSR has been created; it contains a copy of the SYSVOL share and is being replicated with DFSR
• State 2 – Redirected — The SYSVOL_DFSR folder is mapped to the SYSVOL share and is being replicated with DFSR. FSR continues to replicate the old C:\windows\SYSVOL folder, which is no longer mapped to the SYSVOL share.
• State 3 – Eliminated — The SYSVOL_DFSR folder is mapped to the SYSVOL share and continues to be replicated with DFSR. The original c:\windows\SYSVOL folder is deleted, and FRS replication no longer occurs.

Steps:

For more , check https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/

you can use dfsrmig /getmigrationstate to see whether you need to perform DFSR migration.

Before the migration, better to backup the DC state, use wbadmin start systemstatebackup

In this case, the health of AD and SYSVOL on all domain controllers is not known. For instance, you are not using System Center Operations Manager to monitor your domain controllers for AD replication, SYSVOL availability, and free disk space.

The goal of the Quick Migration scenario is to test the conditions of the domain controllers, then migrate SYSVOL to DFSR, with the ability to roll back during the process.

1. Ensure free disk space – The DFSR migration process copies the contents of SYSVOL to a parallel folder called SYSVOL_DFSR, and then shares out that copy during the Redirection phase. This means that on the volume where your SYSVOL exists on domain controllers – typically the C: drive – you need at least as much free space as the size of the current SYSVOL folder, plus a 10% fudge factor. For instance., if your current SYSVOL folder is 2GB (an unusually large SYSVOL), you should ensure that at least 2.2 GB disk space is free on the same volume. Most SYSVOL are only a few hundred MB or less.

An easy way to determine the free disk space on a bunch of remote DCs is with Psinfo.exe -d. Look here for more info. The WMI Win32_LogicalDiskclass is also a possibility, such as through Windows PowerShell:

Get-WmiObject -Class win32_logicaldisk -ComputerName srv01,srv02,srv03 | FT systemname,deviceid,freespace -auto

You can get fancier here, first looking on each computer to decide which volume hosts SYSVOL and comparing sizes and such, but this is the quick migration guide!

Note: you can greatly decrease the size of your SYSVOL by preventing legacy ADM replication using KB813338. A hundred group policies with 50 registry settings apiece is unlikely to exceed 5MB total when creating group policies using Windows Vista or later. The ADMX central store and alternatives are available for servicing.

2. Ensure correct security policy – You must ensure that the built-in Administrators group has the “Manage Auditing and Security Log” user right on all your domain controllers. This is on by default, so if it’s not set, someone yanked it. Microsoft does not support removing that, no matter what you may have read elsewhere. To validate, examine the group policy applied to your domain controllers by using Gpresult.exe. For more info, examine KB2567421.

3. Ensure AD replication is working – The DFSR migration depends entirely on each domain controller receiving and sending state changes via AD replication. There are many ways to examine AD health, but the easiest is probably the Active Directory Replication Status Tool. Install the utility and scan your domain for errors; if there are problems, fix them and then continue. Don’t attempt a DFSR migration unless all your domain controllers are replicating AD correctly.

Ideally, when you set “Errors Only” mode on, it looks like this:

4. Ensure SYSVOL is shared – DFSR migration naturally depends on SYSVOL itself; it must already be shared and the DC must be advertising and available, or migration at each stage will never complete. The simplest way to check all your domain controllers is with the Dcdiag.exe command using two specific tests:

Dcdiag /e /test:sysvolcheck /test:advertising

Don’t attempt a DFSR migration unless all your domain controllers are passing the connectivity, SYSVOL, and advertising tests with no errors.

They should look like this:

5. Migrate to Prepared State – Now you will migrate to the Prepared state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the FRS copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

Dfsrmig /setglobalstate 1

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Prepared state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

As I mentioned in the advice section, you can speed this processing up with faster AD replication and DFSR polling.

6. Migrate to Redirected State – Now you will migrate to the Redirected state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the DFSR copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

Dfsrmig /setglobalstate 2

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Redirected state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

7. Migrate to Eliminated State – Before migrating the domain to the Eliminated state, verify that replication is working correctly by command repadmin /replsum . Finally, you will migrate to the Eliminated state, where DFSR is replicating SYSVOL and FRS is removed. Unlike the Prepared and Redirected states, there is no way to go backwards from this step – once executed, FRS is permanently stopped and cannot be configured again. On the PDC Emulator domain controller, run (as an elevated domain admin):

Dfsrmig /setglobalstate 3

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Eliminated state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

Your migration is complete.

8. Verify – To verify the the migration. type net share and press enter on all DCs, the netlogon share should be mapped to the c:\windows\SYSVOL_DFSR\sysvol\domainname\SCRIPTS folder, and the SYSVOL share should be mapped to the c:\windows\SYSVOL_DFSR\sysvol folder.

9. Make sure you don’t need the FRS for other purose, Stop the FRS service: sc stop ntfrs. then use sc config ntfrs start=disabled

Fix the replication for DFSR

Consider the following scenario:

You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.

How to perform a non-authoritative synchronization of DFSR-replicated SYSVOL (like “D2” for FRS)

1. In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE

2. Force Active Directory replication throughout the domain.
3. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:

   DFSRDIAG POLLAD

4. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
5. On the same DN from Step 1, set:

   msDFSR-Enabled=TRUE

6. Force Active Directory replication throughout the domain.
7. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:

   DFSRDIAG POLLAD

8. You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D2” of SYSVOL.

How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like “D4” for FRS)

1. In the ADSIEDIT.MSC tool, modify the following DN and two attributes on the domain controller you want to make authoritative (preferrably the PDC Emulator, which is usually the most up to date for SYSVOL contents):

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE
   msDFSR-options=1

2. Modify the following DN and single attribute on all other domain controllers in that domain:

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE

3. Force Active Directory replication throughout the domain and validate its success on all DCs.
4. Start the DFSR service set as authoritative:
5. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
6. On the same DN from Step 1, set:

   msDFSR-Enabled=TRUE
   

7. Force Active Directory replication throughout the domain and validate its success on all DCs.
8. Run the following command from an elevated command prompt on the same server that you set as authoritative:

   DFSRDIAG POLLAD

9. You will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D4” of SYSVOL.
10. Start the DFSR service on the other non-authoritative DCs. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
11. Modify the following DN and single attribute on all other domain controllers in that domain:

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

    msDFSR-Enabled=TRUE

12. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):

    DFSRDIAG POLLAD

Special replication situations

1. Urgent Replication events: the following events trigger change notifications immediately, without waiting the normal 15 seconds
   • Account lockouts
   • change to the account lockout policy
   • changes to the domain password policy
   • change to non-security principal passwords, such as the password used to create a trust relationship
   • password change to a domain controller computer account
   • changes to the RID master DC
2. User account password changes:When a user’s password is changed. A user whoes password is changed can be authenticated by a DC different from the one where the change originates.
   To avoid delays between password changes and a user’s ability to log on, AD forwards password changes with urgent processing to the PDC emulator DC.So if a user attempts to log on with the new password before the authenticating DC has this information, the logon attempt is forwarded to the PDC emulator for the domain instead of denying the logon.
   We can use group policies to configure DCs to not contact the PDC emulator when a logon fails,however,which you might want to do if there’s no PDC emulator in the local site.
   How to configure: Computer Configuration>Policies> Administrative Templates>System> Net Logon in right pane, Contact PDC on logon failure

2)  Intersite: optimized to take slower WAN links into account.

Intersite replication occurs between bridgehead servers. When the KCC detects that replication must occur between sites, one DC in each site is designated as the InterSite Topology Generator (ISTG). The ISTG then designates a bridgehead server to handle replication for each directory partition.

The process of creating a custom site link has five basic steps and two optional steps:

1. Create a new site.

2. Create Subnets, and associate it with the new site.

3. Create the site link.

4. Configure the site link’s associated attributes.

5. Create site link bridges.

6. Configure connection objects. (This step is optional.)

7. Designate a preferred bridgehead server. (This step is optional)

Configure site links

1. General tab: By default, intersite replication occurs every 180 minutes, 7 days a week. And the default cost is 100.
2. Attribute Editor: Option attributes,
   • by default, notification of change doesn’t occur between sites, to enable notifications by setting the options attribute to 1.
   • Data compression: by default is on, to turn it off, set the option attribute to 4.

To combine multiple options, simply add the values together.

The options attribute uses a bitmap. Its possible values are:

You can use any combination of these. If your options attribute already has a value you need to perform a BITWISE OR operation on the existing value. If the value is 4, convert that to binary (100), perform an OR operation with binary 1, the result should be binary 101, which you convert to decimal (5) and enter as the value of the options attribute.

Create a site link: right click the IP folder and click new site link.

• One site link must contain at least two sites.
• One site can exist in more than one site link.

Bridgehead servers

repadmin /bridgeheads

Manual configure bridgehead server:

Open Active Directory sites and services > Sites > XXXX (sitename) > Servers >XXXX(servername), right click the server name, choose properties click the Transport protocol under the ” transports available for intersite data transfer:” then click Add>> . Then this server xxxx is a preferred bridgehead server.

Make sure all directory partitions in the site are contained on the bridgehead servers you configure. If you don’t, windows will warn you about which partitions the configured bridgehead servers won’t replicate. So you need to add additional Domain Controllers, which contains the missing partition, to the bridgehead.

Note: If a manually configured bridgehead server fails, replication for the partitions it contains stops, the ISTG will not try to assign a new bridgehead server again.
If the ISTG assigns the bridgehead server and it fails, the ISTG automatically attempts to assign a new one.

Intersite transport Protocols

1. IP: essentially use Remote Procedure Call(RPC) over IP. RPC over IP uses synchronous communication, which requires a reliable network connection with low latency.
2. SMTP: asynchronous protocol that works well for slower, less reliable connections. It can not be used to replicate domain directory partitions.

Now we rarely use SMTP, when we use it, only to replicate schema, global catalog, and configuration partitions.

Site link bridges

A site link bridge enables transitivity between site links. Each site link in a bridge must have a site in common with another site link in the bridge. The Knowledge Consistency Checker (KCC) uses the information on each site link to compute the cost of replication between sites in one site link and sites in the other site links of the bridge.

By default, all site links are transitive and it is recommended to keep transitivity enabled by not changing the default value of Bridge all site links (enabled by default). However, you will need to disable Bridge all site links and complete a site link bridge design if:

• Your IP network is not fully routed ( partially routed network). When you disable Bridge all site links, all site links are considered nontransitive, and you can create and configure site link bridge objects to model the actual routing behavior of your network.
• You need to control the replication flow of the changes made in Active Directory.
• Control traffic through firewalls.
• Reduce confusion of the KCC.

Right click the IP or SMTP folder under Inter-site transports, choose Properties. click to clear the Bridge all site links. Then create a site link bridge, Right click the IP or SMTP folder under Inter-site transports, choose New Site Link Bridge.

Manage replication

To force replication to occur for troubleshooting or testing purposes or don’t want to wait for normal replication schedule. The main tool is repadmin command line program.

• repadmin /replicate dest_DC src_DC partition   :  if you want to replicate only domain directory partition from server2 to server1 in domain frankfu.com , use repamin /replicate server1 server2 dc=frankfu,dc=com
• repadmin /syncall dc: This command forces replication to occur between the specified DC and all its partners.
• repadmin /kcc : This command causes the KCC to check the replication topology and update it. When you add or remove domains or DCs you may need this to update the new topology.
• repadmin /test:replications : test whether a connection can be made and the results of test run on each AD partition.

Powershell: sync-ADObject , forces replication of a single specified AD object between two DCs.

Monitor replication by CLI

• partners: repadmin /showrepl
• about connection objects: repadmin /showconn
• object replication info: repadmin /showobjmeta
• summary of status: repadmin /replsum
• Ensure all DC are advertised: dcdiag /test:advertising
• Tests for failures in intersite replication: dcdiag /test:intersite
• Test for timely and error-free replication: dcdiag /test:replication
• Verifies replication health, specifically its security: dcdiag /test:checkSecurityError

Powershell

• Get-ADReplicationConnection: shows information about replication connection objects.
• Get-ADReplicationFailure: shows replication failures for a specified DC, site, or domain.
• Get-ADReplicationPartnerMetadata: shows detailed replication information for a particular replication partner
• Get-ADReplicationSite: replication info for a site
• Get-ADReplicationSiteLink: Shows replication information for a site link, including the cost and replication frequency.
• Get-ADReplicationUpToDateNessVectorTable: show how up to date a replication partner is. Displays the data and time of the last successful replication, the name of the replication partner, and the Update Sequence Number(USN)