One of the best things about working with software is that it can be designed and built so that it's flexible and adaptable. Real-world physical objects are limited by their design and construction: The minivan my wife uses to take our kids to school can't morph into a sports car or a school bus. Software systems such as Exchange Server, on the other hand, can be deployed into a wide range of environments, but this flexibility raises the question of whether the software is being deployed properly. Not every administrator is aware of every nuance of Exchange setup and configuration. Microsoft has worked hard to build a product that "just works" in most situations, but it requires a fair amount of specialized knowledge to examine an Exchange server and see whether it's optimally configured.
As a secondary problem, consider what happens in midsized to large organizations. Humans aren't very good at repetitive tasks. Sure, we can do them, but tasks that require both attention to detail and repetition are especially difficult because we're easily bored. If someone walked into your office and asked you to examine every aspect of the Exchange configuration on one server, that wouldn't be too bad. On 10 servers, it would be somewhat tedious; on 400 servers, you'd probably go mad.
Microsoft has addressed both Exchange's complexity and the needs of organizations that have multiple servers with the release of the Exchange Server Best Practices Analyzer (ExBPA), an automated tool that runs on a Windows workstation and scans your Exchange servers for proper configuration. The tool checks more than 1200 distinct settings against a database of more than 1000 rules and produces a detailed report telling you what it found. Actually, there are two types of reports. First, the tool reports on problems it finds when checking your configuration against the rules database. Most problems link to pages on the Microsoft Web site that contain more information about the change needed. Some items are self-explanatory, but the ExBPA team is madly adding articles to flesh out the Web documentation. The report that ExBPA generates also contains some of the information found on the associated Web pages. The other type of report is a configuration snapshot of your Exchange environment, which gives you a way to view configuration changes over time. The snapshot report is an XML file that you can parse with your own tools or load into ExBPA on another machine. As ExBPA becomes more widely deployed, I expect to see Microsoft Product Support Services (PSS), Microsoft Consulting Services (MCS), and third-party consultants routinely asking for ExBPA reports as part of their initial troubleshooting procedures. Of course, ExBPA is no substitute for a detailed reporting package such as Ecora Reporter or Quest Software's Quest MessageStats.
How ExBPA Works
ExBPA obtains information in three primary ways:
- by making Windows Management Instrumentation (WMI) calls to the Exchange servers. WMI exposes a wealth of configuration and performance information, especially on Exchange Server 2003. For example, WMI provides an easy programmatic way to find out how many storage groups (SGs) and databases exist on a server or what the mailbox or public folder size limits are for a particular database.
- by looking up configuration parameters in Active Directory (AD). Recall that Exchange keeps its organizational configuration data (including the list of known Exchange servers, administrative groups, and routing groups) in the configuration naming context of the AD forest.
- by inspecting registry and metabase values on the Exchange servers. These values indicate which version of Exchange and related hotfixes are installed and contain some per-server configuration data that's not otherwise exposed. To scan a server's metabase remotely, your scanning machine must have the IIS Common Files component installed. It will if you've followed Microsoft's recommendation of installing the Exchange management tools on the workstation before you install ExBPA.
When you start an ExBPA scan, the tool begins by querying the domain controller (DC) that you specify; from this DC, it gets information about your Exchange topology. The tool then begins scanning individual servers by attempting to connect to each server and retrieve a registry key. If the connection attempt succeeds, the server will be queued for scanning. ExBPA will adjust the number of threads it uses to scan according to the number of Exchange servers that exist. A uniprocessor workstation can scan as many as 25 servers concurrently; a multiprocessor machine can scan as many as 50 servers at once.
This scanning takes a while, of course. In Microsoft's network, which features approximately 100 servers and excellent interserver bandwidth, a complete scan takes 2 to 3 hours. The exact time required to scan a server varies according to the load on that server, the load on the scanning machine, and the bandwidth available between them. Larger and more distributed environments can take up to 24 hours to scan.
Preparing to Use ExBPA
Microsoft has made ExBPA freely available at http://www.microsoft.com/exchange/downloads/2003/exbpa. After you download it, you can easily install it on any Windows Server 2003, Windows XP, or Windows 2000 machine, although Microsoft recommends running it on an XP or Win2K workstation. The machine you use must have network connectivity to the Exchange servers you want to scan, and you must have access to an account that has administrative privileges on each Exchange server you're scanning and at least View Only permissions on the Exchange organization.
ExBPA will scan Exchange 2003 and Exchange 2000 Server systems, and it will scan Exchange Server 5.5 servers in a mixed-mode organization—but if you have only Exchange 5.5, you're out of luck. ExBPA attempts to perform all scans and queries on all servers it can see, so it's normal to see some errors as ExBPA tries to test servers that don't support the queries it's making or for which you don't have administrative permissions. (Note that you can specify the account credentials to use when connecting to Exchange servers, so you don't have to log on using a privileged account.)
There seems to be some confusion about when you can, or should, run ExBPA. The ExBPA documentation says that you can use the tool for troubleshooting but points out that if it can't connect to a server, it won't be able to give you any useful information. Microsoft's recommendation is that you plan on using ExBPA for regular proactive health checks, using the data it gathers to pinpoint and fix any problems before they get out of control and cause data loss or other problems.