In this three part series we will cover ways to monitor and

troubleshoot common problems with Active Directory.

Although listing ways to troubleshoot Active Directory could
easily span into a 3 volume book set, we will cover the most
common issues and solutions here within these articles.
Whether you are already a pro, or just a beginner – these tips
should serve you well. In Part 1 of this article series we will
cover replication traffic and how to monitor and troubleshoot
it with tips and tools.

• Published: Dec 22, 2005

• Updated: Dec 22, 2005
• Section: Articles & Tutorials :: Network
Troubleshooting
• Author: Robert J. Shimonski
• Printable Version
• Adjust font size:
• Rating: 3.4/5 - 144 Votes

• 1
• 2
• 3
• 4
• 5

"For a complete guide to security, check out 'Security+ Study Guide and DVD Training
System' from Amazon.com"

If you would like to be notified when Robert Shimonski releases Active Directory
Troubleshooting Part 1, please sign up to our Real-time article update newsletter.
Monitoring and Troubleshooting Active Directory
Replication
Replication may be defined as a duplicate copy of similar data on the same or a different
platform or system. When using a directory service such as Active Directory, the
directory database is carried by all domain controllers so that when you want to contact a
domain controller for use, there is always a local copy local for use so that requests do
not have to be sent over the wide area network (WAN). Replication for Active Directory
operates within the directory service component of the security subsystem. This
component is called Ntdsa.dll and is accessed through the Lightweight Directory Access
Protocol (LDAP). Ntdsa.dll runs as a part of the local security authority (LSA), which
runs as Lsass.exe. Updates are transported over Internet Protocol (IP) by the remote
procedure call (RPC) protocol. The Simple Mail Transfer Protocol (SMTP) is also
available for use as well, although it’s more common to see RPC over IP used.

When considering Active Directory, replication takes place and a copy of the Active
Directory database is stored and updated on all other participating domain controllers on
your network and in a perfect world, each copy of the database is the same and all
domain controllers are synchronized. If this happens, then all your domain controllers are
synchronized with an exact duplicate copy of the Active Directory database. When you
install Active Directory, for the most part even if all the default settings are chosen, the
replication process from domain controller to domain controller is automatic and
practically transparent. For the most part, domain controllers handle the replication
processes without advanced configuration and most times, without a problem.

In figure 1, you can see a common network (2 sites connected via a WAN link) with a
domain controller in each location. Again, the benefit of having a domain controller local
to your PC’s at each network segment is to have requests made of the domain controller
kept local to the PC’s in need of its services to speed up requests (by keeping them local)
or in case of disaster recovery, which could happen if the WAN link drops, the local PCs
can still find a local domain controller to use. Keeping traffic off the wide area network
(WAN) and containing it to the local area network (LAN) is the best design practice you
can implement.
Figure 1: A Common Wide Area Network (WAN)

As a systems administrator, you should still consider that Active Directory performance
still needs to be monitored and analyzed. The health and maximized performance of
Active Directory depends on a smooth replication process. If you are having problems
with replication, you will know not only from blatant logging in your Event Viewer, but
from poor performance as well. Many times, you cannot stop every problem from
occurring, but hopefully after reading this article, you will be better equipped to handle
issues and keep your network as optimized as possible to handle the traffic traversing it.

Consider a common problem such as a failed network link. In figure 2, you see that the
main wide area network link has been broken.
Figure 2: A Failed Network Link

ISP’s and telecom service providers occasionally have problems and service can be
interrupted. This of course stops the communication between domain controllers,
therefore also severing the replication process. This can prevent the synchronization of
information between domain controllers and possibly cause corruption and/or other
problems.

A good way to make sure that this doesn’t happen is to set up a backup link (such as
ISDN as seen in figure 2). ISDN (Integrated Services Digital Networks) is a digital WAN
technology used to facilitate connections between sites. More commonly used today for
disaster recovery, ISDN still has a place in today’s marketplace. Although still used, you
don’t have to limit yourself to any technology when it comes to backup links, you can use
a fractional or full T1, a DSL line, or any other technology that allows you to have
redundancy in your links. The goal is to have redundant links to keep your domain
controllers in constant communication with each other so that the Active Directory
database stays synchronized and healthy. A common symptom of replication problems is
that information is not updated on some or all domain controllers. For example, a systems
administrator creates a user account on one domain controller, but the changes are not
propagated to other domain controllers. In most environments, this is a potentially serious
problem because it affects network security and can prevent authorized users from
accessing the resources they require. You can take several steps to troubleshoot Active
Directory replication; each of these is discussed in the following sections.

Verifying Network Connectivity

In order for replication to work properly in distributed environments, you must have
network connectivity. Although ideally all domain controllers would be connected by
high-speed and redundant LAN or WAN links, this is rarely the case for larger
deployments and for most companies that utilize slow WAN links that aren’t recoverable
from a disaster. Always make sure your network topology is documented and tested to
ensure that it’s connected. There are many tools you can use to verify connectivity such
as Ping and Tracert which come with just about every operating system ever created that
runs TCP/IP.

