Troubleshooting Logon Problems

Logging into a computer is such a routine part of the day that it is easy to not
even think about the login process. Even so, things can and occasionally do go
wrong when users log into Windows. In this article, I will talk about some of
the things that can cause logon failures, and show you how to get around those p
roblems.
Before I Begin
Before I get started, I just want to quickly mention that in order to provide as
much useful information as possible, I am going to avoid talking about the most
obvious causes of logon failures. This article assumes that before you begin t
he troubleshooting process, you have checked to make sure that the user is enter
ing the correct password, the user's password has not expired, and that there ar
e no basic communications problems between the workstation and the domain contro
ller.
The System Clock
It may seem odd, but a workstation's clock can actually be the cause of a logon
failure. If the clock is more than five minutes different from the time on your
domain controllers, then the logon will fail.
In case you are wondering, the reason for this has to do with the Kerberos authe
ntication protocol. At the beginning of the authentication process, the user ent
ers their username and password. The workstation then sends a Kerberos Authentic
ation Server Request to a the Key Distribution Server. This Kerberos Authenticat
ion Server Request contains several different pieces of information, including:
• The user’s identification
• The name of the service that the user is requesting (in this case it’s t
he Ticket Getting Service)
• An authenticator that is encrypted with the user’s master key. The user’
s master key is derived by encrypting the user’s password using a one way functi
on.
When the Key Distribution Server receives the request, it looks up the user’s Ac
tive Directory account. It then calculates the user’s master key and uses it to
decrypt the authenticator (also known as pre authentication data).
When the user’s workstation created the authenticator, it placed a time stamp wi
thin the encrypted file. Once the Key Distribution Server decrypts this file, it
compares the time stamp to the current time on its own clock. If the time stamp
and the current time are within five minutes of each other, then the Kerberos
Authentication Server Request is assumed to be valid, and the authentication pro
cess continues. If the time stamp and the current time are more than five minute
s apart, then Kerberos assumes that the request is a replay of a previously capt
ured packet, and therefore denies the logon request. When this happens, the foll
owing message is displayed:
The system cannot log you on due to the following error: There is a time differe
nce between the client and server. Please try again or consult your system admi
nistrator.
The solution to the problem is simple; just set the workstation’s clock to match
the domain controller’s clock.
Global Catalog Server Failures
Another major cause of logon problems is a global catalog server failure. A glob
al catalog server is a domain controller that has been configured to act as a gl
obal catalog server. Global catalog servers contain a searchable representation
of every object in every domain of the entire forest.
When the forest is initially created, the first domain controller that you bring
online is automatically configured to act as a global catalog server. The probl
em is that this server can become a single point of failure, because Windows doe
s not automatically designate any other domain controllers to act as global cata
log servers. If the global catalog server fails, then only domain administrators
will be able to log into the Active Directory.
Given the global catalog server’s importance, you should work to prevent global
catalog server failures. Fortunately, you can designate any or all of your domai
n controllers to act as global catalog servers. Keep in mind though that you sho
uld only configure all of your domain controllers to act as global catalog serve
rs if your forest consists of a single domain. Having multiple global catalog se
rvers is a good idea even for forests with multiple domains, but figuring out wh
ich domain controllers should act as global catalog servers is something of an a
rt form. You can find Microsoft’s recommendations here.
If your global catalog server has already failed, and nobody can log in, then th
e best thing that you can do is work to return the global catalog server to a fu
nctional state. There is a way of allowing users to log in even though the globa
l catalog server is down, but there are security risks associated with doing so.
If the Active Directory is running in native mode, then the global catalog serve
r is responsible for checking user’s universal group memberships. If you choose
to allow users to logon during the failure, then universal group memberships wil
l not be checked. If you have assigned explicit denials to members of certain un
iversal groups, then those denials will not be in effect until the global catalo
g server is brought back online.
If you decide that you must allow users to log on, then you will have to edit th
e registry on each of your domain controllers. Keep in mind that editing the reg
istry is dangerous, and that making a mistake can destroy Windows. I therefore r
ecommend making a full system backup before continuing.
With that said, open the Registry Editor and navigate through the registry tree
to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Now, create a new DW
ORD value named IgnoreGCFailures, and set the value to 1. You will have to resta
rt the domain controller after making this change.
DNS Server Failure
If you suddenly find that none of your users can log into the network, and your
domain controllers and global catalog servers seem to be functional, then a DNS
server failure might have occurred. The Active Directory is completely dependent
on the DNS services.
The DNS server contains host records for each computer on your network. The comp
uters on your network use these host records to resolve computer names to IP add
resses. If a DNS server failure occurs, then host name resolution will also fai
l, eventually impacting the logon process.
There are two things that you need to know about DNS failures in regard to troub
leshooting logon problems. First, the logon failures may not happen immediately.
The Windows operating system maintains a DNS cache, which includes the results
of previous DNS queries. This cache prevents workstations from flooding DNS serv
ers with name resolution requests for the same objects over and over.
In many cases, workstations will have cached the IP addresses of domain controll
ers and global catalog servers. Even so, items in the DNS cache do eventually ex
pire and will need to be refreshed. You will most likely start noticing logon pr
oblems when cached host records begin to expire.
The other thing that you need to know about DNS server failures is that often ti
mes there are plenty of other symptoms besides logon failures. Unless machines o
n your network are configured to use a secondary DNS server in the event that th
e primary DNS server fails, the entire Active Directory environment will eventua
lly come to a grinding halt. Although there are exceptions, generally speaking,
the absence of a DNS server on an Active Directory network basically amounts to
a total communications breakdown.
Conclusion
Although I have discussed some of the major causes of logon failures on Active D
irectory networks, an important part of the troubleshooting process is to look a
t how widespread the problem is. For example, if only a single host on a large n
etwork is having logon problems, then you can probably rule out DNS or global ca
talog failures. If a DNS or a global catalog failure were to blame, then the pro
blem would most likely be much more wide spread. If the problem is isolated to a
single machine, then the problem is most likely related to the machine’s config
uration, connectivity, or to the user’s account.
Troubleshooting Remote Desktop
Ever since the release of Windows XP, one of my favorite features as always been
Remote Desktop. In case you re not familiar with Remote Desktop, it is a built-
in Windows feature that allows you to connect to your computer remotely by using
the RDP protocol. For example, if you are at home and you need to access someth
ing from your computer at the office, you could use a Remote Desktop session to
remotely control your office PC from home. Remote Desktop is built on the same t
echnology, and uses the same protocol as the Windows Terminal Services.
As handy as Remote Desktop is, it can sometimes be problematic. While the sessio
ns are usually solid, there are a number of things that can go wrong during the
connection and authentication process. In this article, I will explore some vari
ous troubleshooting techniques that you can use when things go wrong with Remote
Desktop.
The Remote Computer Cannot be Found
Probably the most common Remote Desktop problem is that Remote Desktop has troub
le locating the remote PC. There are a number of things that can cause this prob
lem. Probably the simplest cause is misspelling the name of the remote computer.
Therefore, if you re having trouble connecting to remote computer, just take a
second and make sure that you ve spelled the remote machine s name correctly.
If the remote computer s name is spelled correctly, the problem may be DNS relat
ed. Remote Desktop uses the RDP protocol, which piggybacks on top of the TCP/IP
protocol. As you probably know, TCP/IP does not use computer names as a mechanis
m for identifying the systems. The only reason that it is possible to specify a
computer name is because a DNS server resolves the computer name to an IP addres
s.
If you find yourself having name resolution problems, there are a couple of diff
erent things that you can try. One option is to try using the remote system s fu
lly qualified domain name as opposed to its NetBIOS name. This won t always help
you to establish a connection, but in certain situations it will help.
Another option is to specify the remote machine’s IP address rather than its nam
e. Generally speaking, using an IP address tends to be much less problematic tha
n using a host name when connecting. Even IP addresses can be problematic, thoug
h.
The biggest factor that tends to make connecting with IP addresses problematic i
s the use of dynamic IP addresses. If you are using Remote Desktop to connect to
a server, this probably won t be an issue, because most servers use static IP a
ddresses. Workstations, on the other hand, almost always use dynamic IP addresse
s. Therefore, the IP address that your workstation is using today will probably
be assigned to a different workstation tomorrow. If the machine that you are con
necting to does use dynamic IP addresses, then you will practically have no choi
ce but to specify a host name when connecting rather than specifying the machine
s IP address.
Another factor that can make it difficult to connect to a host machine using rem
ote desktop is firewalls. The Remote Desktop Protocol is designed to work across
TCP port 3389. If you are attempting to connect to a remote machine that sits b
ehind a firewall, then the firewall must allow traffic to flow through TCP port
3389. Of course blindly opening this port on your firewall can pose a huge secur
ity risk. You might choose instead to enable port forwarding so that inbound RDP
traffic is forwarded to a specific IP address, rather than someone on the outsi
de being able to attempt an RDP connection to any machine on your network.
On many networks, you won t have a choice but to use port forwarding for RDP tra
ffic. The majority of networks use private IP addresses on their networks, and o
nly the router uses a public IP address. The router uses Network Address Transla
tion (NAT) to proxy traffic between the Internet and hosts on the private networ
k. If you are trying to establish an RDP connection from across the Internet wit
h a host that sits behind a NAT firewall, then you will have to configure the fi
rewall to forward RDP traffic to the target host.
Of course this assumes that you are attempting to establish a connection directl
y from outside the perimeter network. If you are connecting to the private netwo
rk using a VPN or a dial up connection, then you will have to worry about reconf
iguring a NAT firewall, because your VPN or dial-up connection provides you with
 a connection to the private network. The remote access server that is used for
