Microsoft

Get IT Done: Look out for server problems disguised as Active Directory failures

Solve Active Directory failures by solving server problems


Because Active Directory is so complicated and so interrelated with other aspects of your network, nailing down what’s causing an Active Directory problem can sometimes be like nailing Jell-O to the wall. To make troubleshooting even more difficult, some server problems can manifest themselves as Active Directory failures, creating the proverbial mountain out of a molehill.

In this Daily Drill Down, I’ll explain how misconfigurations in programs such as Exchange 5.5, Proxy Server, or ISA Server can cause Active Directory problems.

How I learned my lesson
Several months ago, I went to change a setting in my Active Directory only to discover that I couldn’t open Active Directory Users and Computers. I assumed that the problem was a fluke and decided to reboot the server since it hadn’t been taken down in quite a while. When the server came back up, I tried to open Active Directory Users and Computers again only to find that the problem still existed. Then, I tried to open Active Directory Sites and Services and some of the other Active Directory tools. To my horror, none of the tools would open. Instead, I kept receiving an error message saying that a domain controller couldn’t be contacted. What made this so scary was that I was running these programs on the same domain controller that the utilities claimed didn’t exist.

Assuming that I had some sort of Active Directory problem, I decided to use the DCPROMO command to demote the server to a member server, and then use the DCPROMO command again to restore its domain controller status. Making this work required going to another server on the network; however, I was unable to open any of the Active Directory tools on that server, as well. I then attempted to access the Active Directory from every domain controller in my entire organization, which consists of two separate domains. Not a single domain controller in either domain would recognize that the Active Directory even existed. Panic set in.

As I struggled to understand what could cause such a catastrophic Active Directory failure, I decided to take a look at the last few things that were done to my network. This situation is a perfect example of why I’ve always recommended to my readers that they maintain a logbook for each server, detailing any maintenance action performed on the server.

As I looked over my logbooks, I realized that the most recent significant chore that had been performed on any of my servers was upgrading my Internet gateway server to Microsoft’s Internet Security and Acceleration (ISA) Server two weeks earlier. I hadn’t experienced any problems since upgrading to ISA Server, but according to my logbooks, I hadn’t done anything that required Active Directory access since the upgrade. At that point, my keen powers of deduction kicked in.

Rather than having a major Active Directory problem, all I had was a minor problem with ISA Server. This gave the illusion of a much bigger problem in Active Directory. Active Directory was still completely functional but appeared to be malfunctioning because ISA Server was interfering with my ability to view Active Directory. As I continued to research the problem, I discovered that the exact same problem could occur when using Microsoft’s Proxy Server 2.0.

ISA Server, Proxy Server, and the Active Directory
To understand why ISA Server and Proxy Server interfere with Active Directory, it’s necessary to consider how ISA Server and Proxy Server work. In a nutshell, both products allow you to connect your organization to the Internet. Typically, the ISA Server or Proxy Server is the only machine in the facility that’s directly connected to the Internet. Anytime another machine needs to access the Internet, the machine passes the request to the ISA Server or Proxy Server. The ISA Server or Proxy Server then submits the request to the Internet. When the results come back, the ISA Server or Proxy Server receives the results and passes them to the client who originally requested them.

Because of this, all communications with the Internet appear to have come from that server, regardless of their actual origin. Because the clients must interact with an ISA Server or a Proxy Server rather than interacting directly with the Internet, it is necessary for the clients to run a Proxy Client. A Proxy Client is a small program that runs in the background and redirects requests that would otherwise be bound for the Internet to the ISA Server or to the Proxy Server. Any machine wishing to access the Internet through the ISA Server or the Proxy Server must run this client. This applies to both servers and to workstations.

So what happens when a client needs to communicate with a Web server through a Proxy Server? The user opens a Web browser and enters the name of a Web site that he or she wants to visit. Upon entering the URL, the Proxy Client passes the request to the ISA Server or to a Proxy Server, which in turn tries to contact the appropriate Web site.

Now, consider the format of fully qualified domain names in an Active Directory environment. Microsoft has gone to great lengths to make the Active Directory domain structure resemble the Internet domain structure. For example, my organization is divided into two domains: production.com and test.com. Both of these domain names could easily refer to Internet domains (Web sites) rather than to internal domains.

With this in mind, let’s take a look at the problem once again. When I opened Active Directory Users and Computers, I was trying to access the production.com domain. However, my Proxy Client intercepted the request and forwarded it to the Internet, where the request was, of course, invalid.

Fixing the problem in a Proxy Server environment
Normally, when Proxy Server is running, you connect clients to the Proxy Server by running the Proxy Client Setup program, which can be found in the MSPCLNT directory on the Proxy Server. During the installation process, the Setup program copies all of the necessary files to the client machine and then creates a file on the client machine called MSPCLNT.INI. This file can be found in the MSPCLNT directory.

