In-Depth

Top 5 Free Microsoft Tools for Active Directory Health

How to evaluate the health of an Active Directory implementation with instrumentation built right into the platform.

• By Gary Olsen
• 07/02/2012

Active Directory health assessment is a challenge, especially for small and midsize companies that can't afford a full-time Active Directory admin or costly third-party tools.

The first indication that Active Directory isn't healthy is when a flood of calls comes to the help desk indicating a potential crisis is brewing. Fortunately, Active Directory is amazingly self-healing, and can run even when it isn't 100 percent healthy. Unfortunately, this usually aids in hiding problems that should be fixed by IT staff who are busy putting out other fires.

I recall a number of years ago when I was contacted by a staffer who said a domain controller wasn't replicating. Upon examination of the logs, I discovered that this DC hadn't replicated for three years.

Here are five basic tools that can be used to provide a quick Active Directory health assessment. All of them are free and relatively easy to use.

1. Active Directory Best Practices Analyzer
With the Active Directory Best Practices Analyzer (ADBPA) tool provided by Microsoft in Windows Server 2008 R2, it seemed that Microsoft was going to unlock the treasure chest of health secrets for Active Directory. After all, the Exchange Best Practices Analyzer (ExBPA) is well-known and well-used among admins, myself included. I was expecting detailed reporting and a very thorough analysis of Active Directory best practices that would translate into a good troubleshooting tool like ExBPA. ADBPA falls short of the mark, at least for troubleshooting, but it does offer some good value. ADBPA appears under the Active Directory Domain Services role in Server Manager, as shown in Figure 1.

[Click on image for larger view.]

Figure 1. The Active Directory Domain Services role in Server Manager provides recommended configurations, task best practices and online resources.

Note that you can click on each entry and get a description below the listing. This example shows all green checks indicating the DC is compliant with the ADBP listing. It will show errors and warnings as well. It checks to ensure all primary DCs are configured to a valid time source; all domains have two functioning DCs; all organizational units (OUs) are protected from accidental deletion; when last backups were executed; DNS is configured correctly; and file replication service (FRS) replication and Group Policy replication are working.

ADBPA is a good place to start as an overview, but details are obviously lacking. For instance, it doesn't display information about Active Directory replication or if any DCs haven't replicated over a period of time (like tombstone lifetime). While it indicates if DNS is working to allow clients to connect, there's nothing to indicate which DNS server might be incorrectly configured.

2. MPS Reports
In the early days of Windows 2000, Microsoft released the Microsoft Product Support (MPS) Reports diagnostic script first to Microsoft partners, then later to the general public. I've utilized MPS Reports for many years, and it's a cornerstone in any Active Directory health assessment or troubleshooting effort. It's a free download from bit.ly/LGivyL. Simply select the x86 or x64 version for the system you're running it on and save the MPSReports.exe to a computer. When you run the MPSReports.exe, the dialog shown in Figure 2 will appear. Note that MPS Reports requires admin privileges to gather the correct information, and requires the following components as prerequisites: the Microsoft .NET Framework 2, Windows PowerShell 1.0, Windows Installer 3.1 and Microsoft Core XML Services 6.0.

[Click on image for larger view.]

Figure 2. This dialog box lets the administrator select which computer is experiencing a problem.

Note that the dialog seems to indicate you can install MPS Reports on another computer -- but actually this is just a handy way to find the .NET Framework and Windows PowerShell components, save them on the current computer and copy them to a Windows Server 2003, Windows XP or Windows Vista machine. The MPSReports.exe must be copied and run locally on each computer that it will be used on.

Figure 3 shows the menu of diagnostics to be run. Previously, there were several versions of MPS Reports, for Networking, SQL, Exchange, Active Directory and more. Now it's all one package and you choose what you need to run. For Active Directory issues, I'd recommend checking General, Internet and Networking, Business Networks, Server Components and Exchange Servers (if Exchange is involved).

[Click on image for larger view.]

