I'll show you how to identify AD replication problems.

I'll also show you how to troubleshoot

and resolve four of the most common AD replication errors:

 Error -2146893022 (The target principle name is incorrect)

 Error 1908 (Could not find the domain controller)
 Error 8606 (Insufficient attributes were given to create an object)
 Error 8453 (Replication access was denied)

Along the way, you'll learn how to analyze replication metadata using tools such as the AD
Replication Status Tool, the built-in command-line utility RepAdmin.exe, and Windows
PowerShell.

For this discussion, I'll use the Contoso forest shown in Figure 1. Table 1 contains the roles,
IP addresses, and DNS client settings for the machines in that forest.

Figure 1: Exploring the Contoso Forest

Table 1: Machine Roles and Settings
DNS Client
Machine Roles IP Address
Settings
DC in the forest root domain,
DNS, GC server, all Flexible
DC1 192.168.10.1
Single-Master Operation 192.168.10.2
(FSMO) roles 127.0.0.1
 Table 1: Machine Roles and Settings
DNS Client
Machine Roles IP Address
Settings
DC in the forest root domain, 192.168.10.1
DC2 192.168.10.2
DNS, GC server 127.0.0.1
DC in a child domain in the
192.168.10.1
ChildDC1 forest, DNS, GC server, domain- 192.168.10.11
127.0.0.1
wide FSMO roles
RODC in the child domain in the
192.168.10.11
ChildDC2 forest, DNS, GC server, 192.168.10.12
127.0.0.1
MinShell
DC in a tree-root domain in the
127.0.0.1
TRDC1 forest, DNS, GC server, domain- 192.168.10.21
192.168.10.1
wide FSMO roles
Windows 8.1 administration
192.168.10.1
Win8Client workstation in the forest root 192.168.10.5
192.168.10.2
domain

Identifying AD Replication Problems

To identify the AD replication problems, you can run the AD Replication Status Tool from
your administration workstation in the forest's root domain. For this example, you'd open this
tool from the Win8Client machine, then click the Refresh Replication Status button to ensure
you're communicating properly with all the DCs. On the Discovery Missing Domain
Controllers tab of the tool's Configuration/Scope Settings page, you can see two DCs are
missing, as Figure 2 shows.

Figure 2: Discovering Two DCs Are Missing

On the Replication Status Collection Details tab, you can see the replication status of the DCs
that aren't missing, as shown in Figure 3.
Figure 3: Getting the DCs' Replication Status

By going to the Replication Status Viewer page, you can see any replication errors that are
occurring. As you can see in Figure 4, there are quite a few replication errors occurring in the
Contoso forest. Note that out of the five DCs, two of them can't see the other DCs, which
means replication isn't going to occur on the DCs that can't be seen. Therefore, users
connecting to the child DCs aren't going to have the most up-to-date information, which can
lead to problems.

Figure 4: Discovering Replication Errors

Because there are replication errors, it's helpful to use RepAdmin.exe to get a forest-wide
replication health report. To create the file, you can run the following command from
Cmd.exe:

Repadmin /showrel * /csv > ShowRepl.csv

Because there are problems with two of the DCs, you'll see two occurrences of LDAP error
81 (Server Down) Win32 Err 58 on the screen when the command executes. We'll deal with
those errors later on. For now, open up the ShowRepl.csv in Excel and follow these steps:

1. From the Home menu, click Format as table and choose one of the styles.
2. While holding down the Ctrl key, click both column A (Showrepl_COLUMNS) and
column G (Transport Type). Right-click somewhere in those columns and select Hide.
3. Reduce the width of the remaining columns (if needed) so that column K (Last Failure
Status) is visible.
4. For column I (Last Failure Time), click the down arrow and deselect 0.
5. Look at the date in column J (Last Success Time). This is the last time that replication
was successful.
6. Look at the errors in column K (Last Failure Status). These errors will be same as
what you saw in the AD Replication Status Tool.

You can also run the RepAdmin.exe tool from PowerShell. To do so, follow these steps:

1. Go to a PowerShell prompt and run the command:

Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

2. In the grid window that appears, select Add Criteria, select Last Failure Status, and
press Add.

3. Select the blue underlined word contains in the filter and select does not equal.

4. As shown in Figure 5, type a 0 in the box so that it filters out everything with a 0
(success) and shows only the errors.

Figure 5:
Showing Only the Errors When Running RepAdmin.exe from PowerShell

Now that you know how to check the replication status and discover any errors, let's look at
how to troubleshoot and resolve the four most common errors.

Troubleshooting and Resolving AD Replication Error -2146893022

