Every time that I have ever had to deploy a brand new
Exchange Server into a corporate environment, doing so has made me a bit
nervous. The reason is because ordering the server hardware is a bit of a
gamble. Microsoft doesn’t have any guidelines that tell you exactly what server
hardware you are going to need based on the number of mailboxes and / or public
folders that will be hosted on the server.

The reason why they don’t give you this information is
because every organization is different. The server’s requirements will vary
dramatically depending on how heavily the users use Exchange, and on whether or
not the server is performing any additional duties. In the end, you are at the
mercy of your own knowledge and experience when you are trying to determine
what hardware is right for your new Exchange Server.

The good news is that you don’t have to wait until you have
users using the server in a production environment to know whether the new
server hardware is adequate or not. What you can do is to make your best
educated guess as to what hardware will best meet your organizational
requirements. When the new hardware arrives, you can install Windows and
Exchange Server. After doing so, you can perform a stress test on the server to
see how well it holds up during the tests. Assuming that the server performs
according to your expectations, you can then start setting up mailboxes. If the
server does not perform adequately during the tests, then you know that you
need to return the server to the manufacturer and buy something with more
power.

This is where the Exchange Server Stress And Performance
Tool comes into play. The Exchange Server Stress And Performance Tool is
designed to simulate a large number of client connections to an Exchange 2003
Server. Here’s how it works.

Author’s Note

There is also an Exchange 5.5 / 2000 version of the tool
that I will talk about later on. Before I get too deeply into this article,
there is one very important detail that I need to mention. In a “normal”
Exchange deployment, clients attach to the Exchange Server using Outlook.
Outlook communicates with Exchange using the MAPI protocol. The Exchange Server
Stress And Performance Tool is protocol based. It does not test mailbox access,
but rather how effectively the server can respond to a flood of network
requests. The tool is protocol based. You can use it to test communications
across a wide variety of Exchange related protocols, but MAPI isn’t one of the
supported protocols. If you want to find out how Exchange responds to MAPI
requests, then you will have to use some other diagnostic tool besides this
one.

Since the Exchange Server Stress And Performance Tool can’t
test MAPI communications, you might be wondering what it is good for. I have
found that this tool is especially useful if you have clients who will be
accessing the server via SMTP or Outlook Web Access. The tool fully supports
testing the SMTP protocol or the WebDAV protocol (used for Outlook Web Access)
among others.

Acquiring the Exchange Server Stress And Performance Tool

You can download the Exchange Server Stress And Performance
Tool for free from the Microsoft Web site. The download consists of a two and a
half megabyte, self extracting executable file.

Installing the Exchange Server Stress And Performance Tool

To install the Exchange Server Stress And Performance Tool,
copy the file that you downloaded to an empty folder on the Exchange Server
that you want to test. Double click on the file, and then click the Run button
when prompted. You will now be asked which folder you want to extract the tool
into. Make your selection, click OK, and the various files will be extracted
into a sub-folder named Medusa.

At this point, you must double click on a file named
MSETUP.EXE, that’s found in the Medusa folder. When you do, you will see the
Exchange Server Stress and Performance setup screen. Unless you need to change
the destination folder, just go with the default settings and click the Install
button. The installer will copy the necessary files, register several COM
objects, and create an icon on the Start menu.

You will now see a message indicating that the utility needs
to create a service account. You don’t have to enter a name for the service
account, but you must supply a service account password. The service account
will be used any time that you run one of the utility’s modules remotely. The
process of creating the service account can take a couple of minutes to
complete, but once the account is created, the tool is finished being
installed.

Configuring the Exchange Server Stress And Performance Tool

Although you have installed the Exchange Server Stress And
Performance Tool, it still needs to be configured. For the purposes of this
article, I will show you how to configure the tool to test the Exchange Server
against a flood of SMTP traffic.

Begin by clicking the Start button and selecting All
Programs | ESP | ESP. When you do, you will see the ESP console appear (ESP is
Microsoft’s abbreviation for Exchange Server Stress and Performance). By default,
the console will be almost completely empty.

The ESP user interface is object oriented. There are three
different types of objects that ESP recognizes; workspaces, hosts, and modules.
A workspace is really nothing more than a collection of hosts. For all
practical purposes, a host is simply a computer, and a module is the component
that’s used to run the tests.

Creating a workspace

With this in mind, the first thing that we have to do is to
create a new workspace. To do so, select the New Workspace command from the
console’s File menu. Nothing will appear to happen, but you have created a
workspace named Untitled. Select the Save As command from the File menu and you
will be prompted to enter a filename for your workspace (the default filename
is UNTITLED.INI). For our purposes, let’s call the new workspace ESP.INI. When
you do, you will see the console updated to reflect a workspace named ESP.

Now that we have created a workspace, we have to add one or
more hosts to it. The hosts will be the Exchange Servers that you want to test.
Keep in mind that the Exchange Servers that you are testing must be running
Exchange Server 2003. There is a separate tool for testing Exchange 5.5 and
Exchange 2000. For the sake of simplicity, let’s limit our workspace to a
single host.