establishing VPN or dial-up connections almost always sits behind a firewall, an
d you ll have to insure that this firewall allows RDP traffic to flow to the pri
vate network.
While I am on the subject of firewalls, I want to point out that Windows XP SP2
and Windows Vista both contain a built-in firewall. If you are attempting to est
ablish a connection to a machine running one of these operating systems, you ll
have to insure that the Windows firewall is configured to allow RDP traffic.
Authentication Problems
Establishing the initial connection is by far the most problematic aspect of Rem
ote Desktop, but there are other problems that you may encounter. Many users are
surprised to see that they can attach to a remote PC, and enter their credentia
ls, but are stopped by the following error message:
The local policy of the system does not permit you to log on interactively.
Windows displays this error message if the user who s logging lacks the necessar
y permissions to log in using the Remote Desktop Protocol. You can correct the p
roblem by adding the user account to the Remote Desktop Users group or to the lo
cal Administrators group.
Data Encryption
One of the most cryptic problems with Remote Desktop involves receiving the foll
owing error message:
Because of an error in data encryption, this session will end. Please try connec
ting to the remote computer again.
This error message is almost always related to using an outdated remote desktop
(or terminal service) client. When Microsoft released Windows 2000, they created
an add-on called the Administration Tool Pack. The Administration Tool Pack inc
luded a client component that could be used to establish a remote session. Altho
ugh this client initially appears to be compatible with Windows XP, it isn’t. Us
ing the Windows 2000 version of the Administration Tool Pack to establish a Remo
te Desktop session with Windows XP will usually trigger the error message that I
mentioned above.
Windows XP comes with its own Remote Desktop client that you can use to establis
h a connection with other machines that are running Windows XP. If you prefer us
ing the Administration Tool Pack though, then you can always upgrade to the Wind
ows Server 2003 version, which you can download at: http://support.microsoft.com
/kb/304718
Conclusion
Although Remote Desktop usually works fairly well, it can sometimes be difficult
to establish an initial connection. In this article, I have discussed some of t
he most common causes of Remote Desktop problems and some possible work arounds.
Troubleshooting a DHCP Server
If you use DHCP servers to automatically configure the TCP/IP settings for works
tations in your organization, a DHCP failure can lead to a major disruption in s
ervice. After all, if a workstation is not able to acquire an IP address, then i
t will have no way of accessing any of the resources on your private network or
on the Internet. In this article, I will discuss some techniques that you can us
e to troubleshoot DHCP server failures.
Inappropriate Address Assignment
One very common DHCP related issue is the assignment of an unexpected IP address
. For example, suppose that your DHCP server was configured with an IP address s
cope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigne
d IP addresses in this range. Now, suppose that a workstation on your network ap
peared to be having problems communicating with network servers. You issue an IP
CONFIG /ALL command to view the workstation’s IP address configuration. Instead
of the expected address range, the workstation has been assigned an address begi
nning with 169.254.
So what happened? If a host on your network is unexpectedly assigned an address
beginning with 169.254, you can rest assured that the address was not assigned b
y your DHCP server. What actually has happened, is that the workstation has fail
ed to contact a DHCP server. When this occurs, the workstation will assign itsel
f an IP address using a Windows feature known as Automatic Private IP Addressing
(APIPA).
Microsoft built Automatic Private IP Addressing into Windows as a way of helping
those who have very small networks. For example, if you were to create a small
Windows network, you would not have to manually configure IP addresses even if t
here were no DHCP server on the network. APIPA would automatically assign a uniq
ue class B IP address to each machine on the network. This is great for small ho
me networks but completely inappropriate for larger networks.
If a workstation resorts to using an APIPA assigned address, it is because its r
equests for an IP address have gone unanswered. There are several possible cause
s for this problem. Assuming that the other computers on the network are able to
acquire an IP address from your DHCP server, you can rule out the DHCP server a
s the cause of the problem.
More than likely, the issue is related to the networking hardware installed in t
he workstation that is having the problem. For example, the Network Interface Ca
rd might be assigned an incorrect driver. Another possible cause of the problem
is that the patch cable is not plugged into the Network Interface Card, or is no
t connected to a switch on the other end.
Of course, just because only one computer on the network is having trouble obtai
ning an IP address doesn’t completely rule out the server as the cause of the pr
oblem. If other workstations are successfully obtaining IP addresses, then you c
an be sure that the server is working properly. However, it could be that the se
rver has run out of IP addresses that it can assign to clients. You can easily t
ell if this is the problem by comparing the size of the DHCP address scope to th
e number of devices on your network that request IP addresses from the DHCP serv
er.
Common DHCP Server Problems
If multiple workstations are experiencing problems with leasing IP addresses, th
en the problem is most likely related to the DHCP server itself. If you suspect
that the DHCP server is the cause of the problem, then you might start off by do
ing some ping tests to verify that the DHCP server is able to communicate across
the network.
If the DHCP server is able to communicate with other computers on the network, t
hen I recommend verifying that the DHCP server has an IP address that is compati
ble with the scope that the server is configured to assign addresses from. For e
xample, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192
.168.0.50, then the server will not actually be able to assign those addresses u
nless the server itself has been assigned a static address in the same subnet ra
nge, such as 192.168.0.0 or 192.168.0.51.
If this still doesn’t solve the problem, then I recommend checking the basics.
For example, you should make sure that the DHCP server is still authorized by th
e Active Directory to lease IP addresses. You should also check to verify that t
he scope is active, and that the necessary services are running on the DHCP serv
er.
IP Address Conflicts
Another problem that I have seen on occasions involves IP address conflicts amon
g dynamically configured addresses. When you create a DHCP scope, it is the DHCP
server’s responsibility to make sure that addresses within the scope are only l
eased to one client at a time. If that’s the case, then how is it possible to ha
ve an IP address conflict for dynamically assigned addresses?
There are two situations that I’ve run into that can cause this problem. The fir
st time that I ever ran into this problem, I was able to determine which PCs had
been assigned at the duplicate addresses. When I checked the TCP/IP configurati
on on those machines, I found that one of the machine’s IP addresses had been ma
nually configured. It’s kind of a long story, but that machine’s user was runnin
g an unauthorized application that required a static IP address. The user got ti
red of having to reconfigure the application every time they used it, so they to
ok the address that had been dynamically assigned to them, and entered it as a s
tatic address.
The likelihood of this happening today is fairly slim. When a particular situati
on occurred, Windows 98 was the current operating system. Windows 98 lacks many
of the security features that we take for granted today. A properly secured work
station running Windows XP or Windows Vista should be resistant to end user reco
nfigurations. Even so, I wanted to at least mention this issue because it gives
you something to look for if you have trouble solving the problem.
A much more common cause of this problem is that multiple DHCP servers are in us
e, and those DHCP servers have overlapping scopes. If you only have a single DHC
P server on your network, do not make the mistake of immediately dismissing this
idea as a possible cause of your problem. In all likelihood, there is probably
a rogue DHCP server that is conflicting with your primary DHCP server.
Windows 2000 Server and Windows Server 2003 are both designed in such a way to p
revent rogue DHCP servers from causing problems. A DHCP server can only issue IP
addresses after it has been authorized by the Active Directory. The problem is
that this only applies to Windows-based DHCP servers. DHCP servers running other
operating systems are free to lease IP addresses to clients without having to b
e authorized by the Active Directory.
So has a user really gone through the trouble of installing a rogue, Linux based
DHCP server? Probably not. A much more likely explanation is that a wireless ac
cess point, or a router intended for cable or DSL Internet connections is causin
g your problem. Such devices almost always have DHCP server’s built in. These de
vices typically use a scope range of 192.168.0.x or 192.168.1.x. If this happens
to be the same IP address scope that your primary DHCP server uses, then you ma
y run into a situation in which both DHCP servers are issuing addresses from the
same address pool.
Conclusion
In this article, I’ve explained that there are a number of potential causes for
DHCP failures. In most cases, these failures are related to simple communication
s problems between the DHCP server and the workstations that are trying to lease
addresses.