In real world deployments, analog/dial-up connections and slow connections are

common. If you have verified that your replication topology is set up properly, you
should confirm that your servers are able to communicate over the network. Problems
such as a failed dial-up connection attempt can prevent important Active Directory
information from being replicated. Learn how to use ping and other ICMP based protocol
troubleshooting tools in the links section at the end of this article.

Verifying Router and Firewall Configurations

When building a secure network, most times controls are placed on network devices to
filter the traffic going from place to place. The most commonly used tool to control
traffic is a Firewall. A router or any other device that utilizes a firewall feature set, or
some other form of Access Control that stops access to and from other hosts connected
can also be used. A firewall is usually dedicated to only protecting the perimeter so its
been designed to do that, do not assume that the use of a firewall stops any risk of you
being attacked, it only minimizes that risk.

Firewalls are used to restrict the types of traffic that can be transferred between networks.
Their main use is to increase security by preventing unauthorized users from transferring
information. In some cases, company firewalls may block the types of network access
that must be available in order for Active Directory replication to occur. For example, if a
specific router or firewall prevents data from being transferred using SMTP, replication
that uses this protocol will fail.

Network Ports Used by Active Directory Replication

RPC replication uses dynamic port mapping as per the default setting. When you need to
connect to an RPC endpoint during Active Directory replication, RPC uses TCP port
135. RPC on the client contacts the RPC endpoint mapper on the server at a well-known
port and RPC randomly allocates high TCP ports from port 1024 to 65536. Because of
this configuration, a client will never need to know what port to use for Active Directory
replication; it will just take place seamlessly. There are also other ports assigned for
Active Directory replication. There are as follows:

Protocol Port
LDAP udp 389
tcp 389
LDAP (SSL) udp 636
tcp 636
Kerberos udp 88
tcp 88
DNS udp 53
tcp 53
SMB over IP udp 445
tcp 445
Global Catalog Server tcp 3269
tcp 3268

Examining the Event Logs:

Errors, if they occur, will show up in the Event Viewer logs. At the end of this article, I
have placed a link to the Microsoft Website so that you can learn how to use the Event
Viewer. The Event Viewer can be very helpful when trying to locate and resolve a
replication problem. Many errors are reported to the Event Viewer for your review.

Whenever an error in the replication configuration occurs, the computer writes events to
the Directory Service and File Replication Service (FRS) event logs. By using the Event
Viewer administrative tool, you can quickly and easily view the details associated with
any problems in replication. For example, if one domain controller is not able to
communicate with another to transfer changes, a log entry is created.

You may receive events such as:

• Event ID 1311 in the directory service log

• Event ID 1265 with error "DNS Lookup Failure" or "RPC server is unavailable"
in the directory service log. Or, received "DNS Lookup Failure" or "Target
account name is incorrect" from the repadmin command
• Event ID 1265 "Access denied," in directory service log. Or, received "Access
denied" from the repadmin command

Note:
The link at the end of the article covers the explanation of these specific errors and more.

Verifying Site Links

Before domain controllers in different sites can communicate with each other, the sites
must be connected by site links. If replication between sites is not occurring properly,
verify that the proper site links are in place. Verify your site links by using the
Replication diagnostics utility (Repadmin.exe). Use this tool to verify correct site links
and to display inbound and outbound connections. You can also use it to display the
replication queue. You can get the tool by using the link at the end of this article.

Verifying That Information Is Synchronized

It’s often easy to forget to perform manual checks regarding the replication of Active
Directory information. One of the reasons for this is that Active Directory domain
controllers have their own read/write copies of the Active Directory database. Therefore,
if connectivity does not exist, you will not encounter failures while creating new objects.

It is important to periodically verify that objects have been synchronized between domain
controllers. This process might be as simple as logging on to a different domain
controller and looking at the objects within a specific OU. This manual check, although it
might be tedious, can prevent inconsistencies in the information stored on domain
controllers, which, over time, can become an administration and security nightmare.

Verifying Authentication Scenarios

A common replication configuration issue occurs when clients are forced to authenticate
across slow network connections. The primary symptom of the problem is that users
complain about the amount of time it takes them to log on to the Active Directory
(especially during times of high volume of authentications, such as at the beginning of
the workday). Usually, you can alleviate this problem by using additional domain
controllers or reconfiguring the site topology. A good way to test this is to consider the
possible scenarios for the various clients that you support. Often, walking through a
configuration, such as “A client in Domain A is trying to authenticate using a domain
controller in Domain B, which is located across a very slow WAN connection,” can be
helpful in pinpointing potential problem areas.

Verifying the Replication Topology

