SolutionBase: Optimize your Exchange organization with the Best Practices Analyzer

Exchange is a very complex system to run and maintain properly. It's easy to overlook important security settings as well as other things. Here's how you can use the Best Practices Analyzer to make sure you've properly configured your Exchange Server.

Few people would argue with the statement that Exchange Server is one of the most complex products Microsoft has ever created. The question, though, is how do you ensure that it's running an optimum configuration and that it's secure and stable? Until recently, about the only thing you could do was make sure you stayed current with the updates and used MOM to monitor the server's performance. Even so, MOM was more of a reactive tool than a proactive one.

While I still believe in using MOM to monitor servers, Microsoft has recently released another tool you can use to scan your Exchange Servers to ensure that they're running an optimum and nonproblematic configuration: the Microsoft Exchange Best Practices Analyzer (BPA). In this article, I'll tell you all about how to use this new tool.

Acquiring BPA

The BPA tool is available for download from the Microsoft Web site for free. The download consists of a 2.5-MB, self-extracting executable file.

I won't bore you with a step-by-step description of the installation process, but there are two things you need to know prior to installing the BPA tool. First, you should install BPA onto a workstation, not onto one of your Exchange Servers. Technically, the tool will install on an Exchange Server, but the results of its scan will be unpredictable. In some cases, BPA is unable to communicate with the server. In other cases, you'll get inaccurate performance data. In either case, you can avoid all of these problems by installing BPA onto a workstation that's running Windows XP.

Second, BPA has limits regarding Exchange 5.5. The BPA tool will analyze Exchange 5.5 Servers with no problems. The only catch is that it is completely dependent on Active Directory. As you probably know, Exchange 5.5 wasn't designed to work with Active Directory. However, if your Exchange organization contains at least one Exchange 2000 or Exchange 2003 Server, you can use that server's Active Directory Connector to analyze the Exchange 5.5 servers in your organization. You won't have to do anything special during the configuration or analysis, but having at least one Exchange 2000 or 2003 Server is an absolute requirement.

A quick overview

You can launch BPA by selecting the Best Practices Analyzer Tool from the All Start | All Programs | Microsoft Exchange menu. When you do, BPA will open and ask if you'd like to download the latest updates. Since this is your first scan, it's a good idea to download the latest updates now.

It seems like downloading the latest updates whenever you run the BPA tool would be the best thing to do. However, this isn't always the case because of what the updates do. The BPA tool gets its results based on rules and thresholds.

For example, suppose BPA is running a test to see if your server's processor is overburdened. It's perfectly normal for a processor's utilization to spike to 100 percent, but the processor shouldnï¿?t consistently run at over 80 percent utilization. BPA might have a rule in place that's designed to trigger an alert if the processor is constantly running above 80 percent. When BPA generates its report, you'll see a warning indicating that your serverï¿?s processor is being overworked.

At this point, you upgrade the processor or take other steps to prevent the processor from having to work so hard. Then, you run the BPA tool again to see if the problem has been resolved.

When you run BPA this time around, it will prompt you to check for any updates that may have been released. However, you shouldn't download updates at this time because the updates make changes to the BPAï¿?s rules and thresholds.

If you're checking to see if you fixed a reported problem, you want to test the system using the same set of rules and thresholds as was originally used to detect the problem. Think about it for a moment. If you get the machineï¿?s average CPU utilization down to 78 percent, then the alert should go away on your next scan. However, if you download a new set of rules that just happens to change the CPU utilization threshold to 75 percent instead of 80 percent, BPA will report that you haven't fixed the problem, when in reality your processor is being used more efficiently.

Donï¿?t get me wrong. I'm all for downloading the latest updates. I just donï¿?t recommend downloading updates while you're in the middle of trying to solve a previously detected problem.

After you've downloaded the latest updates (or skipped the download), BPA will ask whether you want to connect to Active Directory or if youï¿?d rather select a report to view. Go ahead and connect to Active Directory. BPA will then automatically detect one of your networkï¿?s domain controllers. It will also warn you that it will perform the analysis by using the account you're currently logged in with. Normally, this wonï¿?t be a problem because the only special rights BPA needs is the ability to read from Active Directory. Likewise, BPA will usually have no problems detecting a suitable domain controller. It's possible, however, to select a domain controller from a different domain or to specify a global catalog server if necessary.

Once you've verified that an appropriate user account and domain controller are being used, click the Connect To Active Directory Server link. BPA will now spend a few seconds detecting all of the Exchange Servers on your network. When the detection phase completes, you'll see a screen similar to the one shown in Figure A. This screen displays all of the Exchange Servers that have been detected. By default, all of the servers will be analyzed, but you can prevent individual servers from being scanned by deselecting the corresponding check box.

Figure A

BPA detects all of the Exchange Servers on your network.

This screen contains two other options you need to be aware of. The first option is the type of scan to perform. The default option is a health check, the most comprehensive type of scan. You can, however, perform only a connectivity test or a baseline test if you prefer. For the purposes of this article, though, I'll use a health check.

The other option is the network speed selection. Microsoft provides this option so that BPA can accurately measure your Exchange Serverï¿?s response time by taking network latency into account. If your network is heavily congested, I recommend choosing a lower bandwidth setting to prevent BPA from producing false warning messages related to server response time. For example, my network is running at 100 Mbps, but I use the 10 Mbps setting when I run BPA scans.