Figure 3. Administrators can select which diagnostics to run or they can select a separate configuration file.

Clicking on "Link to more info" will display the files collected so you know what MPS Reports is gathering. This is helpful not only for security but for troubleshooting, so you know what will be collected. Click "Next" to begin collecting diagnostic data. This will take a while.

The value of MPS Reports is that it runs a bunch of command-line tools and produces the results in a simple, easy-to-find file. Besides the tools I'm discussing in this article, there are many command-line tools that gather invaluable data. MPS Reports gathers it so you don't have to type and file data. For instance, MPS Reports collects Event Logs in TXT, ECTX and CSV formats. My favorite is the CSV format. In Excel, it's easy to search and sort to find error text, error-level events, event IDs and so forth. Along with the TXT version, the CSV displays the description of events for apps -- so when reading it on your laptop, you can see the event description without loading the app (such as Exchange or SQL).

Here's a tip: When diagnosing multiple servers or DCs, make a single Excel file and include the worksheet from MPS Reports for each machine in that file. It makes finding them a lot easier. If you open separate Excel files from the same instance of Excel, you can copy worksheets between the files. Right-click on the tab and select "Move or Copy." In the Move or Copy dialog, in the dropdown list To Book: select new book, check the "Create a copy" box and hit OK. This will open a new Excel file, to which you should copy the worksheet. Repeat for each worksheet you want to include and then save the combined file with a descriptive name. Note that this only works if you open all Excel files from the same Excel instance.