Let's start with resolving error -2146893022, where DC2 is failing to replicate to DC1. From
DC1, run the following Repadmin command to check the replication status of DC2:
Repadmin /showrepl dc2

Figure 6 shows the results, which indicate that replication is failing because DC2's target
principle name is incorrect. However, error descriptions like this can be misleading, so you
need to dig deeper.

Figure 6: Troubleshooting AD Replication Error -2146893022

First, you should determine whether there's basic LDAP connectivity between the machines.
To check this, run the following command from DC2:

Repadmin /bind DC1

As Figure 6 shows, you're getting an LDAP error. Next, try to initiate AD replication from
DC2 to DC1:

Repadmin /replicate dc2 dc1 "dc=root,dc=contoso,dc=com"

Once again, you see the same principle name error, as shown in Figure 6.

If you open the Event Viewer on DC2, you'll see Event 4, as shown in Figure 7.
Figure 7: Reviewing Event 4 in Event Viewer

The highlighted text in the event indicates the reason for the error. What this means is that
DC1's computer account password is different than the password stored in AD for DC1 on
the Key Distribution Center (KDC), which in this case, is running on DC2. So, the next task
is to determine whether DC1's computer account password matches what is stored on DC2.
From a command prompt on DC1, run the following two commands:

Repadmin /showobjmeta dc1 "cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com" > dc1objmeta1.txt

Repadmin /showobjmeta dc2 "cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com" > dc1objmeta2.txt

Afterward, open the dc1objmeta1.txt and dc1objmeta2.txt files that were created and look at
the version differences for dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, and
lmPwdHistory. In this case, the dc1objmeta1.txt file lists the version as 19, whereas the
version in the dc1objmeta2.txt file is 11. So, comparing these two files reveals that DC2 has
old password information for DC1. The Kerberos operation failed because DC1 was unable
to decrypt the service ticket presented by DC2.
The KDC running on DC2 can't be used for Kerberos with DC1 because DC2 has the old
password information. To resolve this problem, you must force DC2 to use the KDC on DC1
so the replication will complete. To do so, you first need to stop the KDC service on DC2:

Net stop kdc

Then, you need to initiate replication of the Root partition:

Repadmin /replicate dc2 dc1 "dc=root,dc=contoso,dc=com"

Next, you should run the two Repadmin /showobjmeta commands again to verify the versions
are the same. If all is well, you can restart the KDC service:

Net start kdc

Troubleshooting and Resolving AD Replication Error 1908

Now that the -2146893022 error is fixed, let's move on AD replication error 1908, where
DC1, DC2, and TRDC1 failed to replicate from ChildDC1. To troubleshoot this problem, you
can use Nltest.exe to create a Netlogon.log file to determine the cause of error 1908. First,
enable verbose logging on DC1 by running the command:

Nltest /dbflag:2080fff

Now that logging is enabled, you need to initiate replication on the DCs so that any errors are
logged. It's helpful to run three commands to reproduce the errors. First, run the following
command on DC1:

Repadmin /replicate dc1 childdc1 dc=child,dc=root,

dc=contoso,dc=com

As you can see in Figure 8, the results indicate that replication is failing because the domain's
DC couldn't be found.

Figure 8: Troubleshooting AD Replication Error 1908

Second, from DC1, try to locate the KDC in the child.root.contoso.com domain using the
command:

Nltest /dsgetdc:child /kdc

The results in Figure 8 indicate that there's no such domain.

Third, because you can't find the KDC, try to reach any DC in the child domain using the
command:

Nltest /dsgetdc:child

Once again, the results indicate that there's no such domain, as shown in Figure 8.

Now that you reproduced the errors, you need to review the Netlogon.log file that has been
created in the C:\Windows\debug folder. Open the file in Notepad and look for the entry that
begins with "DSGetDcName function called". Note that there will be multiple entries with
this call. You need to find the entry that has the same parameters you specified in the Nltest
command (Dom:child and Flags:KDC). The entry you're looking for will look like:

DSGetDcName function called: client PID=2176,

Dom:child Acct:(null) Flags:KDC

You should review the initial entry as well as subsequent entries in that thread. Table 2 shows
a sample 3372 thread.

Table 2: Sample 3372 Thread

