Delve deeper into ExBPA's architecture and configuration files
Last month, in "The Exchange Best Practices Analyzer," InstantDoc ID 44793, Paul Robichaux explained how to obtain and use Exchange Server Best Practices Analyzer (ExBPA), a Microsoft tool that scans Exchange servers and reports on numerous settings so that you can optimize your Exchange configuration. Here, I continue the discussion by describing the ExBPA architecture and the mechanism by which ExBPA maintains and updates its rules and configuration data.
ExBPA's roots can be traced to a couple of "unofficial" Microsoft tools that have been available for some time: ExConfig (which provides details about Exchange configuration changes on servers) and ExDiag (which reports about Exchange configuration and topology throughout an organization). Microsoft defines ExBPA as a diagnostic tool that gathers configuration information about an Exchange organization, performs specific tests against the organization's configuration, compares the test results against a baseline of best practices, and reports its findings. You can use ExBPA to perform a health check against an organization, identify settings that have been changed from the default, highlight less-than-optimal configuration settings, and compare servers against a baseline. ExBPA compares settings on Exchange systems with Microsoft-recommended best practices for configuration and can thus identify potential problems in an Exchange organization. Of course, a health-check tool that compares real-life servers against a set of rules is only as useful and valid as the rules and configuration data that are built into the tool; furthermore, best practices don't materialize overnight but instead develop over time. Therefore, Microsoft has designed ExBPA so that it checks for new rules and configuration data regularly (by default, every time ExBPA is started).
Microsoft plans to update the ExBPA rules and configuration files frequently (at least every few weeks). The configuration files define the operation of ExBPA, determining what data is collected and how it's analyzed. Microsoft will change the ExBPA binaries somewhat less frequently but will probably release new versions of ExBPA (available at http://www.microsoft.com/exchange/exbpa) about every 4 months. In fact, shortly before publication time, Microsoft shipped ExBPA 1.1, which I discuss later.
ExBPA Architecture and Operation
ExBPA contains several architectural components—namely, a dispatcher, collectors, and an analyzer. The dispatcher drives the collector and analyzer components and takes as its input configuration information, which is effectively the best-practices rules that ExBPA uses for its processing.
ExBPA collectors interrogate the systems you're scanning (i.e., Active Directory—AD—and Exchange servers) and return information to ExBPA. The collectors gather much of this data from diverse sources such as Windows Management Instrumentation (WMI), AD, the registry, the Microsoft IIS metabase, Performance Monitor counters, ports, and DNS. However, some of the data might be generated by tests that ExBPA applies to various components—for example, communications with SMTP virtual servers. ExBPA might access many AD servers during a scan operation to duplicate the behavior of the scanned Exchange servers, which also access numerous AD servers. (Note that ExBPA can scan Exchange Server 5.5 servers for some types of data, but because Exchange 5.5 servers don't support WMI, the scan results will be less comprehensive than for servers running later Exchange versions.) Collectors run in a multithreaded fashion, and as many as 50 Exchange servers (from up to 10 administrative groups) can be scanned at the same time.
When the collectors have returned the data to the ExBPA dispatcher, it invokes the analyzer, which processes the returned data and compares it against the rules in the configuration file. The analyzer then produces an XML file that provides a report about the health of your Exchange messaging environment. You can view the report file within ExBPA or save it for further processing.
By default, ExBPA writes the output XML file and a log file for each scan to system drive:\documents and settings\profile name\application data\microsoft\exbpa, where system drive is the drive on which Windows is installed and profile name is the username under which you're currently logged on to the workstation. You can change the default location for the XML output and log files by setting a registry value. To do so, open the registry editor and navigate to the HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExBPA subkey and create (or modify) the ImportExportDirectory entry (type REG_STRING). Double-click the entry and set its value to the directory name of your choice.
ExBPA's configuration information is contained in the exbpa.config.xml file, which is in the ExBPA installation directory. There are actually two versions of the configuration file: one in the common installation directory and one in the language-specific subdirectory. The language-specific version is the one that ExBPA typically uses; the common installation directory version is a placeholder that ExBPA uses only when no language-specific file is available.
Whenever ExBPA is started, it performs a check to determine whether a newer configuration file is available and, if it finds one, notifies you so that you can download it. You can opt not to download the new file and continue working with the existing configuration file. Downloading the new configuration file can take several minutes, depending on your Internet connection. During the download, you'll see a status box that shows the download's progress on the ExBPA main screen, which Figure 1 shows. You can also manually check for an updated configuration file at any time by clicking Update Exchange Server Best Practices Analyzer on the main screen.
If the system on which ExBPA is running can't connect to the Internet to determine whether a new configuration file is available, it times out within 5 minutes. While ExBPA is attempting to connect to the Internet, you can't run any ExBPA scans. To avoid the timeout problem, you can set a registry value that suppresses the updated–configuration-file check at start-up. To do so, navigate to the HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExBPA subkey and create (or modify) the VersionCheckAlways entry (type REG_DWORD). Double-click the new entry and set its value to 0.
The process of determining whether a new exbpa.config.xml file is required is straightforward, and you can do so manually or let ExBPA do so automatically. Near the beginning of the local exbpa.config.xml file (about line 50) on the system on which ExBPA is running is a line that defines the current file version. For example, the version of exbpa.config.xml that ships with ExBPA 1.0 is 188.8.131.52 (as of publication time, the current configuration-file version was 184.108.40.206). You can find the most recent version of exbpa.config.xml at http://www.microsoft.com/exchange/code/exbpa/1.0/en/exbpa.config.xml. (You can replace the en—for English—in the URL with the appropriate language-specific identifier, such as ja, for Japanese.)
The system on which ExBPA is running can use an HTTP proxy server to access the Internet for configuration-file updates. However, if you use authentication with the HTTP proxy server or use Microsoft Internet Explorer's (IE's) autoproxy functionality, ExBPA can't retrieve updated configuration files because of a problem in the Windows .NET Framework. Microsoft expects to provide a workaround for this problem in a future version of ExBPA. Similarly, if you block Internet access (even via an HTTP proxy) from the system running ExBPA, ExBPA can't retrieve updated configuration files.
If for any reason ExBPA can't use the automated download mechanism and you know that a more up-to-date configuration file is available, you can manually copy it from the ExBPA Web site and install it on the ExBPA management workstation. To do so, perform these steps:
- Rename the existing exbpa.config.xml file in the appropriate language-specific subdirectory to something like exbpa.config.xml.old.
- Go to http://go.microsoft.com/fwlink/?linkid=34290 and download the Update file to a local computer.
- Execute the downloaded file (exbpaupdate.exe); it's an autoextracting .zip file that creates a set of folders for the supported language-specific versions. Copy the new exbpa.config.xml file into both the common installation directory and the appropriate language-specific subdirectory on the ExBPA management workstation.
Be aware that the folders that exbpaupdate.exe creates will also contain an updated ExBPA Help file—called exbpa.chm—for each language-specific version. Exbpa.chm contains updated Help information and updated ExBPA knowledge base articles (more about the knowledge base in a moment). You should also copy exbpa.chm from the newly created folders into the appropriate language-specific subdirectory.
The ExBPA configuration file includes a knowledge base that contains comprehensive technical information about the problems that an ExBPA scan might uncover and the analysis rules ExBPA uses. After it finishes a scan, ExBPA displays one or more messages about best-practices issues it has identified in your Exchange organization, similar to the message that Figure 2 shows. If you click the Tell me more about this issue and how to resolve it link for an issue that ExBPA reports, ExBPA displays the issue-related technical details that the configuration file contains. This knowledge base is similar to having an advanced, tailored, and always-up-to-date version of TechNet available as a troubleshooting resource for your Exchange system. Figure 3 shows the detailed knowledge base information about the problem that's mentioned in Figure 2.
ExBPA Versions and Compatibility
If you look at ExBPA's About box (to do so, click About Exchange Server Best Practices Analyzer in the left pane of the main ExBPA window), you'll see two version numbers, as Figure 4 shows. The first number (1.0.7412.0 in Figure 4), identifies the particular build of ExBPA but isn't related to the configuration-file version. The second number (220.127.116.11 in Figure 4) is the configuration-file version number. Each number in the configuration file version has a specific meaning:
- The first number (1) identifies the application version.
- The second number (5) identifies the major configuration version—primarily, it's the version of the schema used in the configuration file.
- The third number (7) identifies the minor configuration version. Updated configuration files that maintain the same schema but have updated rules will have different minor configuration versions.
- The fourth number (1) identifies the release type: 0 means that the configuration file comes from an ExBPA installation kit; 1 means that the configuration file comes from a Web download.
As Microsoft releases updated configuration files, ExBPA might use them to reanalyze information it found in previous data-collecting scans of Exchange servers, thereby providing a better, more accurate analysis of such data if it's compatible with the new configuration file. Updated configuration files and data obtained in earlier scans are compatible if the first two components of the version number associated with the scan (i.e., the version of the configuration file that was used with the scan) and the first two components of the updated configuration-file version are identical. If you've saved an earlier scan and subsequently downloaded an updated configuration file that isn't compatible with that scan, ExBPA can't reanalyze the scan data and will display the old scan-analysis results for the earlier scan.
Microsoft has updated the configuration file a number of times since it released ExBPA. In the first month following the release of ExBPA, for example, Microsoft released four new versions of the exbpa.config.xml file on the ExBPA Web update site. Besides offering evidence of update frequency, the updated releases reveal the type of updates that Microsoft has made. Table 1 lists recent updated versions of the configuration file and a brief description of the nature of the update. Although the flurry of update activity in the weeks following the tool's initial release isn't surprising, such activity nonetheless demonstrates Microsoft's commitment to keeping the ExBPA configuration file updated and also the relative ease with which you can apply the enhancements in the updates.
Microsoft recently shipped version 1.1, the most recent version of ExBPA. ExBPA 1.1 provides a direct in-place upgrade from ExBPA 1.0 and includes a number of improvements, mostly related to usability. For example, in ExBPA 1.1, you can define the directory in which ExBPA will place output XML files and assign to a particular scan operation a label that's included in the output XML file. Mailbox counts—which originally used domain controllers (DCs)—now use the Global Catalog (GC) server, which makes such counts more accurate. Furthermore, ExBPA validates user credentials (if they're supplied) at start-up instead of when the first scan is executed.
ExBPA 1.1 includes the most recent exbpa.config.xml and exbpa.chm files. In addition, during the update checking process at ExBPA start-up, ExBPA now checks for new binaries as well as new configuration files. If ExBPA detects new binaries, it can automatically download them and perform an in-place upgrade of the tool. The ExBPA main screen provides a new Cancel this check option, which you can select to avoid this update check. Additionally, Microsoft has updated and reworded much of the text in the ExBPA interface and the various rules files to simplify the user experience.
A Best-Practices Package
ExBPA doesn't automatically solve problems, but it does help you identify them—with the aid of its configuration files and regularly updated best-practices database. As knowledge and best practices evolve for Exchange operations, it's comforting to know that Microsoft has conveniently packaged this knowledge so that you can put it to work in your Exchange environment to highlight potential problems. ExBPA spans a wide gamut of Exchange configuration areas and will probably highlight issues in most production Exchange environments. Even if you're supremely confident that your Exchange environment is optimally configured, you have nothing to lose from running ExBPA against your systems and very likely much to gain.