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.