Thread
Date Time Category Message Text
ID
ROOT: DSGetDcName function called:
date time MISC 3372 client PID=2176, Dom:child Acct:(null)
Flags:KDC
NetpDcInitializeContext:
date time MISC 3372
DSGETDC_VALID_FLAGS is c07ffff1
Received ping from
date time MAILSLOT 3372 DC(DC1.root.contoso.com)
child.root.contoso.com (null) on
Ping from DC1 for domain
date time CRITICAL 3372 child.root.contoso.com child for (null) on
is invalid since we don't host
NetpDcGetDcNext: _kerberos_
tcp.Boulder._sites.dc._
date time CRITICAL 3372
msdcs.child.root.contoso.com:
Cannot Query DNS. 9002 0x232a
NetpDcGetNameIp:
date time CRITICAL 3372 child.root.contoso.com: No data returned
from DnsQuery
NetpDcGetName: NetpDcGetNameIp for
date time MISC 3372
child.root.contoso.com returned 1355
NetpDcGetName: child.root.contoso.com:
date time CRITICAL 3372
IP and Netbios are both done
 Table 2: Sample 3372 Thread
Thread
Date Time Category Message Text
ID
Root: DsGetDcName function returns
date time MISC 3372 1355 (client PID=2176): Dom:child
Acct:(null) Flags:KDC

In Table 2, you can see the DNS lookup failure for the KDC SRV record in the child domain.
Error 1355 indicates that the specified domain either doesn't exist or couldn't be contacted.

Because you're trying to contact Child.root.contoso.com, the next step is to try pinging it
from DC1. You'll likely get an error stating that it can't find the host.

The information from the Netlogon.log file and the ping test points to a possible problem in
DNS delegation. Because you suspect this is the problem, you can test the DNS delegation by
running the following command on DC1:

Dcdiag /test:dns /dnsdelegation > Dnstest.txt

Figure 9 shows a sample Dnstest.txt file. As you can see, there's a DNS problem. The IP
address 192.168.10.1 is supposed to be the address for DC1.

Figure 9: Looking for Problems in the Dnstest.txt File

To resolve the DNS problem, follow these steps:

1. On DC1, open up the DNS Management console.

2. Expand Forward Lookup Zones, expand root.contoso.com, and select child.
3. Right-click the (same as parent folder) Name Server record and choose Properties.
4. Select lamedc1.child.contoso.com and click the Remove button.
5. Select Add so that you can add the valid child domain DNS server to the delegation
settings.
6. In the Server fully qualified domain name (FQDN) box, type the correct server of
childdc1.child.root.contoso.com.
7. In the IP Addresses of this NS record box, input the proper IP address of
192.168.10.11.
8. Click the OK button twice.
9. Select Yes in the dialog box that opens asking if you want to delete the glue record
lamedc1.child.contoso.com [192.168.10.1]. (A glue record is a DNS A record for the
name server authoritative for the delegated zone.)
10. Use Nltest.exe to verify you can locate the KDC in the child domain. Use the /force
option so that the Netlogon cache is not used:
Nltest /dsgetdc:child /kdc /force

11. Test AD replication from ChildDC1 to DC1 and DC2. This can be done two different
ways. The first approach is to run the command:

Repadmin /replicate dc1 childdc1 "dc=child,dc=root,

dc=contoso,dc=com"

The other approach is use the Microsoft Management Console (MMC) Active Directory Sites
and Services snap-in, in which case you right-click the DC and choose Replicate Now, as
shown in Figure 10. You need to do this for DC1, DC2, and TRDC1.

Figure 10: Testing AD Replication from the Active Directory Sites and Services Snap-In

When doing this, you'll receive the dialog box shown in Figure 11. Ignore it and click OK.
(I'll discuss this error shortly.)
 Figure
11: Receiving an Error When Using the Replicate Now Option

After completing these steps, go back to the AD Replication Status Tool and refresh the
forest-wide replication status. Error 1908 should no longer be present. The error you'll see is
error 8606 (Insufficient attributes were given to create an object), as noted Figure 11. This is
the next problem to resolve.

Troubleshooting and Resolving AD Replication Error 8606

A lingering object is an object that's present on one DC but has been deleted (and garbage
collected) on one or more other DCs. AD replication error 8606 and Directory Service event
1988 are good indicators of lingering objects. It's important to note that AD replication might
complete successfully and not log an error from a DC containing lingering objects because
replication is based on changes. If there are no changes to any of these objects, there's no
reason to replicate them. For this reason, when cleaning up lingering objects, you should
assume that all DCs have it, not just the DCs logging errors.

To troubleshoot this problem, you first need to confirm the error by running the following
Repadmin command on DC1:

Repadmin /replicate dc1 dc2 "dc=root,dc=contoso,dc=com"

You should see an error message like that in Figure 12.

Figure 12: Confirming There's a Lingering Object Using RepAdmin.exe

You'll also see event 1988 logged in DC1's Event Viewer, as shown in Figure 13. Note that
event 1988 only reports the first lingering object that was encountered. There usually are
many more of these objects present.