To solve the problem, add the LocalDomains= command to the [Common] section of the MSPCLNT.INI file. You can see an example of this command in Figure A.

Figure A
Add the LocalDomains= command to the [Common] section of the client's MSPCLNT.INI file.


As you add the command, there are a few important things to remember. First, the command is case sensitive. It must be typed exactly as shown in the figure. Second, each local domain must be preceded by a period. For example, the domain TEST.COM would be listed as .TEST.COM.

The other thing that you must remember is that, depending on your network configuration, Windows may try to update the MSPCLNT.INI file from time to time. If this happens, you’ll lose your changes. To prevent this, flag the file as Read Only.

Fixing the problem in an ISA Server environment
Like the Proxy Server solution, the ISA Server solution involves adding the LocalDomains= command to the [Common] section of the MSPCLNT.INI file. However, when dealing with ISA Server, there is a shortcut that you can use.

Open the ISA Management console and navigate through the console tree to Internet Security And Acceleration Server | Servers And Arrays | Firewall | Network Configuration | Local Domain Table. At this point, right-click on the Local Domain Table node and select the New | LDT Entry commands from the resulting context menu. When you do, you’ll see a dialog box that asks for the name and description of the local domain entry that you wish to add.

Rather than typing the domain names manually and risking a typo, I recommend using the Browse button to browse the network and select a domain. Once you’ve entered a domain name, click OK to add it to the Local Domain Table. Now, repeat the process for each additional local domain. When you’re done, the ISA Management console will look something like what you see in Figure B.

Figure B
Add your local domains to ISA Server's Local Domain Table.


Once you’ve updated the Local Domain Table, simply reinstall the Proxy Clients on the existing machines. Reinstalling the Proxy Client will update the MSPCLNT.INI file with the LocalDomains= command.

Exchange Server confusion
While not as common as Proxy Server and ISA Server interferences, versions of Exchange Server prior to Exchange 2000 can also cause Active Directory problems.

As you may know, all queries to the Active Directory are made through the Lightweight Directory Access Protocol (LDAP). LDAP is a compact version of the X.500-based Directory Access Protocol (DAP). LDAP was created for the purpose of simplifying directory service communications.

The problem with Windows 2000 using LDAP is that Windows 2000 wasn’t the first Microsoft product to use a directory service that relied on LDAP communications. Exchange Server 5.5 (and earlier) contains its own directory service that relies on LDAP communications.

What further complicates things is that the Exchange directory service and the Windows 2000 Directory service use the exact same LDAP port number by default. This means that if you were performing an Active Directory-intensive chore, such as upgrading to Exchange 2000, it may sometimes be impossible for the system to know which of the two directories to make updates to.

Therefore, I recommend changing the Exchange LDAP port number if you are using Exchange 5.5 or earlier. It’s best to change the LDAP port numbers before upgrading to Windows 2000. If you’ve already upgraded to Windows 2000, though, the process usually still works fine—just be sure to make backups of each server before changing the port number.

Note that all of your Exchange servers need to use the same LDAP port number. Therefore, when you change the LDAP port, it will change the port number for all of the Exchange servers in the site. If your organization has multiple Exchange server sites, however, you should seriously consider changing the port number for all sites for the sake of consistency.

To change the LDAP port number, open the Exchange Administrator program that comes with Exchange 5.5. When the Exchange 5.5 Administrator program opens, navigate through the tree structure to your organization | your site | Configuration | Protocols. When Protocols is selected, you’ll see a list of installed Exchange protocols in the column on the right. Double-click on the LDAP (Directory) Site Defaults protocol.

You’ll now see the LDAP (Directory) Site Defaults Properties. The LDAP services are set to use port number 389 by default. This is the same port number used by the Windows 2000 Active Directory. Therefore, you must change the port number to something other than 389. On my test servers, I selected 390, and it has been working fine for about a year now. When you’ve made the change, click OK.

Then you must stop and restart the Exchange services for the change to take effect. You can now rest assured that any Active Directory problems that you might experience aren’t related to the Exchange Server.

Conclusion
Active Directory problems aren’t always as severe as they might appear to be at first. Sometimes Active Directory problems aren’t even related to Active Directory itself. It’s possible for other Microsoft server products such as ISA Server, Proxy Server, and Exchange Server to interfere with a client’s ability to communicate with the Active Directory, thus providing the illusion of a huge Active Directory meltdown.

When Active Directory acts up, don’t go to pieces. First, you need to rule out any server problems that could appear as Active Directory failure. Once you’ve confirmed that ISA Server, Proxy Server, and Exchange Server are in working order—then you can panic.

Editor's Picks