Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
When a replication problem rear its ugly head, it can be tricky to determine the exact cause and solution. Typically, the favorite tool for diagnosing replication problems is REPLMON. However, there is another replication diagnostic tool called REPADMIN that is also useful. In this article, I give you a crash course in how to use it.
What is REPADMIN?
REPADMIN is a built-in Windows diagnostic command-line utility that works at the Active Directory level. Although specific to Windows, it is also useful for diagnosing some Exchange replication problems, since Exchange Server is Active Directory based.
REPADMIN doesn't actually fix replication problems for you. But, you can use it to help determine the source of a malfunction.
Checking replication status
You can use REPADMIN to verify whether or not replication between domain controllers is occurring. For example, imagine that you recently made a change to one of the account attributes on a domain controller named Server1. If you suspected that your network might be having replication problems, you would be wondering if the update had been replicated to Server2. This is where REPADMIN comes in.
Active Directory associates a number known as the USN with any change made to it. If you wanted to know if the change you made to Server1 had been replicated to Server2, you could simply check to see if both servers listed the same USN numbers for the account. (You could also check the various date/time stamps.)
Let's try it:
- Enter the REPADMIN command followed by the /SHOWMETA switch.
- List the distinguished name of the object that you want to check, enclosed in quotation marks.
- Now enter the fully qualified domain name (FQDN) of the domain controller you want to run the check against.
To see how this command works, let's go back to my earlier example in which we looked at a user account on a server named Server2. For the sake of the example, let's assume that the user account is named Brien; it and the domain controller exist within a domain named brienposey.com.
The command would look something like this:
REPADMIN /showmeta "cn=Brien,cn=Users,dc=brienposey,dc=com" Server2.brienposey.com
Checking replication connections
If you run the command listed above and receive an error message, or the USN numbers are not in sync, you could look into whether or not the domain controllers are listed as a part of Active Directory's replication topology.
You can accomplish this by entering the REPADMIN /SHOWCONN switch followed by the FQDN of the domain controller you want to check.
For example, you could run the /SHOWCONN command against both domain controllers to verify that they display the same replication topology and that no errors are reported.
Checking replication errors
One of REPADMIN's most useful functions is the abilty to provide specific information related to replication errors.
To list any current replication errors, enter the REPADMIN command followed by the /SHOWREPS switch and the FQDN of the domain controller you want to check.
You will see a listing of each different inbound connection and its status. For example, you might see a message indicating that a connection from Server2 via RPC was successful.
Ideally, each connection will report a successful previous replication attempt. However, if replication has failed, you will receive a rather vague error message. Here are a few of the more common errors and what they mean:
| Error Message |
Cause of the Error |
| No inbound neighbors |
The domain controller that you are testing was
unable to establish an inbound replication connection to another domain
controller. |
| Access is Denied |
A replication connection exists between the two
domain controllers, but a security problem is preventing the connection
from being used. |
| Last Attempt at <date/time> failed with the
target account name is incorrect |
This error is usually related to a DNS resolution
problem. |
| No more end points |
The DNS server probably contains a record for the
domain controller, but the domain controller's host record lists an
incorrect IP address. |
| LDAP error 49 |
The domain controller with the computer account
might not be synchronized with the Key
Distribution
Center.
|
| Cannot Open an LDAP Connection to Local Host |
The REPADMIN tool can't contact the Active
Directory. This problem can relate to network connectivity problems, DNS
name resolution failures, or to an incorrectly configured firewall. |
| AD replication has been preempted |
The last replication cycle was interrupted by a
manual replication request. |
| Replication Posted, Waiting |
The domain controller has issued a replication
request and is waiting for replication to complete. This usually means
that replication is currently in progress. |
| Last attempt @never was successful |
A replication link has been created, but
replication never occurred. This can be caused by an overloaded bridgehead
server or by an incorrectly configured replication schedule. |
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Tip: Watch out for replication failures in mixed Exchange environments
Reference Center: Exchange replication tips and resources