Figure 13: Confirming There's a Lingering Object in Event Viewer

You need to copy down three items from the event 1988 information: the lingering object's
globally unique identifier (GUID), the source DC, and the partition's distinguished name
(DN). With this information, you can determine which DCs have this object.

First, use the object's GUID (in this case, 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) in the
following Repadmin command, which sends its results to the Objects.txt file:

Repadmin /showobjmeta * "" > Objects.txt

If you open the Objects.txt file, you'll see that any DC that returns replication metadata for
this object contains one or more lingering objects. DCs that don't have a copy of this object
report the status 8439 (The distinguished name specified for this replication operation is
invalid).

Next, you need to obtain DC1's Directory System Agent (DSA) object GUID and identify all
lingering objects in the Root partition on DC2. (The DSA provides access to the physical
store of directory information that's located on a hard disk. In AD, the DSA is part of the
Local Security Authority process.) To do this, run the command:

Repadmin /showrepl DC1 > Showrepl.txt

In Showrepl.txt, DC1's DSA object GUID will appear at the top of the file and look like this:

DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e

With this information, you can use the following command to verify the existence of
lingering objects on DC2 by comparing its copy of the Root partition with DC1's Root
partition.

Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4-

b7ca-7fa71d4ca13e "dc=root,dc=contoso,dc=com"
/Advisory_mode

You can then review the Directory Service event log on DC2 to see if there are any lingering
objects. If there are, each one will be reported in its own event 1946 entry. The total count of
lingering objects for the partition that was checked will be reported in an event 1942 entry.

You can remove lingering objects a couple of ways. The preferred method is to use
ReplDiag.exe. Alternatively, you can use RepAdmin.exe.

Using ReplDiag.exe. From your administration workstation in the forest root domain (in this
case, Win8Client), you should run the following two commands:

Repldiag /removelingeringobjects
Repadmin /replicate dc1 dc2 "dc=root,dc=contoso,dc=com"

The first command removes the objects. The second command verifies that the replication
completed successfully (i.e., error 8606 is no longer logged). You can rerun the Repadmin
/showobjmeta commands discussed previously to ensure the object was removed from all the
DCs. If you have a read-only domain controller (RODC) and it contained this lingering
object, you'll notice it's still there. The reason is that the current version of ReplDiag.exe
doesn't remove objects from RODCs. To cleanup on the RODC (in this example, ChildDC2),
you can run the command:

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
"dc=root,dc=contoso,dc=com" /Advisory_mode

You should then review the Directory Service event log on ChildDC2 and look for event
1939. As Figure 14 shows, it notifies you that the lingering objects have been removed.
Figure 14: Receiving Notification That the Lingering Objects Have Been Removed

Using RepAdmin.exe. Another way to remove lingering objects is use only RepAdmin.exe.
You first need to remove the lingering objects from the reference DCs using the code shown
in Listing 1.

Listing 1: Commands to Remove Lingering Objects from the Reference DCs

REM Commands to remove the lingering objects

REM from the Configuration partition.

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
"cn=configuration,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
"cn=configuration,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"cn=configuration,dc=root,dc=contoso,dc=com"

REM Commands to remove the lingering objects

REM from the ForestDNSZones partition.

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc1.child.

root.contoso.com 0b457f73-96a4-429b-ba81-
1a3e0f51c848 "dc=forestdnszones,dc=root,
dc=contoso,dc=com"

REM Commands to remove the lingering objects

REM from the Root domain partition.

Repadmin /removelingeringobjects dc1.root.

contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
"dc=root,dc=contoso,dc=com"

REM Command to remove the lingering objects

REM from the DomainDNSZones partition.

Repadmin /removelingeringobjects dc1.root.

contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
"dc=root,dc=contoso,dc=com"

Afterward, you must remove the lingering objects from all the remaining DCs. (Lingering
objects might be referenced, or shown, on multiple DCs, so you need to make sure you
remove them as well.) Listing 2 shows the commands to use for this purpose.

Listing 2: Commands to Remove Lingering Objects from the Remaining DCs

REM Commands to remove the lingering objects

REM from the Configuration partition.

Repadmin /removelingeringobjects dc1.root.

contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"cn=configuration,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects dc2.root.

contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"cn=configuration,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"cn=configuration,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects trdc1.treeroot.

fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"cn=configuration,dc=root,dc=contoso,dc=com"

REM Commands to remove the lingering objects

REM from the ForestDNSZones partition.

Repadmin /removelingeringobjects dc1.root.contoso.