MPS Reports allows saving of the CAB file to a location of your choice, or you can open it up immediately (see Figure 4). In the CAB file there will be one or more XML files (see Figure 5, that provide a graphical view of the various reports so you don't have to run all the tiny reports one by one.

[Click on image for larger view.]

Figure 4. Once the diagnostics have run, administrators can save, e-mail or view the results.

[Click on image for larger view.]

Figure 5. A CAB file displaying XML files listing various reports

Understanding MPS Reports isn't rocket science. Where I work we have an internal tool, written by one of my colleagues, that's actually more useful than MPS Reports because we can send someone an e-mail with a request for a feature and he implements it. This makes it extremely customizable. In addition, our version doesn't have all the requirements for .NET Framework components and is a bit cleaner and faster than MPS Reports. One of the big drawbacks in running a report like this is in gathering the event logs. Our version allows a switch to exclude the security log, which not only makes data collection faster but also doesn't compromise the security requirements of some companies (which prevent security logs from leaving the company). This is important if a third-party support engineer is diagnosing the event logs. So if you wanted to lose the restrictions of MPS Reports, you could have a talented programmer develop a similar tool for your purposes.

3. Repadmin and Replsum
Repadmin, as a rule, is the most powerful command-line tool for Active Directory troubleshooting. The Replication Summary option, or Replsum command, displays an overview of the replication status of all DCs in all domains in the forest. In terms of an Active Directory health check, it's imperative to know if all DCs are replicating -- and for those that aren't, you'll want to know the last time they did replicate and why they stopped.

The Repadmin command can quickly and clearly answer these questions. This is a valuable time saver as opposed to the commonly used Repadmin/showrepl, which details each DC in a long listing. The Replsum option looks at all DCs in all domains in the forest and puts them in an easy-to-read table. Use the command:

Repadmin /bysrc /bydest sort:Delta >repadmin.txt

There are other options and formats for this command, but this is the only one I've ever used and it works well. Table 1 shows a sample output.

Note that the Source DC list shows outbound replication and the Destination DC list shows inbound. For example, in the top list, WTEC-DC2 is a Source DC and it hasn't replicated for more than five days. This is outbound replication because WTEC-DC2 is the source when the error is reported. Likewise, WTEC-DC1 is failing for inbound replication in the lower list because it's the Destination DC. The cause of both failures is event 1722: The RPC server is unavailable. This error usually means there's some physical connectivity failure at that DC.

Here's a tip: If replication hasn't occurred for tombstone lifetime days, the "largest delta" entry will show "> 60 days." This indicates that the DC should not be brought back online because it could introduce lingering objects. Manually demote and re-promote the DC.

4. DCDiag /Test:DNS
Besides replication, the other most common cause of Active Directory failure is DNS. DNS can often cause replication failure. The problem is that many environments install DNS servers on all Active Directory DCs, and there are many ways DNS can fail. Examining each one is time-consuming. In the Windows Server 2003 time frame, Microsoft added the /Test:DNS option to the DC diag command. Execute this command as follows:

DCDiag /Test:DNS /e /v >DcdiagDNS.txt

This command will analyze every DNS server it finds on the network and test DNS server authentication, basic connectivity, configuration of forwarders, delegation, dynamic registration and resource record registration. For the latter, DCDiag creates a test Resource Record and tries to register it. If this fails, new records aren't able to be registered (which will cause other failures).

It will record three potential results: Pass, Fail or Warn. Warn means it isn't a failure but should be investigated. For instance, Warn under the dynamic registration (DYN) column means the secure dynamic updates are not enabled. This isn't a failure, but you should be sure this is what you want.

Table 2 shows typical output for this command.

Table 2 shows a complete, concise report of all DNS servers in all domains in the network, in terms of the six DNS tests just described. This provides a good DNS health check. This table appears at the end of the DCDiag output. Details on these tests for each server are included in the DCDiag report prior to this summary table. If the user who ran the command doesn't have privileges in a domain, the tests will all fail.

In this case, the user context under which DCDiag ran did not have privileges in the EMEA domain, so the tests all failed. "N/A" appears when prior tests fail and the rest of the tests are dependent. For instance, in EMEA-DC03, there's a Fail for the Auth and Basc tests. The rest of the tests show N/A. Because the Auth and Basc tests fail, the others will fail also. DCDiag doesn't test further and puts N/A in the column. The Ext column is a fifth test for checking external connectivity. The DCDiag /Test:DNS doesn't test this by default.

Here's a tip: The listing of domains and DCs in the table is a handy display of all domains in the forest and all DCs (that are DNS servers) in each domain. This is a quick map of the domain structure and the DCs. Most environments make all DCs DNS servers, so this is a nice way to see the domain and DC structure.

5. DNSCMD Command-Line Tool
If you're working on a remote system for an environment you're not familiar with -- or if you just want details about the DNS environment you work in -- the DNSCMD command-line tool will provide a wealth of information. Note that I need this level of detail because I'm diagnosing problems with no access to the environment, and I have to depend on reports to paint the picture. The commands I use are presented in Table 3. I'd recommend trying them even if you have access to the DNS server; sometimes it's easier to look at a report rather than clicking through the DNS UI. Also, if these reports are periodically filed, it's nice to go back and compare a problem report with a known good one -- especially if someone changes the config and you want to know what it was when it worked! Of course, these commands can be scripted.

There are other tools, such as the Group Policy Management Console (GPMC), that are great for analyzing Group Policy. The GPMC also allows a Group Policy Object to be saved as a report in HTML format to send to a support engineer for analysis. The GPMC is not included in MPS Reports.

Staying Healthy
These free tools should provide a quick Active Directory health report and give advance warning of trouble. Of course, it does require effort by an admin to actually run the reports, but it's an easy process -- especially if you use MPS Reports. In conclusion, my advice is to:

1. Use the ADPBA tool as a 35,000-foot overview of Active Directory.
2. Download and run MPS Reports to get logs, event logs and reports to dig deeper for problem resolution.
3. Run DCDiag /Test:DNS, Repadmin and Replsum as described in this article to provide a quick, easy-to- understand snapshot of replication and DNS configuration for overall Active Directory health and pinpointed trouble spots.
4. Use DNSCMD to provide detailed DNS configuration information for offline analysis and comparison to previously known good configurations.

No one ever said managing Active Directory was easy. But applying these best practices should go a long way toward better monitoring and managing of Active Directory, resulting in a secure environment for provisioning and administering user accounts.