Simulating Stress for your Exchange 2003 Hardware using LoadSim 2003


Microsoft provides a few tools for stressing an Exchange server so you can check beforehand if your server can handle the projected load.

The main tool is Exchange Load Simulator (LoadSim) 2003, now updated to handle new Exchange 2003 features. This tool is intended for testing Exchange servers which mainly serve Outlook MAPI calls including RPC Over HTTP clients.

Setting up You Lab

LoadSim requires Outlook 2003 to be installed.

For best results minimal configuration includes your Exchange server and a test machine. Naturally, you should also have a domain controller or two if this is not a branch or SOHO type deployment.

A typical setup would look like this:

You might also choose to install everything on the same machine but this is not really recommended since in most cases you would want to separate the client machine creating the load and the Exchange server.

Before starting the tests you should configure your Exchange server as it would be in real life.  This could mean creating the number of storage groups and databases and placing them on the right disk drives, changing the SMTP queue directory to an appropriate disk drive ( and in large configurations, separating database log files from the database itself.


This is the initial LoadSim screen. You can see that each action is logged so you can see what LoadSim is doing.

In order to begin a test you first have to create a test topology by choosing Configuration -> Topology Properties.

In the Servers tab you can configure the number of users per mailbox stores that will be created during the test by double clicking the # Users column.

In the Security and Credentials tab you should select “Login to users using the account LoadSim is running on” which is simpler, takes up less Memory and CPU on the test client.

Please note that selecting the option “Login to users using their respective accounts” will generate errors if Exchange 2003 SP1 is installed. To resolve this issue use the following article:;en-us;830836&sd=ee

LoadSim 2003 can now create Dynamic Query-Based Distribution Groups when running against Windows 2003 Global Catalog servers.

Exchange 2003 currently supports only one root level folder for MAPI access.

You can however choose the number and depth of its subfolders.

Test Properties

Having created the topology, now is the time to add, using Configuration -> Test Properties, a couple of tests.

Each test contains the number of users participating in the test and the User type. A User type determines the kind of user you’re simulating. After all some users might be using Outlook heavily all the time and others occasionally. You can also select the user type “Cached Mode” which refers to the Outlook 2003 new feature which reads most information from a local file which synchronizes in the background with Exchange, easing the load on the server.

Using the “Customize Tasks” button you can tweak how tests are done.

Notice that in the “Test/Logon” tab LoadSim 2003 has the capability of simulating RPC over HTTP type logons so you can add that to your tests.

Running the Simulation

Now you need to do the following steps:

  • Create the Topology – users, groups and public folders
  • Initialize Tests – Create some items
  • Run Simulation – Reads, Writes, etc.

When you run the tests you will get this notice. It is important only if you have more than one client test machine.

You can open the Active Directory Users and Computers snap-in (dsa.msc) to see how LoadSim Users, and groups were created.

You can also view profile creation on the client test machine in the Control Panel Mail applet.

Be sure not to run a test for too long since, depending on the tests you’ve selected, LoadSim can inflate your Exchange database pretty quick.


During stress tests you should collect information regarding the server’s performance. This will tell you what is the “bottleneck” for you server, that is which hardware component (such as memory, hard drive, etc.) is loaded most so you might decide, for example to add memory to your server or buy faster disk storage.

Collecting information is done using the Administrative Tool “Performance” also known as Perfmon. You can also launch it from a Command Prompt window by issuing the command perfmon.exe.

In Performance, in the console tree, double-click Performance Logs and Alerts, right-click Counter Logs, and then click New Log Settings.

Name the New Log Settings appropriately (for example, “Stress Test #1”).

Add the following Performance Objects that belong to your Exchange server:

  • Memory (all counters, all instances)
  • Physical Disk (all counters, all instances)
  • Process (all counters, all instances)
  • Processor (all counters, all instances)
  • System (all counters, all instances)
  • Logical Disk (all counters, all instances)

For the Logical Disk counters to work you need to follow these steps:

  • Run from the command prompt “diskperf -YV”
  • Restart the server

If you want to know what LoadSim was doing during the tests than you could also add:

  • LoadSim Action (all counters, all instances)
  • LoadSim Global (all counters, all instances)

This will allow you to compare what LoadSim was doing at the time with the impact on the Exchange hardware. Make sure the counters you select belong to the test machine rather than the Exchange server.

If you also want to compare what Exchange itself was doing you could also add:

  • MSExchnageIS
  • MSExchangeIS Mailbox
  • MSExchangeIS Public
  • SMTP Server

Set the Interval to 15 seconds. If you’re stressing your server for a few days you might choose a setting of 60 seconds instead.

On the Log Files tab, set the log location and file name and type. (For example, E:\PerfLogs\jetstress_perfmon_20021119.blg.)

On the Schedule tab, set the Start Log option to Manually so you can begin monitoring when you begin your stress tests.

To start monitoring right click the counter log you just created and choose start:

Clearing the Event Viewer logs on all your lab machines before you start monitoring is a good practice so you could watch any special events that might indicate issues or problems.

Analyzing a Performance Test

In the console tree, click System Monitor, and then click View Log Data or press Ctrl + L.

Under Data source, click Log files, and then click Add.

Browse to the log that you created and click Open.

Click the Properties button, and then click Source.

Move the Time Range slider 10 minutes from the beginning of the test. To do this, move the start time 10 minutes to the right.

Click Data, and then click Add. Add the following counters:

  • Processor->%Processor Time->Total (Average should be less than 80 percent and maximum should be less than 90 percent.)
  • Memory->Available Mbytes (Minimum should be above 50 MB.)
  • Memory->Free System Page Table Entries (Minimum should be above 5000.)
  • Memory->Pages/sec (Average should be less than 100, and maximum should be less than 1000.)
  • Memory->Pool Nonpaged Bytes (Maximum should be less than 75 MB.)
  • Memory->Pool Paged Bytes (Maximum should be less than 190 MB.)
  • Physical Disk->Average Disk sec/Read->Instances (Because there should be almost no reads to the log drives, the average for this value should be less than 20 ms, with a Maximum no more than 40 ms.)
  • Physical Disk->Average Disk sec/Write->Instances (Log disk writes are sequential, so Average Write latencies should be less than 20 ms, with a Maximum no more than 40 ms (.040).)
  • Physical Disk->Disk Bytes/Sec->Instances
  • Physical Disk->Disk Writes/Sec->Instances
  • Physical Disk->Disk Reads/Sec->Instances  (Because all log activity should be writes for this test, this counter should be less than ten on average. If it is higher, the drive is most likely being used by another application).

You might choose Logical Disks instead of Physical Disks, depending on your configuration.

For NAS devices, use the following counters to monitor the disk performance.

  • Database->I/O Log Writes /sec
  • Database->I/O Log Reads/sec
  • Database->I/O Log Writes Average Bytes
  • Database->I/O Log Writes Average Latency
  • Database->I/O Log Reads Average Latency

This should give you a good picture of how your hardware is handling stress. If you want to know what causes this stress you could add counters from:

  • LoadSim Action (all counters, all instances)
  • LoadSim Global (all counters, all instances)

  • MSExchnageIS
  • MSExchangeIS Mailbox
  • MSExchangeIS Public
  • SMTP Server

Which counters to add will vary according to the information you want to compare.

After adding the counter you should see a graph illustrating your server’s performance during the test:


LoadSim is a robust tool with a lot of options and useful for determining the loads that your expensive hardware can handle. Especially when planning for large server deployments, taking the time to set up a lab and testing using LoadSim is worth it so you would know what to expect from you hardware.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top