com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects dc2.root.contoso.

com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects trdc1.treeroot.

fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=forestdnszones,dc=root,dc=contoso,dc=com"

REM Command to remove the lingering objects

REM from the DomainDNSZones–Root partition.

Repadmin /removelingeringobjects dc2.child.root.

contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
"dc=domaindnszones,dc=root,dc=contoso,dc=com"

REM Commands to remove the lingering objects

REM from the Child domain partition.

Repadmin /removelingeringobjects dc1.root.contoso.

com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=child,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects dc2.root.contoso.

com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=child,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=child,dc=root,dc=contoso,dc=com"

Repadmin /removelingeringobjects trdc1.treeroot.

fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=child,dc=root,dc=contoso,dc=com"

REM Command to remove the lingering objects

REM from the DomainDNSZones-Child partition.

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
"dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com"

REM Commands to remove the lingering objects

REM from the TreeRoot domain partition.

Repadmin /removelingeringobjects childdc1.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=treeroot,dc=fabrikam,dc=com"

Repadmin /removelingeringobjects childdc2.child.root.

contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=treeroot,dc=fabrikam,dc=com"

Repadmin /removelingeringobjects dc1.root.contoso.com

0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=treeroot,dc=fabrikam,dc=com"

Repadmin /removelingeringobjects dc2.root.contoso.com

0b457f73-96a4-429b-ba81-1a3e0f51c848
"dc=treeroot,dc=fabrikam,dc=com"
As you can see, using ReplDiag.exe is much easier to use than RepAdmin.exe because you
have far fewer commands to run. The more commands that need to run, the more chances
there are for typos, missing commands, or command-line errors.

Troubleshooting and Resolving AD Replication Error 8453

The previous AD replication errors dealt with a DC not being able to find other DCs. AD
replication error 8453 occurs when a DC can see other DCs, but it can't replicate with them.

For example, suppose that the ChildDC2 (an RODC) in the child domain isn't advertising
itself as a Global Catalog (GC) server. To get the status of ChildDC2, you can run the
following command on ChildDC2:

Repadmin /showrepl childdc2 > Repl.txt

This command sends its results to Repl.txt. If you open this text file, you'll see the following
at the top:

Boulder\ChildDC2
DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC
WARNING: Not advertising as a global catalog

If you look closely at the Inbound Neighbors section, you'll see that the
DC=treeroot,DC=fabrikam,DC=com partition is missing because it isn't being replicated. If
you look the bottom of the file, you'll see the error:

Source: Boulder\TRDC1
******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30
Last error: 8453 (0x2105):
Replication access was denied
Naming Context: DC=treeroot,DC=fabrikam,DC=com

This error indicates that ChildDC2 is unable to add a replication link for the Treeroot
partition. As Figure 15 shows, this error is also recorded in the Directory Services event log
on ChildDC2 as event 1926.
Figure 15: Reviewing Event 1926 in Event Viewer

At this point, you need to check for any security-related problems. To do this, you can use
DCDiag.exe:

Dcdiag /test:checksecurityerror

Figure 16 shows an excerpt from the DCDiag.exe output.

Figure 16: Reviewing DCDiag.exe Output for Security-Related Problems

As you can see, you're receiving error 8453 because the Enterprise Read-Only Domain
Controllers security group doesn't have the Replicating Directory Changes permission.

To resolve this problem, you need to add the missing access control entry (ACE) to the
Treeroot partition. To do so, follow these steps:

1. On TRDC1, open ADSI Edit.

2. Right-click DC=treeroot,DC=fabrikam,DC=com and choose Properties.
3. Select the Security tab.
4. Review the permissions on this partition. Notice that there are no entries for the
Enterprise Read-Only Domain Controllers security group.
5. Click Add.
6. In the Enter the object names to select box, type ROOT\Enterprise Read-Only
Domain Controllers.
7. Click the Check Names button, then choose OK if the object picker resolves the
name.
8. In the Permissions for Enterprise Read-Only Domain Controllers dialog box, clear the
Allow check boxes for the following permissions:

 Read
 Read domain password & lockout policies
 Read Other domain parameters

9. Select the Allow check box for the Replicating Directory Changes permission, as
shown in Figure 17. Click OK.
 Figure 17: Adding the Missing
ACE to the Treeroot Partition

10. Manually initiate the Knowledge Consistency Checker (KCC) to immediately

recalculate the inbound replication technology on ChildDC2 by running the
command:

Repadmin /kcc childdc2

This command forces the KCC on each targeted DC to immediately recalculate the inbound
replication topology, thereby adding the Treeroot partition again