The Active Directory Sites and Services tool allows you to verify that a replication
topology is logically consistent. You can quickly and easily perform this task by right-
clicking the NTDS Settings within a Server object and choosing All Tasks => Check
Replication Topology. If any errors are present, a dialog box alerts you to the problem.

You can verify the Active Directory topology using the Active Directory Sites and
Services tool.

Besides for ensuring that replication always continues, you can also learn how to monitor
it as well. There are several ways in which you can monitor the behavior of Active
Directory replication and troubleshoot the process if problems occur. In our next article
we will look at the replication monitor and part III of this article will cover the system
monitor.

Summary
In this article we covered the basics of replication, how it works, how to verify and
troubleshoot it and what you can do to ensure that you Active Directory topology is
healthy. Stay tuned for more to come!

If you would like to be notified when Robert Shimonski releases Active Directory
Troubleshooting Part 1, please sign up to our Real-time article update newsletter.

Links and Reference Material

Cisco: Understanding ISDN
http://www.cisco.com/warp/public/2/ISDN.html
http://www.cisco.com/warp/public/129/27.html

Using Tracert
http://www.windowsnetworking.com/articles_tutorials/Using-Tracert.html

Using Pathping
http://www.windowsnetworking.com/articles_tutorials/Using-Pathping.html

RFC 792: Internet Control Message Protocol

http://www.faqs.org/rfcs/rfc792.html

RFC 1050: Remote Procedure Call Protocol specification

http://www.faqs.org/rfcs/rfc1050.html

MSDN on RPC
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnanchor/html/rpcank.asp

Restricting Active Directory Replication Traffic to a Specific Port

http://support.microsoft.com/default.aspx?scid=224196

The Microsoft Event Viewer

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/9
7339b5b-54d1-49a6-9475-7f67ac40aea0.mspx

Explanation of Common Replication Errors

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/2
2764cb5-9860-4f8f-95e7-337df24edf74.mspx
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedire
ctory/maintain/opsguide/part1/adogd12.mspx

Using Repadmin
http://support.microsoft.com/?kbid=249256
http://support.microsoft.com/kb/229896/EN-US/

About Robert J. Shimonski

Robert J. Shimonski (MCSE, etc) is an entrepreneur, a technology consultant

and a published author with over 20 years of experience in business. Robert's specialties
include network management, wide and local area network design and architecture,
security analysis and designing storage (SAN) related technologies. Robert also has many
years of experience deploying and engineering Linux and Unix based systems such as
Red Hat and Sun Solaris. Robert can be found online at www.shimonski.com.

Click here for Robert J. Shimonski's section.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on
WindowsNetworking.com! Choose between receiving instant updates with the Real-Time
Article Update, or a monthly summary with the Monthly Article Update. Sign up to the
WindowsNetworking.com Monthly Newsletter, written by Dr. Tom Shinder, containing
news, the hottest tips, Networking links of the month and much more. Subscribe today
and don't miss a thing!

• Real-Time Article Update (click for sample)

• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)
Latest articles by Robert J. Shimonski
• Pre-Installation Steps for Installing Windows Server 2008
• Using Tracert
• File System Planning for Active Directory 101
• Window Server 2003 R2, what’s new with Active Directory?
• Using Pathping

Related links
• LDAP and Exchange port conflict
• A quick look at the Windows 2003 support tools
• ADSI queries fails at 2 minutes
• ILS directory service for NetMeeting
• Windows 2000 Exchange Server in the DMZ

Featured Links*
Get a free Windows SIP Server / IP PBX
IP Telefonanlage, VOIP Telefooncentrale, Centralino Telefonico IP, PABX-IP, Centralita
Telefonica VOIP, Centrala Telefoniczna, Telefonni system, IP telefonvaxel, Central
Telefonica IP, VOIP Telefonsentral, IP telefonanlaeg, IP Puhelinvaihde, Telefon Sistemi,
IP PBX (Russian), IP PBX (Greek), IP PBX (Japanese), IP PBX (Korean), IP PBX
(Simplified Chinese), IP PBX (Traditional Chinese), IP PBX (Arabic)
Optimize the benefits of VDI to printing.
Try UniPrint VDI Edition for easy local and remote desktop access, fast printing and
secure delivery. Find out how UniPrint simplifies printer management and saves up to
90% bandwidth consumption.
ManageEngine OpManager - The Complete Network Monitoring Software
Monitor WAN infrastructure, LAN, Servers, Switches, Routers, Services, Apps, CPU,
Memory, AD, URL, Logs, Printers. Satisfies your entire Network infrastructure
Management needs.
Event log monitoring and management: Why do the dirty work yourself?
Be served with the events that matter and automatically monitor and manage Windows
event logs, W3C logs, Syslog events and SNMP Traps. Download a free trial today!
Citrix burning a hole in your pocket?
Get 2X ApplicationServer - unlimited - for $995