After you've selected the servers you want to scan, the type of scan you want to perform, and your networkï¿?s speed, click the Start Scanning link to initiate the scan. The scanning process typically completes much more quickly than what BPA gives you as an estimate. BPA estimates two to three minutes per server, depending on your networkï¿?s speed. However, my experience has been that it takes closer to one minute per server for the scan to complete.

When the scanning process completes, click the View This Best Practices Report link. You'll see a report similar to the one shown in Figure B, which reveals that there were three critical issues found on the server Scooby. Each issue is occurring because the server is using compressed volumes. You can click on the issue to get more information, as shown in Figure C.

Figure B

On this scan, BPA has detected three critical issues.

Figure C

You can click on an issue for more detailed information.

When you click on an issue to learn more about it, you're given three options. First, you have the option of getting even more information on the issue and on how to resolve it. When you click this option, you're taken to a related article within the Microsoft Knowledge Base. Second, you can choose to ignore the issue on the current server. Third, you can ignore the issue across all servers.

Keep in mind that although BPA indicates that a particular issue is a problem, there may be cases when the reported condition is perfectly normal for your network. When this happens, it's better to simply turn off that particular test than to mess up your network by trying to fix the issue. In fact, the issues shown in Figures B and C are a perfect example of this. Scooby is a test server on my network. I use it only for writing articles about different products. I have so much stuff crammed onto that server that I have to compress the disks to prevent the server from running out of space.

BPA reports the compression as a critical issue, but the compression is absolutely necessary on that server. A real critical issue is not being able to mount the information store because I took the BPA's advice, decompressed the volume, and ran out of disk space.

If you look at the Select A Report drop down list in Figures B and C, you'll notice that Critical Issues List is selected. That means BPA is ignoring any issues it doesn't consider absolutely critical. For a more realistic picture of how well the servers are configured, select the Full Issues List. As you can see in Figure D, the number of issues found within my Exchange organization jumped from three to 32.

Figure D

BPA has 32 issues in my Exchange organization.

The report shown in Figure D is a perfect example of how some of BPA's warnings are worth addressing, but others are no big deal and need to be ignored. As you can see, there are nine warnings for the server Relevant. I'll walk you through the optimization process so you can get a feel for how it will work in your organization.

The first issue that's reported indicates the system pages are set too high on the server. This issue is related to a known bug in BPA. The bug has to do with the way that the /3GB switch is used in the boot.ini file on servers with over 1 GB of RAM. Microsoft is currently considering how the bug should be addressed, but for the time being, you should ignore any errors that mention system pages being set too high or that mention the /3GB switch.

The second warning indicates that a NIC is DHCP-enabled. Normally, an Exchange Server will have a static IP address, and my server is no exception. However, the server contains a NIC that's integrated into the system board. I'm not using that NIC, and it's set up for auto configuration (even though it isn't even plugged into the network). The BPA doesn't notice that the NIC is disconnectedï¿?only that it's set to use DHCP configuration.

The third issue reported is that the NNTP service is enabled. The NNTP service is a part of IIS. Normally, on a production Exchange Server, you should disable any service that is not absolutely required. Running unnecessary services contributes to poor performance and to potential security risks. In this case, though, the server is a lab server, and NNTP is being used for writing an article about IIS.

The fourth issue is an SMTP performance warning. This error was detected because the folder that Exchange uses as an SMTP queue is located on the same drive as my Windows folder. Normally, this would be a serious issue. You'll want the SMTP queue folder to be as isolated from the rest of the system as possible. Not only does having an SMTP queue on the same partition as the Windows folder hurt performance, but it's also a big security risk. I'm surprised that Microsoft didn't choose to designate this one as a critical issue.

The fifth issue detected on the server is displayed because the system's memory is optimized for running programs rather than for caching data. If this server were used exclusively as a routing server or as an OWA front-end server, you could realize a performance gain by reconfiguring a particular registry key that controls caching. As it is, however, this server contains mailboxes, and the registry key should not be reconfigured. I asked a friend at Microsoft why this alert had been triggered. He said that if a server has fewer than 20 mailboxes, the BPA suspects that it might function primarily as a routing server.

The sixth issue detected was triggered because the serverï¿?s TCP/IP configuration does not designate a WINS server. This is a perfect example of an issue you can usually ignore. WINS is a legacy technology that is hardly ever used today. DNS has taken its place. The only time you'd have to pay attention to this warning would be if your network contained older operating systems such as Windows 3.1, Windows 95, and Windows NT.

The seventh issue indicates that a client RPC binding was found. This error basically indicates that either the Exchange client or Outlook has been installed directly onto the server. Normally, you'd never want to use a production server as a workstation, and you wouldn't want Outlook installed. Because this is a lab server, though, Outlook is installed on it, so the error is correct.

The eighth error message says that my server is configured so that crash-related information is not automatically sent to Microsoft for analysis. This is one of those personal preference things. First, this is a lab server. I crash it all the time, intentionally and otherwise. There's no reason to transmit the information to Microsoft every time a crash occurs. Even if it werenï¿?t a lab server, I value my privacy and prefer not to have my crash data automatically sent to anyone.

The ninth issue goes back to the memory-related bug that I addressed in my discussion of the first issue.

Test and answer

As you can see, using the BPA tool effectively requires you to really dig through the test results. Many of the results you'll get will likely be issues you can or should ignore. In most of the scans that I've seen, BPA always manages to pick up on at least a couple of major issues that need to be corrected. Once you configure BPA to ignore unimportant issues, you'll find the advice given by the tool much more valuable.