Active Directory Troubleshooting Part

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 Dire
ctory, 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 lo
cal 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 com
ponent of the security subsystem. This component is called Ntdsa.dll and is acce
ssed 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) p
rotocol. 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 Act
ive Directory database is stored and updated on all other participating domain c
ontrollers 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 Act
ive Directory database. When you install Active Directory, for the most part eve
n if all the default settings are chosen, the replication process from domain co
ntroller 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) wit
h a domain controller in each location. Again, the benefit of having a domain co
ntroller 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 h
appen if the WAN link drops, the local PCs can still find a local domain control
ler 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 perf
ormance still needs to be monitored and analyzed. The health and maximized perfo
rmance of Active Directory depends on a smooth replication process. If you are h
aving 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 sto
p every problem from occurring, but hopefully after reading this article, you wi
ll be better equipped to handle issues and keep your network as optimized as pos
sible to handle the traffic traversing it.
Consider a common problem such as a failed network link. In figure 2, you see th
at 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 b
e interrupted. This of course stops the communication between domain controllers
, therefore also severing the replication process. This can prevent the synchron
ization 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 (suc
h as ISDN as seen in figure 2). ISDN (Integrated Services Digital Networks) is a
digital WAN technology used to facilitate connections between sites. More commo
nly used today for disaster recovery, ISDN still has a place in today’s marketpl
ace. Although still used, you don’t have to limit yourself to any technology whe
n 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 communica
tion with each other so that the Active Directory database stays synchronized an
d healthy. A common symptom of replication problems is that information is not u
pdated on some or all domain controllers. For example, a systems administrator c
reates a user account on one domain controller, but the changes are not propagat
ed to other domain controllers. In most environments, this is a potentially seri
ous problem because it affects network security and can prevent authorized users
from accessing the resources they require. You can take several steps to troubl
eshoot 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 conn
ected 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 documen
ted and tested to ensure that it’s connected. There are many tools you can use t
o 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 c
ommon. If you have verified that your replication topology is set up properly, y
ou should confirm that your servers are able to communicate over the network. Pr
oblems such as a failed dial-up connection attempt can prevent important Active
Directory information from being replicated. Learn how to use ping and other ICM
P based protocol troubleshooting tools in the links section at the end of this a
rticle.
Verifying Router and Firewall Configurations
When building a secure network, most times controls are placed on network device
s to filter the traffic going from place to place. The most commonly used tool t
o control traffic is a Firewall. A router or any other device that utilizes a fi
rewall feature set, or some other form of Access Control that stops access to an
d from other hosts connected can also be used. A firewall is usually dedicated t
o only protecting the perimeter so its been designed to do that, do not assume t
hat the use of a firewall stops any risk of you being attacked, it only minimize
s that risk.
Firewalls are used to restrict the types of traffic that can be transferred betw
een 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 da
ta from being transferred using SMTP, replication that uses this protocol will f
ail.
Network Ports Used by Active Directory Replication
RPC replication uses dynamic port mapping as per the default setting. When you n
eed 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 t
o 65536. Because of this configuration, a client will never need to know what po
rt 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 ho
w to use the Event Viewer. The Event Viewer can be very helpful when trying to l
ocate and resolve a replication problem. Many errors are reported to the Event V
iewer for your review.
Whenever an error in the replication configuration occurs, the computer writes e
vents 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 e
ntry 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 unavaila
ble" 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 "A
ccess denied" from the repadmin command
Note:
The link at the end of the article covers the explanation of these specific erro
rs and more.
Verifying Site Links
Before domain controllers in different sites can communicate with each other, th
e sites must be connected by site links. If replication between sites is not occ
urring properly, verify that the proper site links are in place. Verify your sit
e links by using the Replication diagnostics utility (Repadmin.exe). Use this to
ol 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 u
sing 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 Directo
ry domain controllers have their own read/write copies of the Active Directory d
atabase. Therefore, if connectivity does not exist, you will not encounter failu
res while creating new objects.
It is important to periodically verify that objects have been synchronized betwe
en domain controllers. This process might be as simple as logging on to a differ
ent domain controller and looking at the objects within a specific OU. This manu
al check, although it might be tedious, can prevent inconsistencies in the infor
mation stored on domain controllers, which, over time, can become an administrat
ion and security nightmare.
Verifying Authentication Scenarios
A common replication configuration issue occurs when clients are forced to authe
nticate across slow network connections. The primary symptom of the problem is t
hat users complain about the amount of time it takes them to log on to the Activ
e Directory (especially during times of high volume of authentications, such as
at the beginning of the workday). Usually, you can alleviate this problem by usi
ng 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 loc
ated 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 replica
tion topology is logically consistent. You can quickly and easily perform this t
ask 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 ale
rts you to the problem.
You can verify the Active Directory topology using the Active Directory Sites an
d Services tool.
Besides for ensuring that replication always continues, you can also learn how t
o monitor it as well. There are several ways in which you can monitor the behavi
or of Active Directory replication and troubleshoot the process if problems occu
r. In our next article we will look at the replication monitor and part III of t
his article will cover the system monitor.
Summary
In this article we covered the basics of replication, how it works, how to verif
y and troubleshoot it and what you can do to ensure that you Active Directory to
pology is healthy.