To add the host to the workspace, select the workspace and
then select the Add Host command from the console’s File menu. When you do, you
will see the Add Host dialog box appear. The dialog box, shown in Figure A,
requires you to enter

the name of the host, and the domain Administrator’s
password.

Figure A

Enter the host name and the domain Administrator’s password.

You also have the option of limiting a test to a specific
duration if you choose to. After entering this information, click the Add Host
button (not the OK button). Before clicking OK, you must manually connect to
the host that you have added to the workspace. To do so, simply click the Add
Host button. Once the host has been connected, click OK to close the dialog
box.

Now that you have added a host to the workgroup and
connected the workgroup to the host, it’s time to configure the host to run
some specific tests. As I mentioned earlier, for the purposes of this article,
I will be configuring my test server to run an SMTP test. You can use the exact
same procedure to test any of the other protocols though.

To configure the host to run specific test modules, right
click on the host within the workspace and select the Properties command from
the resulting shortcut menu. When you do, you will see the host’s properties
sheet. The test modules are listed on the Available Modules tab, shown in
Figure B. By default, all of the test modules are listed, but none of them are
active. Therefore, you must select the SMTP module and click the Add button.

Figure B

Select the SMTP test module and click the Add button.

While you are configuring the modules, I recommend taking a
look at the Options tab. The options tab contains four options that you can
set. The first option is Max Transport Threads. This option allows you to
configure the number of ESP transport threads that will be generated to handle
I/O requests. The second option is the Archive Log option. It allows you to
control whether the test should generate a new log file or overwrite the old
log file. The third option is the Log Results option. As the name implies, it
allows you to determine whether or not the test results should be logged. The
final option is the log file path. This is the location where the log file will
be placed.

Click OK and the SMTP module will be added to the workspace
beneath the host. The next thing that you must do is to customize the module to
meet your needs. To do so, right click on the module and select the Properties
command from the resulting shortcut menu. For the most part, you will be OK
using the default values, but you will have to enter a script name and the name
of the server that you are running the script against.

ESP allows you to create some pretty elaborate scripts that
you can use to test the server’s SMTP capabilities. I’m not going to pretend to
be some kind of scripting guru. My scripting skills are mediocre at best.
Fortunately, there are a lot of sample scripts included with ESP’s
documentation. Below is a sample scripts (taken from ESP’s documentation) that
you can use in conjunction with the SMTP module. ESP’s documentation contains
lots of information about how to modify this script and there are also other
example scripts.

Example 1

Send a message with one recipient. The message body is in
file body.txt. Sleep between 3 and 5 seconds afterwards.

CONNECT

EHLO

MAIL FROM: <me>

RCPT TO: someone@somewhere

DATA body.txt

QUIT

SLEEP RANDNUMBER(3000, 5000)

Note

body.txt ends with CRLF.CRLF. You can also use BDAT instead
of DATA.

Running the Test

Once the test module has been configured, it’s time to
actually run the test. You can run the test locally on the Exchange Server that
you are testing. However, if you want to get a better feel for how your
underlying network infrastructure is performing, I recommend installing ESP
onto a different machine and running the test remotely. If you really want to
make things interesting, you can even configure multiple computers to run ESP
test modules simultaneously against a single Exchange server. The module can
only be run against an Exchange 2003 Server, but the ESP console can be run
under Windows 2000, 2003, or XP.

To run the test, simply right click on the module and select
the Start command from the shortcut menu. Keep in mind that ESP is only going
to give you statistics related to the commands that the script is executing
(such as the total number of connections). Although ESP is designed for
performance analysis, it does not generate any performance data on its own. For
that, you will have to run the Performance Monitor against the machine that’s
being tested. Since we are testing SMTP performance, then I recommend loading
the following counters that are found in the Performance Monitor’s SMTP Server
performance object:

  • Connections Current
  • Local Queue Length
  • NDRs Generated
  • Remote Queue Length
  • Messages Delivered / sec
  • Messages Sent / sec
  • Messages Received / sec

Interpreting the Test Results

Unfortunately, every module has its own individual set of
results, so there is no way that I have the space to discuss every conceivable
test result. They are however all in the ESP documentation. I do want to take a
moment and discuss the results of the SMTP test.

When you run the SMTP test, there are some things that you
can look for to determine whether or not the server is performing adequately.
For example, you can watch the Remote Queue Length counter to make sure that it
is not constantly growing. The Server needs to be able to process messages
almost as fast as the messages enter the queue.

Another thing that you should check is the server’s event
logs. Even if the server seems to be performing adequately, you need to make
sure that no errors are occurring behind the scenes as a result of your tests.

Exchange 5.5 and 2000

Earlier I mentioned that ESP could not be used to test the
performance of an Exchange 5.5 or of an Exchange 2000 Server. There is however
an older version of ESP available that you can use for such tests. You can
download this version from the Microsoft Web
site.

All that and more

In this article, I have barely even begun to scratch the
surface of what you can do with ESP. I strongly recommend looking at the ESP
documentation for assistance with testing alternate protocols and with
developing scripts that are suitable for your organization.