Exchange Stress and Performance Tool 2003

Exchange Server Stress and
Performance 2003 Tool

Published: September 2003
Updated: August 2004
Applies To: Exchange Server 2003 Service Pack 1
Copyright
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may
be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted
herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is
intended or should be inferred.
2003–2004 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveSync, MSDN, Outlook, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Exchange UE Writer: Jon Hoerlein

Project Editor: Diane Forsyth
Graphic Design: Kristie Smith
Production: Sean Pohtilla
Table of Contents
Exchange Server Stress and Performance 2003 Tool.................................1

Table of Contents.......................................................................i
Introduction...............................................................................1
Supported Protocols..................................................................1
System Requirements...............................................................2
When to Use ESP 2003..............................................................2
Installing ESP 2003....................................................................2
Configuring ESP 2003 on a Client Computer.............................3
Creating Workspaces and Hosts................................................................4
Establishing Connections...........................................................................5
Configuring Hosts......................................................................................5
Installing Test Modules..........................................................................................5
Configuring the Connection to the Host................................................................6
Customizing Test Configuration Properties............................................................7
Configuring Test Modules..........................................................................8
Configuring Module Properties and Committing Them..........................................9
Configuring Module Parameters............................................................................9
Configuring Logging and Performance Monitor Options for a Module......10
Saving the Workspace.............................................................................11
Restoring the Workspace.........................................................................11
Running Test Modules..............................................................................12
Stopping Modules....................................................................................12
Command Line Parameters......................................................................12
Setting up the Test..................................................................13
ESP Modules............................................................................13
Common Infrastructure............................................................................14
WebDAV Module for ESP..........................................................................14
Run-time Parameters..........................................................................................15
Configuration.......................................................................................................17
Statistics..............................................................................................................18
Script Verbs Specific to This Test Module and ESP Keywords..............................19
Reserved Variables Specific to This Test Module.................................................24
Commands Specific to This Test Module.............................................................25
How to Script WebDAV Verbs..............................................................................26
Sample Suites.....................................................................................................28
Simulating an Exchange Server 2003 User..........................................................35
ii Exchange Server Stress and Performance 2003 Tool
IMAP4 Module for ESP..............................................................................36

Statistics..............................................................................................................38
Script Verbs Specific to This Test Module............................................................39
Example Scripts...................................................................................................44
LDAP Module for ESP................................................................................50
Parameters..........................................................................................................50
Statistics..............................................................................................................51
Example Script....................................................................................................57
OLEDB Module for ESP.............................................................................57
POP3 Module for ESP................................................................................71
Statistics..............................................................................................................72
Example Scripts...................................................................................................75
SMTP Module for ESP...............................................................................78
Statistics..............................................................................................................79
Example Scripts...................................................................................................82
NNTP Module for ESP...............................................................................85
Statistics..............................................................................................................86
Sample Script......................................................................................................89
Outlook Mobile Access Browse Module for ESP........................................89
Installation..........................................................................................................89
Adding the Mobile Browse Module.......................................................................92
Statistics..............................................................................................................93
Variables Specific to This Test Module.................................................................94
Scripting With the Mobile Browse Module............................................................95
Example Script....................................................................................................96
Debugging Script Errors......................................................................................97
Exchange Server Stress and Performance 2003 Tool iii
Simulating an Exchange 2003 User.....................................................................98

Mobile Synch Module...............................................................................99
Adding the Mobile Synch Module.........................................................................99
Statistics............................................................................................................100
Script Verbs Specific to This Test Module..........................................................101
Script Functions ................................................................................................106
Script Object......................................................................................................107
Example Script..................................................................................................107
Simulating an Exchange Server 2003 User........................................................108
Additional Resources.............................................................109
Microsoft Knowledge Base Articles.........................................................110
Other Microsoft Exchange 2003 Tools....................................................110
Introduction
Microsoft® Exchange Stress and Performance (ESP) 2003 (also known as Medusa) is a highly scalable stress
and performance tool that you can use to stress test Microsoft® Exchange Server 2003. ESP includes multiple
modules and can simulate many client sessions while accessing one or more Exchange servers at the same
time. You can use ESP to test several workload scenarios.
You can run an unlimited number of ESP modules from a single computer to more realistically simulate
physically separate client computers. Alternatively, you can run ESP modules from separate computers at the
same time. Therefore, the load you can apply to your test environment is limited only by the available
hardware. Depending on the hardware and workload imposed by each script, you can simulate 5,000 or more
end users on a single host computer.
Note
The ESP tool cannot create user accounts. Therefore, to create a test that involves simulating
actual individual users, and not only client sessions, it is recommended that ESP be used with other
tools that can create user accounts (for example, Load Simulator 2003). For more information about
using ESP with other programs that create actual user objects, see "Setting up the Test" later in this
document.
ESP is modular and extensible. Currently modules are provided that enable you to test stress that is applied for
most Internet protocols. ESP does not include a module to test stress. This test is applied by MAPI
(Microsoft® Office Outlook®) clients.
Supported Protocols
ESP includes modules that can simulate client sessions over the following Internet protocols/APIs:
• WebDAV (Outlook Web Access)
• Internet Message Access Protocol version 4rev1 (IMAP4)
• Lightweight Directory Access Protocol (LDAP)
• OLEDB
• Network News Transfer Protocol (NNTP)
• Post Office Protocol version 3 (POP3)
• Simple Mail Transfer Protocol (SMTP)
• Outlook Mobile Access Synchronization Support
• Outlook Mobile Access Browser Support
2 Exchange Server Stress and Performance 2003 Tool
System Requirements
To use ESP 2003, you must comply with the following requirements. Note that these requirements can increase
if you use custom e-mail messages and custom configurations (Table 1).
Table 1 ESP 2003 system requirements

Components Minimum
Processor Intel Pentium Pro or compatible 200-megahertz (MHz) or greater
processor
Operating system Microsoft® Windows® 2000, Microsoft® Windows® XP, or
Microsoft® Windows Server™ 2003
Memory 256 megabytes (MB) of RAM
Available hard disk drive 10 MB
Display SVGA (800 x 600) or greater resolution monitor
When to Use ESP 2003
ESP 2003 simulates users using non-MAPI protocols, also named Internet protocols. ESP 2003 cannot
simulate MAPI stress.
Important
ESP 2003 should be used only in a test environment not connected to the production environment.
Installing ESP 2003
ESP 2003 runs only on Windows® 2000 operating system, Windows® XP operating system, and
Windows Server™ 2003.
Exchange Server Stress and Performance 2003 Tool 3
To install ESP
1. In the Setup folder on the ESP download package, run MSETUP.EXE.
2. In ESP Setup, under Destination Folder, note the default location to which ESP 2003 will be installed.
To change the location, click Browse, and then navigate to the location that you want.
3. To begin the setup process, in ESP Setup, click Install.
4. In ESP Service Account, type a password for the ESP service account that will be created during ESP
Setup, and then click Continue.
5. In ESP Setup, click OK to the message indicating that ESP components have been installed on your
computer.
Note
If you plan to run ESP modules remotely on Windows 2000 computers, you will also have to run
DCOMCNFG.EXE to manually configure DCOM settings. See the README.TXT for details. The ESP
Module Wizard requires Visual C++ 6.0 or later, Enterprise or Professional editions.
Configuring ESP 2003 on a Client

Computer
The ESP user interface is used to manage, configure, and run the Exchange COM tools components.
To start ESP 2003
1. Log on the computer where ESP 2003 is installed.
2. Start ESP 2003 (esp.exe). Click Start, point to All Programs, point to ESP, and then click ESP. ESP
opens showing an unsaved workspace named untitled.ini.
Figure 1 is an example of what the console pane of an ESP 2003 workspace looks like after saving the
workspace with a specific name and adding four host computers to the configuration. The workspace name
kevb.INI refers to the top-level object. The objects under the top-level object represent host computers that run
ESP modules (Figure 1).
Figure 1 An example of an ESP 2003 workspace with four hosts

Creating Workspaces and Hosts

ESP components include host computers, modules, and workspaces. Hosts are computers that run modules for
your ESP test. Hosts are members of a particular workspace, but the ESP UI refers to each computer as a Host.
To create a new workspace
1. In ESP 2003, on the File menu, click New Workspace. A workspace named Untitled.INI displays in the
console pane.
2. On the File menu, click Save As. In Save As, under File Name, type a name for the workspace, and then
click Save.
To add a host computer to the workspace
1. In ESP 2003, select the workspace to which you want to add a host, and then right-click Add Host. The
Add Host dialog box displays (Figure 2).
Figure 2 Adding a host to a workspace
2. In Name, type the name of the computer that you want to add as a host to the workspace. Alternatively,
click Browse, and then navigate to the computer that you want to add.
3. Click OK.
To remove a host computer from a workspace
1. In ESP 2003, in the console pane, select the host that you want to remove.
2. Right-click that host, and then click Delete.
Note
If you remove a host that is currently connected to a workspace, the host will be disconnected
immediately and all of its active test modules will be stopped.
Establishing Connections
After adding hosts to a workspace, you must manually connect to the host computer. Once a connection has
been established, you can add ESP modules and configure them to run on the host computer.
To connect to a host computer
1. In ESP 2003, select the host computer to which you want to connect.
2. On the Host menu, click Connect. The <Host Computer Name> dialog box appears, which you can use
to configure the selected host computer.
Note
After you establish a connection to a host computer, the host computer name is displayed in bold
in the console tree of ESP 2003.
Configuring Hosts
To configure each host computer in a workspace, you use the property tabs in the <Host Computer Name>
dialog box. This dialog box displays automatically after you add a host to a workspace. You can also display
the properties of a host if you right-click a host computer in the console tree of ESP, and then click Properties.
The <Host Computer Name> dialog box includes the following tabs:
• Available Modules tab
• Target Host tab
• Options tab
Installing Test Modules

Use the Available Modules tab to specify the modules that you want to run on a host computer.
To specify the modules that you want to run on a host
1. In ESP 2003, right-click the host computer to which you want to connect, and then click Properties.
2. On the Available Modules tab, under Installed Modules, select the first module that you want to run on
this host, and then click Add. The module you add appears under Add These Modules (Figure 3).
Figure 3 The Available Modules tab of the member properties dialog box
3. To add additional modules, repeat the previous step until you have added all of the required modules. You
can remove a module that you have added by selecting it and clicking Remove. You can clear all of the
added modules by clicking Clear.
4. Click Apply.
Configuring the Connection to the Host

You use the Target Host tab to view and configure the connection information for a specific host.
Note
The options under Remoting (Domain, User Name, and Password) are not functional in this
version of ESP 2003. When implemented, these options will enable you to specify a security context
for the host computer.
To configure the connection to the host
1. In ESP 2003, right-click the host computer to which you want to connect, and then click Properties.
2. On the Target Host tab, in Name, specify the name of the host computer. You can type the name of the
computer, or click Browse, and then navigate to the computer to connect to (Figure 4).
Figure 4 Target Host tab of the properties dialog box
3. Under Test Duration, click Fixed (minutes), and then type a value if you want a test to run only for a
specific amount of time. If you do not select this option, the test will continue to run until it is finished.
4. Select Reconnect at Startup if you want the host to be connected automatically when the workspace is
opened.
5. Click Apply.
Customizing Test Configuration

Properties
• You use the Options tab to specify run-time test configuration properties that apply to all of the modules
running on a particular host. These test configuration properties include the following:
• Max Transport Threads The number of ESP transport threads that will be generated to handle IO
requests.
• Archive Log Whether each test-run should generate a uniquely named log file or overwrite the existing
log.
• Log Results Whether the results should be logged to disk.
• Log File Path The path of the log file.
To change test configuration properties

1. In ESP 2003, right-click the host computer that you want to connect to, and then click Properties.
2. On the Options tab, double-click the parameter that you want to modify (Figure 5). The cursor will move
to the Value column for the option that you specify.
Figure 5 The Options tab of a of the properties dialog box for a workspace
3. Type the value for the parameter that you want to modify.
Note
If you are specifying the Log File Path, you can either type the path directly or click the
Browse button and navigate to the location that you want to specify.
4. Click Apply to save your changes.
The host computer tries to accept the new settings and to put the changes into effect. If you apply changes
while any test modules are running, the host automatically determines whether it needs to restart the modules.
Configuring Test Modules

When you connect to a host computer, all of the installed test modules for that host are listed in the ESP 2003
user interface.
To view the installed modules for a host
1. Start ESP 2003 (esp.exe). Click Start, point to All Programs, point to ESP, and then click ESP.
2. In the console tree, expand the host computer object that contains the modules that you want to view
(Figure 6).
Figure 6 Host computer lest80 with one LDAP module
Configuring Module Properties and

Committing Them
You configure test modules using the property tabs of each individual module object. The two property tabs for
ESP modules are Settings and Statistics.
Changes to modules must be committed to take effect. You commit changes by using the Apply button on each
tab. Alternatively, the changes you configure are automatically committed when you start the test module. The
changes are saved before ESP runs the test module.
Configuring Module Parameters

You use the Settings tab to configure parameters for individual modules.
To configure the parameters for a module
1. In the console tree, expand the host computer object (Figure 6).
2. Right-click the module that you want to configure, and then click Properties. Alternatively, you can
double-click the module.
3. On the Settings tab, double-click the parameter that you want to modify (Figure 7).
Figure 7 Settings tab of the LDAP module within a workspace

4. In the Value column, type the value that you want.
5. Click Apply to save your changes.
Configuring Logging and

Performance Monitor Options for
a Module
Use the Statistics tab to configure logging and performance monitor options for individual modules. The only
statistics options you can configure are whether a statistic is enabled and how frequently a statistic is polled.
To configure a logging or performance counter option
1. In the console tree, expand the host computer object (Figure 6).
2. Right-click the module that you want to configure, and then click Properties. Alternatively, you can
double-click the module.
3. On the Statistics tab, select the first statistic that you want to modify, and then do the following
(Figure 8):
• In Polling, select Enabled.
• In Frequency, specify how often you want the data for that statistic to be gathered.
Figure 8 Statistics tab of the LDAP module within a workspace

4. Repeat the previous step for all statistics that you are interested in.
5. Click Apply to save changes.
Saving the Workspace

You can save the configuration for a workspace (which includes the configuration of all hosts that are currently
connected to a workspace) to a workspace .ini file. This enables you to restore and rerun a test later.
Important
The settings of a host computer are saved to the workspace file only if the computer is connected
when the save occurs. For example, if a user connects to the host computer named Host01, makes
setting changes to that host, disconnects from the host, and then saves the workspace, the
changes for the host computer named Host01 are not saved.
Restoring the Workspace

You can restore a workspace by opening the workspace .ini file from a previous test. When you open the
workspace, the console pane is restored to display the same host computers that were connected when the file
was last saved. Connections that existed during the previous session will not be restored.
Running Test Modules

You can run all modules on a host simultaneously, or you can run modules individually.
To run all modules for a specific host
1. In the console tree, ensure that you are connected to the host.
2. Right-click the host object that contains the modules that you want to run, and then click Start All.
Alternatively, you can select a host and then use the green traffic light icon on the tool bar to start a test.
To run an individual module
1. In the console tree, ensure that you are connected to the host that contains the module you want to run.
2. Right-click the module that you want to run, and then click Start. Alternatively, you can select a module
and then use the green traffic light icon on the tool bar to start the module.
Stopping Modules
After your modules have started, you can stop an individual module or all of the modules.
To stop all modules for a specific host
1. In the console tree, select the host that contains the modules that you want to stop.
2. Right-click that host, and then click Stop All. Alternatively, you can select a host and then use the red
traffic light icon on the tool bar to stop a test.
To stop an individual module
1. In the console tree, expand the host computer that includes the module that you want to stop.
2. Right-click the module that you want to stop, and then click Stop. Alternatively, you can select a module
and then use the red traffic light icon on the tool bar to stop the module.
Command Line Parameters

You can start ESP from the command line to enable batch files to run test passes. You can pass a single
parameter on the command line: the name of a workspace file. And, you can pass the following flags shown in
Table 2.
Table 2 Command line parameters

Parameter Flags Description Example
<workspace filename> The workspace file ESP
D:\tools\<filename>.ini
<workspace filename> -unattended Starts ESP automatically ESP -unattended
running in the workspace given D:\Tools\<filename>.ini
by <workspace filename>
<workspace filename> -closeonstop ESP will run until the last ESP -unattended
module stops. Used when -closeonstop
modules use "Fixed Duration" D:\Tools\<filename>.ini
parameter.
Parameter Flags Description Example

-regserver Called only by setup to register ESP -regserver
component categories
-unregserver Called only by setup to ESP -unregserver
unregister component
categories
Setting up the Test
To set up a realistic test, you need to create users and populate mailboxes with e-mail messages. ESP cannot
simulate users, so it is recommended that you use it with tools that have this capability, such as LoadSim 2003
to leverage the capability of creating users and populating mailboxes. For example, if you are using
LoadSim 2003 with ESP 2003, it is possible to export a list of users created with LoadSim 2003 from Active
Directory® directory service.
To export a list of users from Active Directory
1. Start Active Directory Users and Computers.
2. Expand the Active Directory Users and Computers console tree to display the Active Directory containers
that include the user names that you want to export.
3. Right-click a container for which you want to export user names, click Export, and then save the user
names to a file.
4. Open the file to which you exported user names.
5. In that file, delete all data other than the user names. The correct syntax is that only one user name should
be listed per line.
6. Repeat Steps 3 through 5 for each Active Directory container for which you want to export the list of
users.
ESP Modules
ESP provides a common script language that can be used for all scripts. It also enables each module to extend
the language for its own needs.
Common Infrastructure
The script verbs shown in Table 3 are common to all ESP modules.
Table 3 Common scripts for all modules

Reserved Script Verb Syntax and Example Description
LOOP LOOP <no_of_iterations> Loops into the code.
1*(<command>)
// one or more
commands
ENDLOOP
RANDNUMBER RANDNUMBER(<low>, <high>) Generates a random number within
the low-high range.
RANDLIST RANDLIST(<filename>) Gets a random line from
"filename".
SEQULIST SEQULIST(<filename>) First evaluation of construct will
return first line from file
"filename." Second evaluation will
return second line from file, and so
on. This is done in a circular
manner.
SAMESEQULIST SAMESEQULIST(<filename>) Returns the same string as the
previous SEQULIST(<filename>)
call.
SEQUNUMBER SEQUNUMBER(<n1>, <n2>, ID) Each evaluation returns a
sequential number in the range
<n1> - <n2>. The range is
associated with an ID. Depending
on whether n2 > n1 or n2 < n1,
you will have an ascending or
descending sequence.
SAMESEQUNUMBER SAMESEQUNUMBER(<n1>, Returns the same number as the
<n2>, ID) previous SEQUNUMBER call
with the same ID.
WebDAV Module for ESP

This module simulates multiple clients using Web Distributed Authoring and Versioning (DAV). The module
supports parameters for configuring different protocol-specific options, options for how the test executes, and
security options. Examples are the server this client is targeting or the port number. Client actions are
simulated by running a script that contains ESP keywords and DAVCOM verbs. This module supports simple
script variables and reports a number of statistics during runtime. Statistics give counts of the number of
modules or protocol-specific events (for example, errors, successful or failed connection attempts.) that occur
during a test run. You can also log client actions and server responses during a test run. You cannot configure
the events that are logged.
Important
This module requires the use of a specific set of additional script files not required by other
modules. These are known as Outlook Web Access suite files. These files are in the
C:\Medusa\OWASuite subfolder, where C:\ is the location to which you extracted the ESP 2003 tool
(by running Medusa.exe).
For more information about these files, see "Sample Suites" later in this section.
Run-time Parameters
The run-time parameters of Outlook Web Access and a description of each are shown in Table 4.
Table 4 Outlook Web Access run-time parameters

Parameter Description Optional/ Default Legal Values
Required
Server Server name Required Blank <UNC server name or IP
address>
Script Instances Number of users Required, > 1 1-n
than 0
Start Time Delay (ms) Each script instance will Required, > 0 1-n
be delayed from starting than 0
this many milliseconds.
Encryption Type Encryption method to Required NONE BASE64
use when doing UUENCODE
authentication
NONE
Authentication Method Authentication method Required NTLM NTLM
DPA
MSN
KERBEROS
BASIC
NONE
Authentication Authentication encoding Required BASE64 BASE64
Encoding Method method
HTTP Version HTTP version Required HTTP/1.1 HTTP/1.1
HTTP/1.0
HTTP/0.9
Port Number Port number to use when Required 80 <integer port number>
connecting to a server
Browser Type Browser type Required DAV DAV
Script File Script file to run a test Required Blank <valid path>

Required
Calculate Content Can be one of the Required YES YES
Length following: NO
If yes, and there is a
second parameter for the
script request, the
content length will be
calculated, and the
"Content-Length" header
will be added.
If yes, and you do not
have a second parameter
for the script request, the
content length will not be
calculated, and the
"Content-Length" header
will not be added.
If yes, and the content
length of the second
parameter is 0 bytes,
then the "Content-
Length" header will not
be added.
Send Notification If yes, then error and Required NO YES
warning notifications are NO
sent to the ESP user
interface notification
windowpane.
Sleep Duration on Error The duration for which Required 1000 0-n
(ms) each script instance (or
user) will be delayed (put
to sleep) when an
internal error occurs, in
milliseconds
Close Connection on Closes the connection Required YES YES
Wakeup whenever a user wakes NO
up from a sleep. When
users are doing long
sleeps, this prevents the
user from reporting an
error when waking up if
the server has timed out
the socket.

Required
Emulate Wininet Forces the module to Required NO YES
follow Wininet's default NO
behavior when uploading
request bodies and using
authentication. In this
case, prior to the request
body being uploaded the
connection will be re-
authenticated.
Configuration
1. Start ESP 2003 (esp.exe). Click Start, point to All Programs, point to ESP, and then click ESP.
2. From the File menu, click Add Host.
3. In Name, type the name of the host computer, and then click Connect Host.
4. On the Available Modules tab, add a DAV module instance, and then click OK.
5. In the console tree, right-click the DAV module just created, and then click Properties.
6. Configure the module to your specifications. For example, enter the server, script instances, authentication
method, and script file. You can also change other fields (Figure 9). For example, you can change the
value for the parameter "Close connection on wakeup" from YES to NO. Authentication method should be
set as NTLM or BASIC.
Figure 9 Settings tab of a DAV module

7. Run the suite by clicking the green traffic light icon.
Statistics
Table 5 describes the run-time statistics that are reported to the ESP user interface and an explanation of each.
Table 5 Outlook Web Access run-time statistics

Statistic Description
Active Connections Current active user connections
Successful Connections Total number of active connections
Failed Connections Total number of failed connections
Authenticated Connections Total number of successful authenticated connections
Failed Authenticated Total number of failed authenticated connections
Connections
Connections Closed by the Total number of connections that the server closed for no good reason.
Server This is NOT incremented if you get a Connection: close header back from
the server.
SLEEP Requests Total number of SLEEP requests
POLL Requests Total number of POLL requests
SUBSCRIBE Requests Total number of SUBSCRIBE requests
UNSUBSCRIBE Requests Total number of UNSUBSCRIBE requests
POST Requests Total number of POST requests
SEARCH Requests Total number of SEARCH requests
TRACE Requests Total number of TRACE requests
PROPFIND Requests Total number of PROPFIND requests
PROPPATCH Requests Total number of PROPPATCH requests
PUT Requests Total number of PUT requests
OPTIONS Requests Total number of OPTIONS requests
MOVE Requests Total number of MOVE requests
MKCOL Requests Total number of MKCOL requests
UNLOCK Requests Total number of UNLOCK requests
LOCK Requests Total number of LOCK requests
HEAD Requests Total number of HEAD requests
DELETE Requests Total number of DELETE requests
COPY Requests Total number of COPY requests
GET Requests Total number of GET requests
BPROPFIND Requests Total number of BPROPFIND requests
BPROPPATCH Requests Total number of BPROPPATCH requests
BDELETE Requests Total number of BDELETE requests
BMOVE Requests Total number of BMOVE requests
BCOPY Requests Total number of BCOPY requests
Unknown Requests Total number of unknown requests
100 Level Status Total number of 100 status-level responses received by the server
Unknown Level Status Total number of unknown status-level responses received by the server
Successful Shutdowns Total number of script instances (or users) that were successfully
shutdown
Failed Shutdowns Total number of script instances (or users) that did not successfully shut
down. If this number is greater than 0, you must quit the ESP user-
interface application and restart…$bug$ in the Internet transport used.
Script Verbs Specific to This Test Module

and ESP Keywords
Following are the reserved-word script verbs that are specific to this test module and a description of each
(Table 6). Anything specified with the delimiters "<>" is required. Anything specified with the delimiters "[]"
is optional.
Table 6 Outlook Web Access reserved-word script verbs

Reserved Script Syntax and Example Description
Verb
ADDHEADER ADDHEADER <HdrLbl><:> <HdrVal> Adds headers for any DAV
commands that follow it until the
header is deleted.
ADDHEADER Connection: close
DELHEADER DELHEADER < HdrLbl ><:> [HdrVal] Deletes a header so that it is not
sent with the server request.
DELHEADER Connection:
or
DELHEADER Connection: close

Verb
SET SET <$><VarName><$> <VarValue> Creates a variable that can be
used throughout the script.
SET $server$ server_1

ADDHEADER host: $server$
ADDVROOT ADDVROOT <VrootName> Adds a Vroot name so that when
any request is sent to the server,
the Vroot is pre-pended to the
ADDVROOT root6 server request.
DELVROOT DELVROOT <VrootName> Removes the Vroot name so that
it is not pre-pended to the server
request.
DELVROOT root6
KEEPRESPONSE PROPFIND /exchange/user1/Inbox c:\temp.xml Used with PARSEXML to grab
keepresponse more than one XML tag from a
response.
PARSEXML dav:!href
The first four SET commands get
SET $name1$ $xml$.NEXT
the dav:!href property from the
SET $name2$ $xml$.NEXT first four responses to the
SET $name3$ $xml$.NEXT PROPFIND.
SET $name4$ $xml$.NEXT The second four SET commands

get the dav:!displayname property
PARSEXML dav:!displayname from the first four responses to
SET $displayname1$ $xml$.NEXT the PROPFIND.
SET $displayname2$ $xml$.NEXT
RESPHEADER RESPHEADER(<HdrLbl>) Used to get header information

returned in the response from the
server.
SET $respvalue$ RESPHEADER(ETag)
GET /exchange/user1/text.txt
ADDHEADER IF-NONE-MATCH:
$respvalue$

Verb
New XMLList SET $xml$ new XMLList These three constructs are used
for taking variables from an XML
PARSEXML <tag> PROPFIND /exchange/user1/Inbox c:\temp.xml
response from a DAV request.
PARSEXML dav:!href
.NEXT
The first command, setting the
SET $name1$ $xml$.NEXT
$xml$ variable, needs to be
entered only once at the
beginning of the script.
The PROPFIND command gets
properties on the Inbox described
by the temp.xml file. The
PARSEXML part of this
command specifies which part of
the returned XML to take.
The third line sets the part of the
XML that was grabbed to a
variable name.
RESPXML RESPXML(<xml>) This is used to parse the server's
XML body response.
SET $xml$ RESPXML(opaquelocktoken)
LOCK /exchange/user1/text.txt c:\<filename>.txt Note
Use this only to extract the lock
ADDHEADER Lock-Token: <$xml$> token out of the XML body that is
GET /exchange/user1/text.txt returned from the server in a
response to a lock command. If
UNLOCK /exchange/user1/text.txt you use it for other than locks, the
DELHEADER Lock-Token: result is undefined.

Verb
PARSEXML Example: PARSEXML enables you to store
property values returned from the
SET $xml$ = new XMLList
server as variables. You do this
PROPFIND /<Value> PARSEXML dav:! by adding the following text to
displayname the end of the command:
SET $prop$ $xml$.NEXT PARSEXML Namespace!
SET $nextprop$ $xml$.RND propertyname.
SET $fifthprop$ $xml$.5 The example to the left is doing a

PARSEXML for namespace dav:!
SET $xml$.RESET property displayname. Note that
SET $xml$.REMOVE the PARSEXML option can be
specified for any request
GET /<Value>/$prop$
(PROPFIND, SEARCH, ) but
DELXMLLIST $xml$ will work correctly only on
requests that return XML
(response body with a content-
Methods supported by the XMLList object: type of text/xml). The results of
.Next – gets the next item doing a PARSEXML are stored in
the last variable that you set as the
.RND - gets a random item XMLList.
.RESET- sets the next item back to the You can have and use multiple
beginning of the list. This occurs automatically if XMLLists in your script, but the
the end of the list is reached. results of the PARSEXML will
.REMOVE – removes all of the items in the list always be stored in the last one on
.# - (where # is an integer) gets the item at index which SET was called. After you
create an XMLList object, that
#
object is never deleted as long as
the module exists, so you should
reuse the objects as much as
possible to keep the working set
of the module low.
DELXMLLIST SET $xml$ = new XMLList Frees the memory associated with
an XMLList object. However,
DELXMLLIST $xml$
note that you cannot use an
XMLList that has been deleted
unless you re-create it again with
SET … new XMLList.
URIESCAPE URIESCAPE $variable$ URIESCAPES the value of a
given variable. This ensures that
the variable is safe to use in a
URI.
URIUNESCAPE URIUNESCAPE $variable$ URIUNESCAPES the value of a
given variable. This removes any
escaping.

Verb
CURRENT SET $timenow$ = current datetime These commands get the current
DATETIME date and time and put them into
SET $time+1hr$ $timenow$
the format that DAV commands
ADDTIME ADDTIME $time+1hr$ 60 will use. They also create new
date-time strings.
Time added in the ADDTIME
command is in minutes. The
minutes can also be negative,
which creates a past date.
SEARCHVAR GET /exchange/user1/Calendar/?Cmd=new Used to get data returned in a
KEEPRESPONSE script.
SEARCHVAR $mbxguid$ g_szMailboxGuid To simulate some actions in a
script, you may need to get the
mbxguid for a user. The mbxguid
appears within a script as the
response of a GET on the
Calendar in a variable
g_szMailboxGuid.
To grab the variable, use the
SEARCHVAR command.
REPLACEVARS PROPPATCH /<Value> c:\text.txt replacevars REPLACEVARS will open up the
file specified and replace any
instances of variable names with
the corresponding values. Any
variable that you can reference
from a script as $variable$ will be
replaced if that same string
$variable$ exists in the file. The
actual contents of the file on disk
are not changed.
Used to keep any variables that
have been set in the script when
including an external file.
SET SET $<variablename>$ <value$ Sets a variable to a value.
SET $host$ server1
REM REM [text] Used to comment out lines.
ECHO ECHO [text] Used to log output to the log file.
Note
You cannot have an ECHO as the
ECHO --- Starting new message ---
first action, because the script will
-Or- fail. You must have one event
Echo $host$ written to the log before using an
ECHO to write to the log.

Verb
SKIP SKIP <value> Causes the script to skip the next
<value> number of lines.
SKIP 1
SLEEP SLEEP <value> Causes the script execution to
pause.
SLEEP 15000
-Or-
SLEEP RANDNUMBER(180000,290000)
Reserved Variables Specific to This Test

Module
The following are reserved-word variables and an explanation of each (Table 7).
Table 7 Outlook Web Access reserved-word variables

Reserved Variable Syntax and Example Description
$AUTHORIZATION$ SET $AUTHORIZATION$ <domain\user> This is how
<pwd> authentication is done.
If you set up your server
to do any type of
SET $AUTHORIZATION$ domain1\user1
supported authentication,
TryToGuess!
the module will send the
-Or- <domain\user> <pwd>
SET $AUTHORIZATION$ when authenticating the
SEQULIST(c:\users.txt) user.
-Or-
SET $authorization$ RANDLIST(c:\ users.txt)
$USER$ SET $AUTHORIZATION$ domain1\user1 In this example, the
TryToGuess! $USER$ variable is set to
and replaced with user1.
GET /private/$USER$/inbox
$PWD$ $PWD$ In this example, the
$USER$ variable is set to
and replaced with user1,
SET $AUTHORIZATION$ domain1\user1 and the $PWD$ variable
TryToGuess! is set to and replaced with
GET /exchange/$USER$/inbox/$PWD$ TryToGuess!
Commands Specific to This Test Module

The following describes the general syntax that is used for any WebDAV command supported by this test
module
How to Script a WebDAV Verb

All WebDAV verbs can have at most two parameters and at least zero parameters:
Note
When the syntax is described for each WebDAV verb, anything specified with the delimiters "<>" is required.
Anything specified with the delimiters "[]" is optional.
<HTTP/DAV_Verb> [parameter1] [parameter2]
Parameter1 is always assumed to be some resource on the server and is optional. Parameter2 is assumed to be a
path + filename that can be local or UNC and is optional. In keeping with this convention, you should not
assume that this test module does not support new WebDAV verbs not discussed in this document.
The HTTP Version

The HTTP Version specified in the HTTP Version parameter is always appended to the WebDAV verb
command before it is submitted to the server. For this reason, you should never include the HTTP version on
any WebDAV verb command in your scripts.
WebDAV Headers
You add headers to a server request by using the ADDHEADER reserved word. To add headers to a server
request, add all of the headers before the request. All headers that are added with an ADDHEADER are sent
with all server requests until the header is removed. To remove headers from a server request, use the
DELHEADER reserved word.
The Content-Length Header

If the Calculate Content Length is set to YES and there is a second parameter for the script request, ESP
calculates the content length of the header for you and adds or removes the Content-Length header
accordingly.
If the Calculate Content Length is set to YES, and there is not a second parameter for the script request, ESP
does not calculate the content length and does not add the Content-Length header is not added for you.
If the Calculate Content-Length parameter is set to YES and the content length of the second parameter is 0
bytes, ESP does not add the Content-Length header for you.
Authentication
1. In the ESP UI, specify the authentication method by using the Authentication Method parameter.
2. In the ESP UI, specify the encryption method by using the Encryption Type parameter (if applicable).
3. In your script, ensure that one of the following exists:
SET $AUTHORIZATION$ <domain\user> <pwd>
or
SET $AUTHORIZATION$ SEQULIST(<path/UNC to list of users in a file formed like
<domain\user> <pwd>)
or
SET $AUTHORIZATION$ RANDLIST(<path/UNC to list of users in a file formed like
<domain\user> <pwd>)
When the domain\user and pwd are parsed, the reserved variable $USER$ will be set to user, and the
reserved variable $PWD$ will be set to the password.
4. Send your WebDAV verb. If the server returns a 401 status code, ESP prompts to authenticate the user.
Here is an example script:
SET $AUTHORIZATION$ domain1\user1 password
ADDHEADER Host: server1
ADDHEADER Depth: 1
ADDHEADER Content-type: text/xml
PROPFIND /exchange/$USER$/Inbox D:\text.txt
DELHEADER Depth:
DELHEADER Content-type:
SLEEP 1000
How to Script WebDAV Verbs

The following shows the WebDAV verbs and how to script them (Table 8).
Table 8 WebDAV verbs and how to script them

HTTP/DAV Syntax/Example Description
GET GET <url> Retrieves a resource from the server.
ADDHEADER host: server1

PUT PUT <url> <local or UNC path + filename> Used to put a resource to a server.

PUT /exchange/user1/myfile.txt c:\text.txt
POST POST <url> <local or UNC path + filename> Used to post a resource (or form) to
the server.

POST /exchange/user1/myfile.txt c:\text.txt
COPY COPY <source url> Used to copy a resource.
ADDHEADER Destination:
/exchange/user1/dest.txt
COPY /exchange/user1/src.txt
DELETE DELETE <url> Used to delete a resource.

HEAD HEAD <url> Used as the GET verb, but does not
return the body of the resource.
MKCOL MKCOL <url> Used to make a collection on the
server.
MOVE MOVE <source url> Used to move a resource.
ADDHEADER Destination:
/exchange/user1/dest.txt
MOVE /exchange/user1/src.txt
OPTIONS OPTIONS <url> Used to see what options the server
supports.
TRACE TRACE <url> Repeats the command sent to the
server.
LOCK LOCK <url> <path to xml lock body> Used to lock a resource on the
server.
LOCK /fs/text.txt c:\<filename>.txt

UNLOCK UNLOCK <url> Unlocks the resource that is locked.
SET $xml$ RESPXML(opaquelocktoken)

LOCK /fs/text.txt c:\ <filename>.txt
ADDHEADER Lock-Token: <$xml$>
GET /fs/text.txt
UNLOCK /fs/text.txt
DELHEADER Lock-Token:
PROPFIND PROPFIND <url> Used to find the properties on a
resource.
-Or-
If you do a PROPFIND with only
PROPFIND <url> <path to xml propfind body>
one parameter, you need to add the
Content-Length header yourself
ADDHEADER host: server1 using ADDHEADER.

PROPFIND /exchange/user1/dir1 c:\text.txt
PROPPATCH PROPATCH <url> <path to xml propfind body> Used to add, delete, or modify
properties on resources.

PROPPATCH /exchange/user1/dir1 c:\text.txt

MS-SEARCH MS-SEARCH <url> <path to xml body> Searches for a resource.

ADDHEADER Content-Type: text/xml
MS-SEARCH /httpext c:\text.txt
SEARCH SEARCH <url> <path to xml body> Searches for a resource.

ADDHEADER Content-Type: text/xml
SEARCH /httpext c:\text.txt
POLL POLL <url>
SUBSCRIBE SUBSCRIPT <url>
Sample Suites
Table 9 shows three sample suites to help you immediately start stress testing your servers and topologies.
These three suites model many user interactions and cover the scenario in which a user has no cached items,
thereby necessitating the download of every item every time a user session is initiated. The suites are labeled
small, medium, and large. You can use one suite or a combination of the suites to provide the best model of
your users. In the suites described in Table 9, no sleep requests are inserted in order to accurately model a
realistic pattern of usage. Instead, the suites are aimed at applying the largest amount of load in the shortest
period of time.
Important
By default, the files that make up the sample suites used throughout this section are in the
C:\Medusa\OWASuite subfolder, where C:\ is the location to which you extracted the ESP 2003
tool (by running Medusa.exe). The description of each of these files is shown in Table 9, Table 14,
and Table 15 later in this section.
Although not required, it is recommended that you copy the OWASuite folder to C:\ folder, where
C:\ is the location to which you installed ESP 2003. The important consideration is that you must
correctly reference the location of the Outlook Web Access suite script files when configuring the
$filepath$ variable in the script files shown in Table 9.
For additional information about configuring your HTTP/DAV ESP 2003 test, see the Readme text
file, located in the OWASuite folder.
Table 9 Outlook Web Access sample suites

Suite Description
OWA_small.txt This is a Microsoft Office Outlook® Web Access scalability script to
simulate a satellite user, in other words, one who uses Outlook Web Access
lightly.
It sends 3 messages, creates an appointment, forwards one message, checks
the calendar, checks for new messages, deletes a message, and reads 4
messages.
Suite Description
OWA_medium.txt This is an Outlook Web Access scalability script to simulate a companion
user, in other words, one who uses Outlook Web Access as a companion.
It sends 10 messages, sends a message with an attachment, creates an
appointment, sends a recurring meeting request, checks the calendar, checks
for new messages, reads 12 messages, forwards four messages, deletes 4
messages, empties the deleted items folder, and opens a new contact and
saves it.
OWA_large.txt This is an Outlook Web Access scalability script to simulate a heavy user
who uses Outlook Web Access as their main client.
It sends 30 messages, sends a message with an attachment, creates an
appointment, sends 2 recurring meeting requests, creates a new contact,
creates a rule, checks the calendar, checks for new messages, reads 12
messages, creates another new contact, forwards 20 messages, sends a
message to trigger a rule, spell checks one 2 KB message, creates a task,
deletes 36 items, searches for three items, marks task as complete, empties
the deleted items folder, deletes another item, and then deletes that item
from the Dumpster.
You need to configure several variables to run the suites in your environment. The variables below are
examples, and you might need to change them if the default is not appropriate (Table 10).
Table 10 Variables for the sample suites in Table 9 that might need to be changed
Variable Description
$host$ Name of target server, for example, OWAserver1
$FullSMTP$ SMTP address to be appended to username, for example,
@domain.company.com
$filepath$ Location of files. The default assumption is c:\OWASuite.
$build$ Build of Exchange. The default is ***.
$theme$ Theme to use. The default is 0.
$authorization$ User account to log in to with password. The default is to select a random
user for the list in file C:\OWASuite\users.txt.
$senduser1$ - $senduser4$ Recipients to send mail to .Default is to select a random user for the list in
file C:\OWASuite\recipients.txt.
$folders$ Folders to create. The default is to select a random name from
C:\OWASuite\folders.txt.
$mailbox$ The virtual server name to log in to. The default is Exchange.
$Inbox$ Name of the Inbox folder. The default is Inbox (must be URL escaped).
$Calendar$ Name of the Calendar folder. The default is Calendar (must be URL
escaped).
$Contacts$ Name of the Contacts folder. The default is Contacts (must be URL
escaped).
$Drafts$ Name of the Drafts folder. The default is Drafts (must be URL escaped).
$Deleted%20Items$ Name of the Deleted Items folder. The default is Deleted%20Items (must
be URL escaped).
$Tasks$ Name of the Tasks folder. The default is Tasks (must be URL escaped).
$dlname$ Name of the distribution list. The default is currently set to
tempdlRANDNUMBER(0,99).
$pfolder$ Name of public folder. The default is currently set to folder-$USER$.
$User-Agent$ User-Agent string to be sent up to server. The default is Mozilla/4.0
(compatible, MSIE 6.0, Windows NT® 5.1, Microsoft Internet Explorer
update 328970 required "328970 - MS02-066: November, 2002,
Cumulative Patch for Internet Explorer."
$Accept-Language$ Accept-language string to pass to server. The default is en-us.
$protocol$ Protocol to pass to server. The default is HTTP.
Several variables are set by default and you should not need to configure them to run the suites in your
environment.
Table 11 Variables for the sample suites in Table 9 that should not need to be
changed.
$xml$ new XMLList
$timenow$ current datetime
$time+3mo$ $timenow$ ADDTIME $time+3mo$ 129600
$time-3mo$ $timenow$ ADDTIME $time-3mo$ -129600
$time+1hr$ $timenow$ ADDTIME $time+1hr$ 60
$dismisstime$ 4501-01-01T00:00:00.000Z
$dayofweek$ RANDNUMBER(1,127)
$cookie$ RESPHEADER(Set-Cookie)
Several variables are set by default but you can configure them to your preferences, because not all variables
are in all suites (Table 12).
Task Variables
Table 12 Outlook Web Access Task Variables
Variable Default
$tasksubject$ Tasksubject
$taskcompanies$ Taskcompanies
$taskbilling$ Taskbilling
$taskmileage$ Taskmileage
Variable Default
$taskdetails$ Taskdetails
Contact Variables
Table 13 Outlook Web Access contact variables
Variable Default
$businesshomepage$ http://businesswebpage.com-automation
$callbackphone$ 555-1212-automation
$co$ Country-USA-automation
$department$ Department-automation
$email1addrtype$ SMTP
$emailemailaddress$ automation@mail.com
$email2emailaddress$ automation2@mail.com
$email3emailaddress$ automation3@mail.com
$email1displayname$ DisplayNameAutomation
$email1originaldisplayname$ Email@automation.com
$email2displayname$ DisplayName2Automation
$email2originaldisplayname$ Email2@automation.com
$email3displayname$ DisplayName3Automation
$email3originaldisplayname$ Email3@automation.com
$emaillisttype$ 1
$facsimiletelephonenumber$ faxnumber-automation
$fileas$ 1
$givenName$ Firstnameautomation
$homeCity$ Homecityautomation
$homeCountry$ Homecountryautomation
$homefax$ Homefaxautomation
$homePhone$ Homephoneautomation
$homePostalCode$ Homepostalcode
$homeState$ Homestateautomation
$homeStreet$ Homestreetautomation
$internationalisdnnumber$ Homeisdnnumberautomation
Variable Default
$1$ CityAutomation
$mailingaddressid$ 2
$manager$ Managerautomation
$middlename$ Middlenameautomation
$mobile$ Mobileautomation
$nickname$ Nicknameautomation
$o$ Companyautomation
$organizationmainphone$ Organizationmainphoneautomation
$othercity$ Othercityautomation
$othercountry$ Othercountryautomation
$otherfax$ Otherfaxautomation
$othermobile$ Othermobileautomation
$otherpostalcode$ Otherpostalcodeautomation
$otherstate$ Otherstateautomation
$otherstreet$ Otherstreetautomation
$otherTelephone$ OtherTelephoneautomation
$pager$ Pagerautomation
$postalcode$ Postalcodeautomation
$profession$ Professionautomation
$roomnumber$ Roomnumberautomation
$secretarycn$ Secretarycnautomation
$secretaryphone$ Secretaryphoneautomation
$sn$ SnLastNameautomation
$spousecn$ Spousecnautomation
$state$ Stateautomation
$street$ Streetautomation
$subject$ Subjectautomation
$telephoneNumber$ TelephoneNumberautomation
$telephonenumber2$ telephonenumber2automation
$title$ Titleautomation
$fburl$ Fburlautomation
There are other Outlook Web Access suite files that you will want to change to fit your own environment
(Table 14).
Table 14 Outlook Web Access suite files that you need to change
File Content
users.txt Names, domain, and password for all of the users to be used.
Format of each must be in domain\user password. Each subsequent set of
credentials goes on a new line.
recipients.txt Alias for mail to be sent to
Format is in the form of user. Each subsequent user name goes on a new
line.
Folders.txt Name of folder to be created.
Format is in the form of "foldername." Each subsequent folder goes on a
new line.
Table 15 shows the additional Outlook Web Access suite script files that are used when running your
HTTP/DAV ESP 2003 test. For additional information about configuring your HTTP/DAV ESP 2003 test,
including information about which files are required for each Outlook Web Access suite, see the readme text
file located in the OWASuite folder.
Table 15 List of files required to use the Outlook Web Access suite
File
Appointment.1
Check_rule.1
checkmail.xml
contact_new.1
Delete_task.1
DeleteFromDumpster.1
Deletemessage1.1
Deletemessage2.1
Deletemessage3.1
Deletemessage4.1
Deletemessage5.1
Deletemessage6.1
desc.xml
folders.txt
forward.1
MeetingRequest.1
postwithatt.1
File
recipients.txt
save_rule.1
SaveWithAttachment.1
Search_contact.1
Search_mailbox.1
Search_mailbox.2
Search_mailbox.3
Search_tasks.1
SearchAfterDel.1
SearchCalendar.1
SearchDel.1
SearchDeletedItems.1
SearchInbox.1
SendMsgTo4Data.1
SendMsgTo4Data.10
SendMsgTo4Data.11
SendMsgTo4Data.2
SendMsgTo4Data.3
SendMsgTo4Data.4
SendMsgTo4Data.5
SendMsgTo4Data.6
SendMsgTo4Data.7
SendMsgTo4Data.8
SendMsgTo4Data.9
SendMsgTo4Data.RULE
SendWithAttachment.1
spellcheck_text.1
Users.txt
Simulating an Exchange Server 2003

User
Step 1: Create and Populate the Users Accounts
To simulate an Exchange Server 2003 user, you must create user accounts. You can run the suites against
empty mailboxes, but if you do, errors will be logged, because the suites expect items to exist in the mailbox.
To populate the accounts, you can run the suites with the expectation of errors.
Step 2: Configure ESP

To configure ESP, you must copy the Outlook Web Access suite files to the local computer. The default
assumption is to copy the OWASuite folder to the C:\ root with all scripts and included files under there.
Open ESP and configure the Server property to be the computer on which ESP is running. Set the Script File
property on the DAV module properties to be the file that you want to run. Set this sample to
C:\OWASuite\OWA_small.txt. Because you are only trying to validate that it is possible to run the scripts, set
the Script Instances property to 1.
In Host Properties, set the Log Results property to YES.
Step 3: Customize the Script

To successfully run the suites, you must customize the script by changing the following variables (Table 16).
Table 16 Outlook Web Access Suite variables that must be changed
$host$ Name of target server, for example, OWAserver1.
$FullSMTP$ SMTP address to be appended to user name, for example,
@domain.company.com.
$filepath$ Location of files. The default assumption is c:\OWASuite.
$build$ Build number for Exchange. The default is ***.
To successfully run the suites, you must create the following files (Table 17).
Table 17 Outlook Web Access Suite files that need to be created
File Content
users.txt Aliases, domain, and password for all of the users.
recipients.txt Alias for mail to be sent to.
line.
File Content
folders.txt Name of folder to be created.
Format is in the form of "foldername." Each subsequent folder goes on a
new line.
For the purposes of this verification, you should start with a single user in the users.txt file that will be logged
into. Likewise, if you list the same user in the recipients.txt file, you ensure that you have isolated your testing
to a single user who should be sending and receiving all messages. Initially, you want to reduce complexity to
verify that you can run these suites.
You might need to update other variables to run the suites, or the defaults may run successfully for you. The
variables listed above are variables that you definitely need to change. For a list of other potential changes, see
the section on Setting up the Test later in the document.
Step 4: Run
When you have configured your suites and ESP, you are ready to run them. Click the green traffic light icon to
start running the scripts. The script will loop as long as you allow it to run. It should only take a few seconds to
loop at least once. If the Successful Connections value is at least 5, then it has looped more than once. Finer
granulation is difficult without applying sleep requests, and it is unnecessary for this purpose.
Step 5: Analyze the Results

With the script stopped, open the log file (this is likely to be C:\log.txt). All actions and responses are logged
here, and any ECHOed comments and errors are also logged here. An initial 401 error can be expected as part
of the user login. Errors might also be logged if a mailbox is empty, because the suites expect items to exist in
the Inbox. Circumstances might also arise in which the tool reports no failures, but actions have not actually
been successful. After what appears to be a successful run, log in to a mailbox that you are sure has been
targeted by the automation, and verify that mail was received in the Inbox, that mail was sent from the Sent
Items, and that Contacts and Appointments exist (if the suite created them).
Now you can start adding loads to your server with multiple script instances and multiple clients pointed at the
same server.
IMAP4 Module for ESP

This module simulates multiple clients using the IMAP4 protocol. The module supports parameters for
configuring different protocol-specific options, options for how the test executes, and security options.
Examples are the server this client is targeting or the port number. The module simulates client actions by
running a script that contains ESP keywords and IMAP4 verbs.
This module reports a number of statistics during runtime. Statistics give counts of the number of modules or
protocol-specific events (for example, errors, successful or failed connection attempts, and so on) that occur
during a test run.
You can also log client actions and server responses during a test run. However, you cannot configure the
events that are logged.
Run-time Parameters
The following are the run-time parameters shown in ESP UI and an explanation of each (Table 18).
Table 18 IMAP4 module run-time parameters

Required
Enable Local Logging Enables/Disables Optional NO YES
creating a per-module NO
log file
Local Logfile Path <Not Yet Implemented – Required if Blank <valid path and log
additional logfiles will above is YES filename>
be created in the host log
location>.
Script Path Script file containing test Required Blank <valid path and script
steps to be run filename>
Encryption Method Encryption method to Required NONE SSL
use throughout the test NONE
duration
Authentication Method Authentication method Required BASIC NTLM
used during BASIC
Authentication state
Server Name Target server Required Blank <server name string or IP
address>
Timeout Period (in minutes) to Optional 0 <0-n>
wait for a server
response before closing
connection. 0 (the
default) means wait
indefinitely.
Fast Shutdown Reserved for future use Optional 0
Start Time Delay (ms) Interval (in milliseconds) Required, >= 0 <1-n>
to wait between the start 0
of each user instance
User Instances Number of client Required 1 <1-n>
sessions to simulate
Statistics
The following are the run-time statistics that are reported to the ESP UI and an explanation of each (Table 19).
Table 19 IMAP4 module run time statistics

Errors Number of errors
Connections Number of active connections established so far
Disconnected Number of connections that have been ended
Timeouts Number of timeouts on server responses
APPEND Number of APPEND commands
AUTHENTICATE Number of AUTHENTICATE commands
CAPABILITY Number of CAPABILITY commands
CHECK Number of CHECK commands
CLOSE Number of CLOSE commands
COPY Number of COPY commands
CREATE Number of CREATE commands
DELETE Number of DELETE commands
EXAMINE Number of EXAMINE commands
EXPUNGE Number of EXPUNGE commands
FETCH Number of FETCH commands
FETCHUID Number of FETCHUID commands
IDLE Number of IDLE commands
LIST Number of LIST commands
LOGOUT Number of LOGOUT commands
LSUB Number of LSUB commands
NOOP Number of NOOP commands
RENAME Number of RENAME commands
SEARCH Number of SEARCH commands
STATUS Number of STATUS commands
SELECT Number of SELECT commands
STORE Number of STORE commands
SUBSCRIBE Number of SUBSCRIBE commands
UIDCOPY Number of UIDCOPY commands
UIDFETCH Number of UIDFETCH commands
UIDSEARCH Number of UIDSEARCH commands
UIDSTORE Number of UIDSTORE commands
UNSUBSCRIBE Number of UNSUBSCRIBE commands
DONE Number of DONE commands

The following are the reserved word script verbs that are specific to this test module and a description of each
is optional.
Table 20 IMAP4 module reserved word scripts

CONNECT CONNECT Opens a TCP/IP connection to
the IMAP4 Server.
SELECT SELECT <mailbox name> Select a specified mailbox. This
will also populate a message #
cache that you can use later in
SELECT "Drafts" commands using the FIRST,
NEXT, ALL, SAME, and LAST
macros.
DELETE DELETE <mailbox name> Deletes a specified mailbox.
DELETE "mytestfolder1"
EXAMINE EXAMINE <mailbox name> Examines a specified mailbox.
EXAMINE "Public Folders/Local

Reports"
CREATE CREATE <mailbox name> Creates a specified mailbox.
CREATE "INBOX/folder1"
RENAME RENAME <mailbox name> <new Renames a specified mailbox.
mailbox name>
RENAME "testfolder1" "testfolder2"

STATUS STATUS <mailbox name> Returns the status of a specified
<(attributes)> mailbox and its attributes.
STATUS "INBOX" (UNSEEN)


LIST LIST <reference name> <wildcard> Lists folders. Reference name
and wildcard can be used to
limit the output of the listing.
LIST "INBOX/" f* (This example lists all
mailboxes under INBOX
starting with 'f'.)
NOOP NOOP No Operation request.
LOGOUT LOGOUT Closes the connection to the
server.
EXPUNGE EXPUNGE Calls the Expunge command on
the currently selected folder.
This will delete any items
flagged for deletion.
CLOSE CLOSE Closes the currently selected
folder. This will delete any
items flagged for deletion with
the folder.
CAPABILITY CAPABILITY Requests the capability string
from the server.
CHECK CHECK Performs a check command
against the server (equivalent to
a NOOP in Exchange).
SUBSCRIBE SUBSCRIBE <mailboxname> Subscribes to the specified
mailbox.
SUBSCRIBE "Drafts"
UNSUBSCRIBE UNSUBSCRIBE <mailboxname> Unsubscribes from the specified
mailbox.
UNSUBSCRIBE "Sent Items"

LSUB LSUB <reference name> <wildcard> Lists Subscribed folders.
Reference name and wildcard
can be used to limit the output of
LSUB "" "*" the listing.
APPEND APPEND <mailbox name> <file Appends the contents of
name> <filename> to the mailbox.
APPEND "Public Folders/Drop Here"

c:\temp\test1.txt

FETCH FETCH <num|num set> <msg data Fetches an item or set of items
item string> from the currently selected
mailbox.
FETCH 1 RFC822
For more information on types
of msg data items, refer to
FETCH 1:4 RFC3501.
BODY[HEADER.FIELDS(subject
from)]
FETCH 300:325 (INTERNALDATE

BODY[2.MIME])
COPY COPY <num|num set> <dest mailbox Copies an item or set of items
name> from the currently selected
mailbox to a destination mailbox.
COPY 1 "Saved Items"

STORE STORE <num|num set> <msg data Stores the specified item value
item name> <item value> on the set of items in the
currently selected mailbox.
Most common use of the STORE
STORE 1 +flags \deleted
command is to set \deleted status
and other "flags" to either on or
STORE 3:48 –flags \seen \answered off.
FETCHUID FETCHUID Translates into a "FETCH 1:*

UID." This will populate a UID
cache that can later be used in
commands using the FIRST,
NEXT, ALL, SAME, and LAST
macros.
UIDFETCH UIDFETCH <uid num|uid num set> Similar to a FETCH command,
<msg data item string> but uses a UID reference instead
of message number.
UIDFETCH 613 RFC822

UIDSTORE UIDSTORE <uid num|uid num set> Similar to a STORE command,
<msg data item name> <item value> but uses a UID reference instead
of message number.
UIDSTORE 332 +flags \answered

UIDCOPY UIDCOPY <uid num|uid num set> Similar to a COPY command,
<dest mailboxname> but uses a UID reference instead
of message number.
UIDCOPY 390 "Public Folders/public

knowledge"

Both the SELECT and FETCHUID commands create a cache of IDs that can be used later with the following
macros:
FIRST (num) – gets replaced with a set representing the first n items in the cache
NEXT – gets replaced with the next item in the cache
SAME – gets replaced with the same item in the cache
LAST (num) – gets replaced with a set representing the last n items in the cache
ALL – gets replaced with a set representing all of the items in the cache
The following describes the usage of these macros with the verbs that support them:
FETCH Command: (Requires a completed SELECT command before using)
FETCH FIRST (num) <msg data item string>
FETCH LAST (num) <msg data item string>
FETCH ALL <msg data items string>
FETCH NEXT <msg data items string>
FETCH SAME <msg data items string>
STORE Command: (Requires a completed SELECT command before using)
STORE FIRST (num) <msg data item name> <item value>
STORE LAST (num) <msg data item name> <item value>
STORE ALL <msg data item name> <item value>
STORE SAME <msg data item name> <item value>
STORE NEXT <msg data item name> <item value>
COPY command: (Requires a completed SELECT command before using)
COPY FIRST (num) <dest mailboxname>
COPY LAST (num) <dest mailboxname>
COPY ALL <dest mailboxname>
COPY SAME <dest mailboxname>
COPY NEXT <dest mailboxname>
UID FETCH command: (Requires a completed FETCHUID command before using)
UIDFETCH FIRST (num) <msg data item>
UIDFETCH LAST (num) <msg data item>
UIDFETCH ALL <msg data item>
UIDFETCH SAME <msg data item>
UIDFETCH NEXT <msg data item>
UID STORE Command: (Requires a completed FETCHUID command before using)
UIDSTORE FIRST (num) <msg data item name> <item value>
UIDSTORE LAST (num) <msg data item name> <item value>
UIDSTORE ALL <msg data item name> <item value>
UIDSTORE SAME <msg data item name> <item value>
UIDSTORE NEXT <msg data item name> <item value>

UID COPY Command: (Requires a completed FETCHUID command before using)
UIDCOPY FIRST (num) <dest mailboxname>
UIDCOPY LAST (num) <dest mailboxname>
UIDCOPY ALL < dest mailboxname>
UIDCOPY SAME < dest mailboxname>
UIDCOPY NEXT < dest mailboxname>
Example Scripts
Table 21 Example IMAP4 module scripts

Test Case Description
CONNECT This script connects to a
user's Inbox, reads all the
AUTHENTICATE SEQULIST(userlist.txt)
messages in the Inbox, and
SELECT "INBOX" logs out.
FETCH ALL RFC822
LOGOUT
SLEEP 60000
CONNECT This script appends a
message to a user's Inbox.
AUTHENTICATE myuser1 myuserspassword
APPEND "INBOX" c:\myfiles\testfile1.txt
CLOSE
LOGOUT
CONNECT This deletes all the
messages in the user's
AUTHENTICATE mydomain\user1 password1
Inbox.
SELECT INBOX
STORE ALL +flags \deleted
EXPUNGE
LOGOUT
CONNECT This will walk a
folderlist.txt file, fetch all
AUTHENTICATE RANDLIST(userlist.txt)
the subjects of each
LOOP 10 message, and mark each
SELECT SEQULIST(folderlist.txt) message as read.
FETCH ALL body[header.fields (subject)]

STORE ALL +flags \seen
CLOSE
ENDLOOP
LOGOUT

User
Step 1: Create and Populate the Users
You can populate a mailbox in many ways. The method described here uses an IMAP4 module and an IMAP4
ESP script that will populate a mailbox using the APPEND command. For example:
CONNECT
CAPABILITY
LOOP 10
APPEND "INBOX" MyDataFile.eml
ENDLOOP
LOGOUT
REM # Sleep for one day
SLEEP 86400000
The SEQULIST (userlist.txt) command walks through the userlist.txt file that you created earlier. Each "User
Instance" of the script represents a different entry in the list. Therefore, if you have 100 mailboxes that you
want to populate, you should have 100 entries in your userlist.txt file and 100 User Instances when you start
the ESP script.
The APPEND "INBOX" MyDataFile.eml appends the contents of MyDataFile.eml to the user's inbox (local
path relative to the location of the ESP Script), and the LOOP 10 … ENDLOOP combination will run through
the APPEND command 10 times.
The APPEND command will generate messages in a way that is similar to local SMTP delivery. If you want to
test your enterprise using predominantly MAPI clients (Outlook), consider a tool such as LoadSim, for
generating mailbox content.
The SLEEP command is used to prevent the script from running again. (Without the SLEEP command, ESP
will automatically start a script from the beginning after it has finished running.)
A variation on this is to use a SEQULIST or RANDLIST option for the list of files, such as:
LOOP 10
APPEND "INBOX" SEQULIST(imap4messages.txt)
APPEND "INBOX" SEQULIST(imap4messages.txt)
ENDLOOP
Where imap4message.txt is a text file that contains a single message file name on each line.
When ESP runs this block, it replaces the listing in the imap4messages.txt file at runtime and appends that file
to the Inbox. In this way, you can maintain one file that represents your message set, in case you want to
add/remove messages in the future. Also, if you use RANDLIST instead of SEQULIST, you can obtain
random message coverage.
Tip
To avoid confusion when you try to locate files from scripts, put all files (Workspace.ini files, ESP
scripts, associated list files, and message data files) in a local directory while you work. If you want
to use relative paths, they must be relative to the script file.

When customizing the IMAP4 scripts, you generally focus on number and frequency of client connections. The
number of client connections is controlled with the User Instances property of the ESP module, and the
frequency is controlled with the ending SLEEP statement in the scripts. Modify these two values to
accommodate your test scenario.
Two common methods can be used to iterate through userlist.txt files. The first method is a SEQULIST macro,
and the second is a RANDLIST macro. SEQULIST maintains a correct state of mailbox connections
throughout the test (because, unlike RANDLIST, you ensure only one client connection to any one mailbox).
RANDLIST simulates more "real world" scenarios and provides additional benefit if your mailboxes are
populated with messages of varying sizes and types.
Simple Script Example

You can use the following simple script to simulate client load on an Exchange server. This script will walk
through the userlist.txt file and read all of the messages in the user's Inbox.
CONNECT
CAPABILITY
SELECT "INBOX"
FETCH ALL RFC822
LOGOUT
SLEEP 60000
Advanced Script Example

The following script, (while quite involved), can be used to simulate a user reading 10 messages and then
performing operations on those 10 messages (such as moving them to subfolders, setting properties, and
deleting).
REM # This script assumes the presence of at least 10 message currently in the users
INBOX.
REM # This script will leave the INBOX with the first 10 messages of the INBOX
remaining... all others will be purged.
CONNECT
CAPABILITY
AUTHENTICATE RANDLIST(userlist.txt)
CREATE "BackMeUp"
SELECT "INBOX"
COPY 1:10 "BackMeUp"
CREATE "Other Mail"
CREATE "Trash"
LIST "" "*"
SELECT "INBOX"
FETCHUID
UIDFETCH 1:10 (FLAGS)
UIDFETCH UIDALL (UID RFC822.SIZE rfc822.header)
NOOP
UIDFETCH FIRST 1 (UID RFC822.SIZE RFC822)
UIDCOPY 1 "Trash"
UIDSTORE 1 +FLAGS (\Deleted)
UIDFETCH NEXT (UID RFC822.SIZE RFC822)
UIDCOPY 2 "Other Mail"
UIDCOPY 1 "Trash"
UIDCOPY 2 "Other Mail"
UIDCOPY 1 "Trash"
CHECK
NOOP
FETCH LAST 1 (UID)
UIDCOPY LAST 2 "Other Mail"
UIDSTORE LAST 2 +FLAGS (\Deleted)
CLOSE
SELECT "Other Mail"
FETCHUID
UIDFETCH 1:* (FLAGS)
NOOP
UIDFETCH FIRST 1 (UID RFC822.SIZE RFC822)
FETCHUID
UIDCOPY LAST 4 "Trash"
CLOSE
SELECT "INBOX"
FETCHUID
UIDFETCH 1:10 (FLAGS)
NOOP
UIDCOPY LAST 5 "Trash"
EXPUNGE
CLOSE
SELECT "TRASH"
STORE ALL +FLAGS (\DELETED)

EXPUNGE
LIST "TRASH" "*"
DELETE "Other Mail"
DELETE "TRASH"
CLOSE
SELECT "BackMeUp"
COPY 1:10 "INBOX"
DELETE "BackMeUp"
LOGOUT
Step 3: Run
Select all the counters under the MSExchangeIMAP4 that pertain to your script. Some helpful counters are:
• Connections Current
• Connections Total
• CAPABILITY Total
• LOGOUT Total (Compare this to Connections Total and Capability Total to ensure that all of the users are
completing the scripts.)
• UID or FETCH Rate (Several factors affect this such as server load, message size, and the type of item
requested.)
Note
Any UID commands display under the UID counters. For example, a UIDFETCH in the script appears
under the UID Perfmon counters, not under the FETCH counters.
Using Protocol Logging on the Server

The protocol logging registry key can help diagnose problems. Protocol logging can be helpful because a
separate log is always created for each open connection. This is in contrast to the ESP log, which logs all
connections into one file. For more information about protocol logging, see Microsoft Knowledge Base article
299778, "XGEN: How to Activate Protocol Logging for POP3 and IMAP4"
(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299778).
Tip
Logging Level 4 is often the most useful, because it logs all interaction between the client and the
server but truncates actual message data.

A good stress run will yield the following results, which you can observe through Perfmon:
• IMAP4 connections can be created throughout the test (\Connections Current is typically the same value
throughout the test).
• Number of IMAP4 verbs should be directly proportional to the number of total connections. (For example,
if your script has one close statement in it, then \Connections Total and \CLOSE Total should be equal.)
• No errors should be reported, unless your script is specifically testing error conditions.
Always check event logs for important messages.
LDAP Module for ESP

This module simulates multiple clients using the LDAP protocol. The module supports parameters for
Examples are the server that this client is targeting, the port number, and the LDAP version. A script that
contains ESP keywords and LDAP script commands specifies the client actions.
This module also reports a number of statistics during runtime. Statistics give counts of the number of modules
or protocol-specific events (for example, errors, successful or failed connection attempts, and so on) that occur
during a test run. You can also log client actions and server responses during a test run. You cannot configure
the events that are logged.
The following section describes the commands that are specific to the LDAP test module and the parameters
the module requires.
Parameters
Table 22 lists the run-time parameters shown in the ESP UI and an explanation of each.
Table 22 OLEDB module run-time parameters

Required
Script name The name of the LDAP Required <valid path>
script to process
Encryption method Currently unsupported Required NONE
(Change Port Number to
636 or 3269 to use SSL,
although this is currently
untested.)
Authentication method Method used by the Required NTLM SIMPLE
server to authenticate DPA
client sessions. The
server may not support NTLM
these methods, however. NEGOTIATE
MSN
SICILY
Server Name The server to connect to Required <valid UNC or IP
address>
Client Timeout Duration (in Required 120000 0-n
milliseconds) before
abandoning a pending
LDAP operation
(0=never abandon). This
is independent of LDAP
Time Limit (see below).
LDAP Version LDAP version (2 or 3) Required 3 2
3

Required
LDAP Deref LDAP connection Required 0 0
ld_deref value (0=Never, 1
1=Searching, 2=Finding,
3=Always) 2
3
LDAP Referrals LDAP referrals value (0 Required 0 0
= off, 1=on, 32=chase 1
subordinate referrals,
64=chase external 32
referrals) 64
LDAP Time Limit LDAP connection Required 60000 0-n
ld_timelimit value (0=no
limit)
LDAP Size Limit LDAP connection Required 0 0-n
ld_sizelimit value (0=no
limit)
LDAP Port Number Port number for LDAP Required 389 389
to use (389, 636, 3268, 636
3269)
3268
3269
Start time delay (ms) Delay (in milliseconds) Required 200 0-n
between starting virtual
users
User Instances Number of Required 1 1-n
connections/virtual users
to use
Statistics
Table 23 LDAP run-time statistics

Connections Number of current LDAP connections
Connect Commands Number of ldap_open calls
Bind Commands Number of ldap_bind calls
Search Commands Number of ldap_search_ext calls
Modify Commands Number of ldap_modify_ext calls
Add Commands Number of ldap_add_ext calls
Delete Commands Number of ldap_delete_ext calls
Compare Commands Number of ldap_compare_ext calls
Rename Commands Number of ldap_rename_ext calls
Quit Commands Number of ldap_unbind calls

is optional.
Table 24 OLEDB module reserved work scripts
Reserved Syntax and Example Description

Script Verb
CONNECT CONNECT Connects to the server (via
ldap_open API) the name of
which is specified in the
"Server name" parameter of
the LDAP test module via the
port specified in the "LDAP
Port Number" parameter of
the LDAP test module.
The "LDAP Deref," "LDAP
Options," "LDAP Time
Limit," "LDAP Size Limit,"
and "LDAP Version"
parameters of the LDAP test
module are set on this
connection if it is successful,
and errors are emitted to the
log if any of them fail to
succeed (usually due to an
invalid parameter value).
BINDSIMPLE BINDSIMPLE <DN={dn};> [user name={name};] Performs an LDAP ldap_bind
[password={passwd};] [domain={domain};]" (not ldap_simple_bind despite
the name) to the {dn} or "" if
ANONYMOUS.
BINDSIMPLE ANONYMOUS
Credentials are constructed
based on the user name,
password, and domain
specified. If any of these are
omitted, empty strings are
substituted.

Script Verb
Authentication is done based
on the "Authentication
method" parameter of the
LDAP test module.
SEARCH SEARCH <SUBTREE|ONELEVEL|BASE> RETURN Searches the directory (via
<ALL|SUBSET|attrib1,attrib2,…> DN=<dn>; ldap_search) for the records
FILTER=<filter>; matching the <filter>, starting
from base DN={dn} with
scope equal to SUBTREE,
ONELEVEL, or BASE,
returning all of the attributes
(ALL), a hard-coded subset
(sn, givenName), or a
specified subset (comma-
separated list of attributes with
no spaces).
Refer to RFCs 1960/2254 (A
String Representation of
LDAP Search Filters) and the
examples for the format of a
filter, although this
implementation requires at
least one level of parenthesis.
For example, use
FILTER=(objectClass=*);,
not FILTER=objectClass=*;.
MODIFY MODIFY DN={dn}; {attrib1}={value11||value12|| Calls the LDAP API
…:R|A|D} [&& {attrib2}={value21||value22||…:R|A| ldap_modify to modify the
D} [&& …]] record DN={dn} with the
attributes and values specified
(&& separates the attributes.)
Appended to each value can
be a :R, a :A, or a :D to
specify replace, add, or delete.
If this is omitted, it will
default to add.
A value can be a string
(trailing white space is
ignored, leading white space
is not), a HEX: sequence (for
example,
attrib=HEX:80000000), or a
FILE containing the data (for
example,
attrib=FILE:c:\ldapdata.txt).
ADD ADD DN={dn}; {attrib1}={value11||value12||…:R|A| Calls the LDAP API ldap_add
D} [&& {attrib2}={value21||value22||…:R|A|D} [&& to add the record DN={dn}
…]] with the attributes and values

Script Verb
specified.
Appended to each value can
be a :R, a :A, or a :D to
specify replace, add, or delete
(although these can be
specified, if they are not
"add," the behavior is
undefined). If this is omitted,
it will be set to add.
A value can be a string
(trailing white space is
ignored; leading white space
is not), a HEX: sequence (for
example,
attrib=HEX:80000000), or a
FILE containing the data (for
example,
attrib=FILE:c:\ldapdata.txt).
DELETE DELETE DN={dn}; Calls the LDAP API
ldap_delete to delete the
record {dn} from the
directory.
COMPARE COMPARE DN={dnsrc}; {attrib}={value} Calls the LDAP API
ldap_compare, which
compares the attribute {attrib}
on the {dn}. It returns true if
the values are the same.
RENAME RENAME DN={olddn}; DN={rdn}; DN={parent}; Calls the LDAP API
{TRUE|FALSE}" ldap_rename, which
moves/renames {olddn} to
{rdn},{parent}.
The final Boolean specifies
whether to delete the attributes
on the existing distinguished
name while renaming it.
IF IF DN={dn}; FILTER={filter}; COMMAND Calls the LDAP API
ldap_search_s with
scope=LDAP_SCOPE_BASE
, baseDN={dn}, and
filter={filter}.
If the search returns the
distinguished name (in other
words, the filter evaluates to
TRUE), proceed with the
LDAP script COMMAND,
otherwise do nothing.

Script Verb
QUIT QUIT Closes the LDAP connection
by issuing an LDAP API
ldap_unbind call.

The following are the LDAP APIs (as specified in MSDN®) invoked as a result of the various SCRIPT
module verbs. Ldap_open and ldap_bind_s are synchronous API calls. The rest are asynchronous, although the
module waits for the response (through ldap_result) before proceeding to the next script verb.
m_pLdapClient = ldap_open(m_pszServer, m_dwPort);
Invoked by the script command CONNECT, where m_pszServer is the pointer to the Server name parameter,
and m_dwPort is the Port number parameter.
ldap_bind_s(m_pLdapClient, szDN, m_ulLdapMethod == LDAP_AUTH_SIMPLE ?
(PCHAR)szPasswd : (PCHAR)&AuthIdentity, m_ulLdapMethod);
Invoked by the script command BINDSIMPLE, where m_pLdapClient is the LDAP connection pointer from
ldap_open; szDN is a pointer to a string that contains the base distinguished name;AuthIdentity is a
SEC_WINNT_AUTH_IDENTITY structure constructed from the user name, domain, and password;
szPassword is a pointer to the string that contains the password; and m_ulLdapMethod is the Authentication
Method parameter.
ldap_search_ext(m_pLdapClient, szDNBase, ulScope, szFilter, rgszAttribList, FALSE,
NULL, NULL, m_ld_timelimit, m_ld_sizelimit, &m_msgid);
Invoked by the script command SEARCH, where m_pLdapClient is the LDAP connection pointer from
ldap_open; szDNBase is a pointer to a string containing the base distinguished name of the search; ulScope is
the scope specified (LDAP_SCOPE_BASE, LDAP_SCOPE_ONELEVE,L or LDAP_SCOPE_SUBTREE);
szFilter is the pointer to the filter string; rgszAttribList is a NULL terminated array of string pointers
enumerating the attributes to return; and m_ld_timelimit and m_ld_sizelimit are the Time Limit and Size Limit
parameters.
ldap_modify_ext(m_pLdapClient, szDN, ppMods, NULL, NULL, &m_msgid);
Invoked by the script command MODIFY, where m_pLdapClient is the LDAP connection pointer from
ldap_open; szDN is a pointer to the string that contains the distinguished name to modify; and ppMods is a
pointer to an LDAPMod structure (containing data about the modification to perform).
ldap_add_ext(m_pLdapClient, szDN, ppMods, NULL, NULL, &m_msgid);
Invoked by the script command ADD, where m_pLdapClient is the LDAP connection pointer from ldap_open;
szDN is a pointer to the string that contains the distinguished name to add; and ppMods is a pointer to an
LDAPMod structure (which contains data about the attributes to add).
ldap_rename_ext( m_pLdapClient, szOldDN, szNewRDN, szNewParent, (int)fDelete,
NULL, NULL, &m_msgid);
Invoked by the script command RENAME, where m_pLdapClient is the LDAP connection pointer from
ldap_open; szOldDN is a pointer to the string containing the original distinguished name; szNewRDN a pointer
to the string that contains the new RDN; szNewParent a pointer to the string that contains the new parent;
fDelete equal to 1 or 0 depending on whether deleting the attributes is specified.
ldap_compare_ext(m_pLdapClient, szDN, szAttrib, szValue, NULL, NULL, NULL,
&m_msgid);
Invoked by the script command COMPARE, where m_pLdapClient is the LDAP connection pointer from
ldap_open; szDN is a pointer to the string that contains the distinguished name; szAttrib a pointer to the string
that contains the attribute name; szValue a pointer to the string that contains the attribute value.
ldap_delete_ext(m_pLdapClient, szDN, NULL, NULL, &m_msgid);
Invoked by the script command DELETE, where m_pLdapClient is the LDAP connection pointer from
ldap_open, and szDN is a pointer to the string that contains the distinguished name to be deleted.
ldap_unbind(m_pLdapClient);
Invoked by the script command QUIT, where m_pLdapClient is the LDAP connection pointer from ldap_open.
Example Script
Table 25 LDAP module example script
CONNECT Conducts 1000
searches for
BINDSIMPLE ANONYMOUS
users against a
LOOP 1000 directory
SEARCH SUBTREE RETURN cn,mailNickName,objectGuid DN=dc=server,dc=com; service.
FILTER=(&(displayName=userRANDNUMBER(1,1000))(objectClass=user));
SLEEP 100
ENDLOOP
QUIT
CONNECT Modifies a
user's data.
BINDSIMPLE dn=cn=administrator,cn=users,dc=server,dc=com; user name=administrator;
password=; domain=mydomain;
MODIFY DN=CN=user1,CN=Users,dc=server,dc=com; sn=RANDALPHA(10):R &&
phone=555-1212:R
QUIT
CONNECT Conditionally
modifies a set of
BINDSIMPLE dn=cn=administrator,cn=users,dc=server,dc=com; user name=administrator;
distinguished
password=; domain=mydomain;
names.
LOOP 100
IF DN=CN=userSEQUNUMBER(1,100,1),CN=Users,dc=server,dc=com;
FILTER=(objectClass=contact); MODIFY
DN=CN=userSAMESEQUNUMBER(1,100,1),CN=Users,dc=server,dc=com;
sn=RANDALPHA(10):R && phone=555-1212:R
QUIT
OLEDB Module for ESP

This module simulates multiple clients using the OLEDB COM interfaces. The module supports parameters for
configuring OLEDB-specific options and options for how the test runs. An example is the server this client is
targeting. Client actions are simulated by running a script that contains ESP keywords and OLEDB-specific
verbs. Some simple environment variables and flow-control constructs are also supported.
protocol-specific events (for example, errors) that occur during a test run.
You can also log client actions and server responses during a test run. You cannot configure the events that are
logged.
Run-time Parameters
Table 26 OLEDB module run-time parameters

Required
Script File Script file to run a test Required Blank <valid path>
Server Server name Required Blank <UNC server name or IP
address>
Start Time Delay (ms) Duration (in Required, > 0 1-n
milliseconds) that each than 0
script instance will be
delayed from starting

is optional.
Table 27 OLEDB module reserved work scripts

Verb
COPYOBJ COPYOBJ {Source URL} {Resource} {Destination URL} Copies trees or sub-
trees of rows
designated by a
SETVAR PrivateURL=File://./BackofficeStorage/ source URL to a
%UserDNSDomain%/MBX/TestUser1 location specified by
COPYOBJ %PrivateURL%/Inbox/ SrcFooMsg %PrivateURL a destination URL.
%/Inbox/DestFoomsg
CREATECOLLE CREATECOLLECTION {URL/FolderObjectName} Creates a folder
CTION object in the store.
SETVAR PrivateURL=File://./BackofficeStorage/
%UserDNSDomain%/MBX/TestUser1
CREATECOLLECTION %PrivateURL%/Inbox/FooFolder1
CREATERESOU CREATERESOURCE {URL/ResourceName} {optional file to Creates a resource
RCE stream in} object in the store.
CREATERESOURCE %PrivateURL%/FooMessage1
CREATERESOURCE %PrivateURL%/FooMessage2
MessageBody.Txt

Verb
DELETEOBJ DELETEOBJ {Source URL} {Resource} Deletes the trees or
sub-trees specified
by the source URL.
DELETEOBJ %PrivateURL%/Inbox/ FooMessage1
DELETEOBJ %PrivateURL%/Inbox/ FooFolder1
DELETEPROP DELETEPROP {URL} {Property Name} Deletes a property
from a row.
DELETEPROP %PrivateURL%/Inbox/FooMessage2
mapi:0x0037001f
GETMESSAGE GETMESSAGE {URL/Message} {Optional Output File} Binds to a specified
resource and
retrieves the
SETVAR PrivateURL=File://./BackofficeStorage/ resource from a
%UserDNSDomain%/MBX/TestUser1 stream object.
GETMESSAGE %PrivateURL%/Inbox/FooMessage2
GETMESSAGE %PrivateURL%/Inbox/FooMessage2
C:\TEMP\MsgOutput.Txt
GETPROP GETPROP {URL} {Property Name} {Property Type} {Output Reads a property
file} from a row.
GETPROP %PrivateURL%/Inbox/FooMessage3
mapi:0x0037001f STRING
mapi:0x00170003 INT
DAV:displayname STRING D:\Property1.Txt
MSGBOX $$The name of the message is %PROPVALUE%$$
DAV:getcontentlength INT D:\Property2.Txt
MSGBOX $$The size of the message is %PROPVALUE%$$
Note
Property Type can be [STRING | INT | BINARY]
Properties that are INT and STRING types are stored in the
system variable PROPVALUE. Each call to GETPROP replaces
the last value stored in the variable "PROPVALUE"

Verb
GETPROVIDER GETPROVIDER {BINDER | DATASOURCE | DSOBIND} Starts and initializes
{ProgID} {Binding URL} the Exchange
OLEDB provider
via a Binder or
REM *** Set a variable for the user name Datasource.
SETVAR User Name = User1
REM *** Create a session via a binder object
GETPROVIDER BINDER EXOLEDB.BINDER
File://./BackOfficeStorage/%USERDNSDOMAIN
%/MBX/%User Name%
REM *** Create a session by creating a datasource object
GETPROVIDER DATASOURCE EXOLEDB.DATASOURCE
File://./BackOfficeStorage/%USERDNSDOMAIN%/Public
Folders
REM ***
GOTO GOTO {label} Forces script code to
branch
SETVAR Case = 1
unconditionally to
IF %Case% = 3 Then GOTO CASE3
another part of the
script.
GOTO END
:CASE3
MSGBOX $$Running Test Case 3$$
GOTO END
:CASE2
GOTO END
:CASE1
GOTO END
:END
MSGBOX $$End of Test Suite$$
STOP
Note
When executing a GOTO script command, you must use a label
somewhere in the script, otherwise an error will occur. A label is
designated by a leading colon and then the name of the label (see
example above).

Verb
IF...THEN IF {expression} {= | < | > | != } {expression} THEN Enables conditional
{Command} processing to be
performed in the
OLEDB ESP script.
IF 123 = 123 THEN MSGBOX $$This expression is true$$
IF 123 = 456 THEN MSGBOX $$This expression is not true$$
SETVAR X = 1
IF %X% = 1 THEN MSGBOX $$This expression is true$$
SETVAR Y = 1
IF %X% = %Y% THEN MSGBOX $$The expression %X%
equals %Y% is a true statement$$
IF %X% > %Y% THEN MSGBOX $$This statement won't get
executed$$
IF %X% < %Y% THEN CREATERESOURCE
Exstore://LocalHost/Private/User/Inbox/SomeMsg%Y%
IF %X% != %Y% THEN CREATECOLLECTION
Exstore://LocalHost/Private/User/Inbox/FooFolder%X%
ITERATE ITERATE {number of iterations} Iterates through a
rowset a specified
number of times
SAVEROWSET ON after issuing a
SETVAR PrivateURL=File://./BackofficeStorage/ SELECT statement.
SELECT $$SELECT "DAV:displayname" FROM
SCOPE('SHALLOW TRAVERSAL OF "%PrivateURL
%/INBOX/"')$$
ITERATE 100
Note
SAVEROWSET must be turned on before using this feature.
LAUNCHPROCE LAUNCHPROCESS {Filename} {Argument 1, Argument 2, ...} Starts a specified
SS {NOWAIT | WAIT} execute command
and optionally waits
for the program to
REM *** Launch Notepad.Exe and wait for the program to finish finish running
running before continuing to run commands in Medusa before proceeding.
LAUNCHPROCESS NOTEPAD.EXE D:\Medusa_Log.Txt
WAIT
REM *** Launch Notepad.Exe and do not wait for the program
to finish running before continuing to run commands in Medusa
LAUNCHPROCESS NOTEPAD.EXE D:\Medusa_Log.Txt
NOWAIT

Verb
LOGLEVEL LOGLEVEL {ERRORS | ALL} Logs all commands
and the status of the
LOGLEVEL ERRORS
commands to the log
LOGLEVEL ALL file (regardless of
error).
MOVEOBJ MOVEOBJ {Source URL} {Resource} {Destination URL} Moves the trees or
sub-trees specified
by the source URL
REM *** Set a variable for the URL to a location
SETVAR PrivateURL=File://./BackofficeStorage/ specified by a
%UserDNSDomain%/MBX/TestUser1 destination URL.
MOVEOBJ %PrivateURL%/Inbox/ SrcFooMessage1
%PrivateURL%/Inbox/DestFooMessage1
MSGBOX MSGBOX {Message Text} {Optional caption for dialog box} Temporarily
suspends the ESP
test script and
MSGBOX $$This is some text to be displayed$$ $$Exchange displays a dialog
Rocks$$ box with the
SETVAR FooVar = Hello World! specified text.
MSGBOX $$%FooVar%$$
SETVAR X = Hi
MSGBOX %X%
Note
Any text that includes spaces must be enclosed in "$$." This also
includes variables in which the value contains spaces.
SAVEROWSET SAVEROWSET { ON | OFF} Turns ON or OFF
the persistence of an
IRowset object.
SAVEROWSET ON
SELECT $$SELECT "DAV:displayname" FROM
%/INBOX/"')$$
ITERATE 100
Note
Used in conjunction with ITERATE.

Verb
SELECT SELECT {SQL Select} {Optional output file | NULL} Runs the specified
SQL Select
REM *** Set a variable for the URL
statement against
the Exchange store.
SELECT $$SELECT mapi:0x0037001f FROM
%/Inbox/"')$$
Note
SQL command must be surrounded by $$. If NULL is specified
as the argument for the OUTPUT file, then the SELECT will
only traverse the entire rowset. This is different from not
specifying an OUTPUT file, which the rowset NOT, not to be
traversed before being released. This provides a way to determine
how much time is spent creating the rowset and how much time
is spent traversing it.
SETBINDFLAGS SETBINDFLAGS { DBBINDURLFLAG_READ | Sets a system
(OLEDB Module)
DBBINDURLFLAG_WRITE |
variable used during
DBBINDURLFLAG_READWRITE | all of the calls to
DBBINDURLFLAG_SHARE_DENY_READ | IBindResource::Bin
DBBINDURLFLAG_SHARE_DENY_WRITE | d for the
DBBINDURLFLAG_SHARE_EXCLUSIVE | DBBINDURLFLA
DBBINDURLFLAG_SHARE_DENY_NONE | G parameter.
DBBINDURLFLAG_RECURSIVE |
DBBINDURLFLAG_OUTPUT |
DBBINDURLFLAG_ASYNC |
DBBINDURLFLAG_COLLECTION |
DBBINDURLFLAG_OPENIFEXISTS |
DBBINDURLFLAG_OVERWRITE |
DBBINDURLFLAG_ISSTRUCTUREDDOCUMENT |
NULL }
SETBINDFLAGS DBBINDURLFLAG_READ
DBBINDURLFLAG_WRITE
SETBINDFLAGS DBBINDURLFLAG_READWRITE
DBBINDURLFLAG_OVERWRITE
SETBINDFLAGS NULL
Note
NULL Sets the value of the flag to zero
Default value: 0

Verb
SETCREATEFL SETCREATEFLAGS { DBBINDURLFLAG_READ | Sets a system
AGS (OLEDB Module)
DBBINDURLFLAG_WRITE |
DBBINDURLFLAG_READWRITE | all of the calls to
DBBINDURLFLAG_SHARE_DENY_READ | ICreateRow::Create
DBBINDURLFLAG_SHARE_DENY_WRITE | Row for the
DBBINDURLFLAG_SHARE_EXCLUSIVE | DBBINDURLFLA
DBBINDURLFLAG_SHARE_DENY_NONE | G parameter.
DBBINDURLFLAG_RECURSIVE |
DBBINDURLFLAG_OUTPUT |
DBBINDURLFLAG_ASYNC |
DBBINDURLFLAG_COLLECTION |
DBBINDURLFLAG_OPENIFEXISTS |
DBBINDURLFLAG_OVERWRITE |
DBBINDURLFLAG_ISSTRUCTUREDDOCUMENT |
NULL }
SETCREATEFLAGS DBBINDURLFLAG_READWRITE
DBBINDURLFLAG_OPENIFEXISTS
SETCREATEFLAGS NULL
Note
NULL Sets the value of the flag to zero
Default value: 0.

Verb
SETSCOPEFLA SETSCOPEFLAGS {Scope Type } Sets a system
GS { DBMOVE_REPLACE_EXISTING | (OLEDB Module)
DBMOVE_DONT_UPDATE_LINKS |
all of the calls to
DBMOVE_ASYNC | IScopedOperations::
DBMOVE_ALLOW_EMULATION | [Copy | Move |
Delete] for the
DBMOVE_ATOMIC | dw[Copy | Move |
DBDELETE_ASYNC | Delete]Flags
parameter.
DBDELETE_ATOMIC |
DBCOPY_REPLACE_EXISTING |
DBCOPY_ASYNC |
DBCOPY_ALLOW_EMULATION |
DBCOPY_NON_RECURSIVE |
DBCOPY_ATOMIC |
NULL }
Scope Type can be MOVE, COPY, or DELETE
SETSCOPEFLAGS MOVE DBMOVE_ALLOW_EMULATION

SETSCOPEFLAGS DELETE DBDELETE_ATOMIC
SETSCOPEFLAGS COPY DBCOPY_ASYNC
DBCOPY_ATOMIC
SETSCOPEFLAGS MOVE NULL
SETSCOPEFLAGS MOVE DBMOVE_REPLACE_EXISTING
DBCOPY_REPLACE_EXISTING
Note
NULL sets the value of the flag to zero. It is possible to set the
COPY, MOVE and DELETE flags with ANY of the flags
(DBDELETE_ASYNC & DBMOVE_REPLACE_EXISTING).
Default values:
MOVE = DBMOVE_REPLACE_EXISTING
COPY = DBCOPY_REPLACE_EXISTING
DELETE = 0

Verb
SETPROP SETPROP {URL} {Property Name} {Property Type} {Memory Sets the value of a
Size in bytes} specified column in
a row.

REM *** The line below will set the subject (PR_SUBJECT =
mapi:0x0037001f)
SETPROP %PrivateURL%/Inbox/NewMessage
mapi:0x0037001f STRING $$Hello World$$
REM *** The line below will set the body (PR_BODY =
mapi:0x1000001e). It will then fill in the body of the message
REM *** with as many iterations of "HelloWorld" as will fit into
1024 bytes.
SETPROP %PrivateURL%/Inbox/NewMessage
mapi:0x1000001e STRING HelloWord 1024
Notes
Property Type can be [STRING | INT | BINARY]
Memory Size (in bytes) is the amount of memory allocated each
time a property is SET. When specifying the amount of memory
for a STRING data type, it stores the characters as Unicode,
which actually takes up two bytes. The "Memory Size" (in bytes)
has no effect on an "INT" data type.
SETMULTIPROP SETMULTIPROP {URL} {Property Count} {Property Name} Sets multiple
{Property Type} properties for a
specified column in
a row.
REM *** Set multiple properties for a resource in the store
REM *** This particular call below will set the
PR_IMPORTANCE, PR_PRIORITY, and DAV:displayname for
the resource
SETPROP %PrivateURL%/Inbox/NewMessage 3
mapi:0x170003 INT 0 mapi:0x360003 INT 0 DAV:displayname
STRING $$This is a test$$

Verb
SETPENDINGTR SETPENDINGTRANS {ON | OFF} Turns ON or OFF
ANS pending (or
retaining
REM *** Set a variable for the URL transactions).
REM *** Do not start a new transaction until the next
EXOLEDB script command
SETPENDINGTRANS OFF
REM *** This command will not start a transaction because it
doesn't execute any EXOLEDB specific provider code
REM *** The two commands below will behave by starting a
transaction, creating the resource,
REM *** and then commit the transaction
CREATERESOURCE %PrivateURL
%/INBOX/TESTMESSAGE1
REM *** By default at this point a pending or retaining
transaction would be in effect
REM *** But since pending transactions are OFF, a transaction
is not started until the point immediately before the resource is
created
REM *** Let's turn back on Pending Transactions
SETPENDINGTRANS ON
Note
By default, after each EXOLEDB script command is executed,
everything is committed that was inside of the transaction.
Immediately after committing the transaction, a new one is
started. If the value for this command is set to OFF, a transaction
is not started until the next EXOLEDB script command is
executed.
Default value: ON

Verb
SETROWSTOFE SETROWSTOFETCH {number of rows} Sets the number of
TCH rows that will be
fetched on each call
SETVAR BASEURL=FILE://./BACKOFFICESTORAGE/ that is made to
%USERDNSDOMAIN%/MBX/TESTUSER1 IRowset::GetNextR
REM *** Initialize the provider ows.
SETBINDFLAGS DBBINDURLFLAG_READ
GETPROVIDER DATASOURCE EXOLEDB.DATASOURCE
%BASEURL%
REM *** Set the number of rows to fetch when retrieving data
SETROWSTOFETCH 10
REM *** Issue a query. As the data is retrieved 10 rows will be
retrieved at a time
REM *** If there are less than 10 rows to be retrieved, the
remaining number will be retrieved
SELECT $$SELECT "DAV:displayname","DAV:isfolder"
FROM "%BASEURL%/Inbox"$$
E:\MEDUSA\SCRIPTS\SELECT1.TXT
REM *** Stop the script
STOP
Note
Once the number of rows is set via SETROWSTOFETCH, all
subsequent calls to ::GetNextRows will use that value. To reset
the number of rows fetched for each call to 1 (the default value),
another call must be made to SETROWSTOFETCH with the
value of 1 (for example, SETROWSTOFETCH 1).
SETTRANS SETTRANS { ON | OFF } Turns wrapping
commands in a
transaction ON or
Note OFF.
COPYOBJ and MOVEOBJ operations are never wrapped in a
transaction.
SETVAR SETVAR {User Variable Name | System Variable Name} = Sets a user-defined
{Value | Expression} or system variable.

SETVAR MessageNum = 1
SETVAR MessageNum = MessageNum + 1
SETVAR MessageNum = MessageNum * 5
SETVAR MessageNum = MessageNum – 4
SETVAR MessageNum = MessageNum / 2
MSGBOX MessageNum = %MessageNum%
CREATERESOURCE %PrivateURL%/Inbox/Message
%MessageNum%
CREATECOLLECTION %PrivateURL%/Inbox/Folder
%MesssageNum%

Verb
SETVERSIONC SETVERSIONCMD { ALL | LATEST | VID } URL Sets Version CMD
MD VersionCommand for an object to be
manipulated.
ALL Getting everything (Not getting versioned object)
LATEST Getting the latest version
VID Getting the specified VID
SETVERSIONCMD ALL File://./BackOfficeStorage/
%Userdnsdomain%/Public%20Folders/user/msg
SETVERSIONCMD LATEST File://./BackOfficeStorage/
%Userdnsdomain%/Public%20Folders/user/msg
DESTROY
SETVERSIONCMD 09e8475a91e340012
File://./BackOfficeStorage/%Userdnsdomain%/Public
%20Folders/user/msg PIN
TRANSSTART TRANSSTART Manually starts a
transaction.
REM *** Turn off automatic transactions
SETTRANS OFF
REM *** Start a new transaction
TRANSSTART
REM *** Wrap the next two commands in a transaction
REM *** Because automatic transactions are off, you need to
manually commit the transactions
TRANSCOMMIT
REM *** Turn back on automatic transactions
SETTRANS ON
Note
Automatic transactions must be turned off to use this feature.

Verb
TRANSCOMMIT TRANSCOMMIT Manually commits
an active
transaction.
SETTRANS OFF
TRANSSTART
REM *** Because automatic transactions are off, you need to
manually commit the transactions
TRANSCOMMIT
REM *** Turn back on automatic transactions
SETTRANS ON
Note
TRANSABORT TRANSABORT Manually stops an
active transaction.
SETTRANS OFF
TRANSSTART
CREATERESOURCE %PrivateURL%/TESTMESSAGE1
CREATERESOURCE %PrivateURL%/TESTMESSAGE2
REM *** Now, end the last transaction, thereby rolling back the
creation of messages 'TestMessage1' & 'TestMessage2'
TRANSABORT
REM *** Turn on automatic transactions again
SETTRANS ON
Note

This module supports some simple global variables that you can use in your scripts:
SLEEPCOMMIT Causes the ESP OLEDB module to wait the specified number of milliseconds before
committing the current transaction
SETVAR SLEEPCOMMIT=5000 *** This will cause the module to wait 5 seconds before
committing.
SETVAR SLEEPCOMMIT=0 *** This will cause the module to not wait at all.
SETVAR SLEEPCOMMIT=250 *** This will cause the module to wait 1/4 second before
committing.
PROBBUFFSIZE Sets the amount of memory allocated each time a property is set or got via SETPROP or
GETPROP
SETVAR PROBBUFFSIZE=1024 *** Allocates 1024 bytes for SETing/GETing properties
SETVAR PROBBUFFSIZE=10000 *** Allocates 10000 bytes for SETing/GETing properties
COMPUTERNAME System variable that contains the same value as the environment variable
COMPUTERNAME
USERDNSDOMAIN System variable that contains the same value as the environment variable
USERDNSDOMAIN
HRESULT System variable that contains the last HRESULT return value from an OLEDB API call
PROPVALUE Contains the value of the last property retrieved via GETPROP
POP3 Module for ESP

This module simulates multiple clients using the POP3 protocol. The module supports parameters for
Examples are the server that this client is targeting or the port number. Client actions are simulated by running
a script that contains ESP keywords and POP3 verbs.
This module also reports several statistics during runtime. Statistics give counts of the number of modules or
during a test run.
logged.
Run-time Parameters
Table 28 POP3 module run-time parameters

Required
Enable Local Logging Enables/Disables Optional NO YES
creating a per-module NO
log file
Local Logfile Path <Not Yet Implemented – Required if Blank <valid path and log file
additional log files will above is YES name>
be created in the host log
location>
Script Path Script file containing test Required Blank <valid path and script file
steps to be run name>

Required
Encryption Method Encryption method to Required NONE SSL
use throughout the test NONE
duration
Authentication Method Authentication method Required BASIC NTLM
used during BASIC
Authentication state
Server Name Target server Required Blank <server name string or IP
address>
wait for a server
connection. 0 (the
default) means wait
indefinitely.
Start Time Delay (ms) Interval (in milliseconds) Required, >= 0 <1-n>
to wait between the start 0
of each user instance
User Instances Number of client Required 1 <1-n>
sessions to simulate
Statistics
Table 29 POP3 module run-time statistics

Connections Number of connections completed
Disconnected Number of connections terminated
Timeouts Number of timeout expirations
AUTH Commands Number of AUTH commands
DELE Commands Number of DELE Commands
LIST Commands Number of LIST Commands
NOOP Commands Number of NOOP Commands
PASS Commands Number of PASS Commands
QUIT Commands Number of QUIT Commands
RETR Commands Number of RETR Commands
RSET Commands Number of RSET Commands
STAT Commands Number of STAT Commands
TOP Commands Number of TOP Commands
UIDL Commands Number of UIDL Commands
USER Commands Number of USER Commands

is optional.
Table 30 POP3 module reserved word script verbs

CONNECT CONNECT Opens a TCP/IP connection to
the POP3 Server.
QUIT QUIT Closes the TCP/IP connections.
MAILBOX MAILBOX <username> <password> Expands into 3 POP3
commands:
USER <username>
MAILBOX myuser1 gr8p@sswrd
PASS <password>
STAT
The information from STAT
will be cached for use in the
DELE and RETR commands.
RSET RSET ReSETs status on the mailbox.
(All messages marked for
deletion will be unmarked.)
STAT STAT Returns number of items in
mailbox and total size of
mailbox.
Results will be cached for use in
the DELE and RETR
commands.
NOOP NOOP No-Operation command.
LIST LIST Returns a listing of messages
via message number and size.
UIDL UIDL [msgnum] Returns a Unique ID Listing for
a particular message or all of the
messages.
UIDL
UIDL 13
RETR RETR <msgnum> Returns the contents of a
message.
RETR 4
TOP TOP <msgnum> <numOfLines> Returns the top n number of
lines of the body from the
specified message. (Value 0
TOP 1 10 returns no body lines, only the
TOP 255 0 headers.)
DELE DELE <msgnum> Marks the specified message for

deletion. (Messages are actually
deleted at the close of the
DELE 5 connection.)

Both the MAILBOX and STAT commands record the number of messages in a mailbox. The ALL macro can
then be used by either the RETR or DELE command to apply to all of the messages in the mailbox.
RETR Command: (Requires a completed STAT command prior to using)
RETR ALL
DELE Command: (Requires a completed STAT command prior to using)

DELE ALL
Example Scripts
Table 31 POP3 module example scripts
CONNECT This script connects to a user's Inbox, reads all
the messages in the Inbox, and logs out.
MAILBOX "mydom1\myuser1" mypass1
LIST
RETR ALL
QUIT
SLEEP 60000
CONNECT This script logs a series of users and deletes the
first five messages.
MAILBOX SEQULIST(myusers.txt)
LOOP 5
DELE SEQUNUMBER(1,5,1)
ENDLOOP
QUIT

User
The POP3 module for ESP does not support any mechanism for adding data to a mailbox. To populate user
data use either an SMTP submit or an IMAP4 Append-based script.

When customizing the POP3 scripts, you generally focus on number and frequency of client connections.
The number of client connections is controlled through the User-Instances property of the ESP module, while
the frequency is controlled using the terminating SLEEP statement in the scripts. Modify these two values to
accommodate your test scenario.
There are two common methods for iterating through userlist.txt files. The first is a SEQULIST macro, and the
second is a RANDLIST macro. SEQULIST maintains a proper state of mailbox connections throughout the
test (because, unlike RANDLIST, you ensure only one client connection to any one mailbox). RANDLIST can
be useful for simulating more "real world" scenarios and gives you an additional benefit if your mailboxes are
populated with messages of varying sizes and types.
Simple Script Example

You can use the following simple script to simulate client load on an Exchange server. This script will walk
through the userlist.txt file and read all of the messages in that user's Inbox.
CONNECT
MAILBOX SEQULIST(userlist.txt)
RETR ALL
QUIT
SLEEP 60000
It is important to note that, although it is simple, the RETR ALL command can cause significant DISK I/O on
single-spindle systems. It is also important to note when testing a POP3 system that the typical POP3 client is
set up by default to remove all of the messages from the server after retrieving them.
Advanced Script Example

You can use the following advanced script to obtain a better indication of POP3 stress. By issuing the various
commands against a subset of mail, you can more accurately reflect the scenario of a client logging in, reading
a few messages, and then sleeping until the next new mail notification.
CONNECT
MAILBOX RANDLIST(userlist-pop.txt)
list
TOP RANDNUMBER(1,10) RANDNUMBER(1,10)
UIDL RANDNUMBER(1,10)
RETR RANDNUMBER(1,10)
DELE RANDNUMBER(1,10)
NOOP
%90 RSET
STAT
QUIT
The "%90" tag indicates a 90 percent chance that this command will be run.
Identifying Good Scenarios

POP3 servers typically have a large lag time between the client issuing the PASS or STAT command and the
server responding. This is because most POP3 implementations use this time to not only verify the user's login,
but also to perform checks on each message in the mailbox, with the result that a message can be read by a
POP3 client. (Because POP3 is limited in its message retrieval methods, only messages that can be completely
downloaded in a single stream should be made available.) If you implement a POP3 service, consider issues
such as mailbox size and message age, because these can therefore affect the design of your test.
Step 3: Run
Select all the counters under the MSExchangePOP3 that pertain to your script. Some helpful counters are:
• Connections Total
• STAT Total
• QUIT Total (Compare this to STAT Total and Connections Total to ensure that all of the users are
completing the scripts.)
• RETR Rate (Several factors affect this such as server load, but also message size, and the type of item
requested.)
Using Protocol Logging on the Server

The protocol logging registry key can help you diagnose problems. Protocol logging creates a separate log for
each open connection, in contrast to the ESP log, which logs all connections into one file. For more
information, see the following Microsoft Knowledge Base article 299778, " XGEN: How to Activate Protocol
Logging for POP3 and IMAP4" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=299778).
Tip
Logging level 4 is often the most useful, because it logs all interaction between the client and the server
but truncates actual message data.

A good stress run will yield the following results. You can observe all of these results through Perfmon:
• POP3 connections can be created throughout the test. (\Connections Current is typically the same value
throughout the test.)
• Number of POP3 verbs should be directly proportional to the number of total connections. (In other words,
if your script has one quit statement in it, then \Connections Total and \QUIT Total should be equal.)
Additionally, you should always check event logs for important messages.
SMTP Module for ESP

This module simulates multiple clients using the SMTP protocol. The module supports parameters for
Examples are the server this client is targeting or the port number. Client actions are simulated by running a
script that contains ESP keywords and SMTP module verbs.
during a test run.
logged.
Run-time Parameters
Table 32 SMTP module run-time parameters

Required
Path Path to the script file - can Required N/A <valid path>
be UNC path
Server name The name of the server to Required N/A <UNC server name or IP
connect to address>
Port number The port number to connect Required 25 1-n
to
Authentication method Method used to authenticate Required Login Login
client session NTLM
Encryption method Method used to encrypt Required None None
network traffic SSL
Sleep on error (ms) Duration (in milliseconds) to Required 1000 0-n
sleep after an error, for
example, a connection
failure or dropped
connection
Send Notifications If "Yes," notification Required No Yes
messages will be sent to the No
ESP UI (right upper pane).
Currently not recommended
due to active bugs. All
notification messages are
logged (if logging is
enabled).

Required
Start time delay (ms) Delay (in milliseconds) Required 0 0-n
between starting virtual
users
Script Instances Number of virtual users 100 1-n
Statistics
Table 33 SMTP module run-time statistics

Sleep on error (ms) Number of milliseconds to sleep after an error condition
Total Successful Connections Total successful connections
Total Failed Connections Total failed connections
Current Active Users Number of active client sessions
Total HELO Commands Total HELO Commands
Total EHLO Commands Total EHLO Commands
Total MAIL Commands Total MAIL Commands
Total RCPT Commands Total RCPT Commands
Total DATA Commands Total DATA Commands
Total DATA Errors Total DATA Errors
Total Message Bodies Total Message Bodies
Total Message Body Errors Total Message Body Errors

is optional.
Table 34 SMTP module reserved word script verbs

CONNECT CONNECT Connects to the server whose
name is specified in the server
name parameter of the SMTP
module.
DATA DATA <filename> Sends a message. See
DATA comments below.
(<DATASTRING command> |
<DATAFILE command>)
<ENDDATA command>
DATASTRING DATASTRING <string> Sends <string> as part of the
message body. No server
response is expected.
If <string> contains "\n", it will
be substituted with CRLF
before sending.
DATAFILE DATAFILE <filename> Sends the contents of
<filename> as part of the
message body. No server
response is expected.
ENDDATA ENDDATA Specifies that all message
chunks have been sent. Waits
for the server response.
BDAT BDAT <filename> Sends the contents of
<filename> as the message
body. A server response is
expected after message is sent.
See comments below.
AUTHENTICATE AUTHENTICATE <user name> Authenticates using the method
<password> specified in the Authentication
method parameter of the
module.
Currently, the only supported
methods are LOGIN and
NTLM.
<user name> and <password>
are the user name and password
used to authenticate. They must
be given in the script as clear
text.

STARTTLS STARTTLS Starts a TLS session. This
command is processed only if
the Encryption method
parameter of the module is set
to SSL. Otherwise, the
command is ignored.

DATA
Syntax:
"DATA" <filename>
-Or-
"DATA"
*(<DATASTRING command> | <DATAFILE command>)
<ENDDATA command>
where <filename> represents the file that contains the message to be sent. This file must contain the
CRLF.CRLF that is to be sent at the end of the message.
DATSTRING, DATAFILE, and ENDDATA commands are described below.
Description: if <filename> is specified, the command translates into the following SMTP exchange:
C: DATA
S: 354 …
C: <contents of file "filename"> // only if server has given the Ok
S: 250 …
If the response to "DATA" is an error, the module will not attempt to send the message body.
If <filename> is not specified, it is assumed that the message is sent in several chunks and that the ENDDATA
command specifies the end of the message. Any combination of DATASTRING and DATAFILE commands
can be between "DATA" and the ENDDATA command.
The SMTP exchange is:
C: DATA
S: 354 …
C: <send body chunk>
C: <send body chunk>
C: <send last body chunk>
S: 250 …
where a body chunk is described by a DATASTRING or a DATAFILE command.

BDAT
Syntax: "BDAT" <filename>
Description: Sends the contents of <filename> as the message body. A server response is expected after
message is sent.
The SMTP exchange is:
C: BDAT <no_of_bytes_in_filename> LAST
C: <send contents of file "filename">
S: 250 …
Example Scripts
The following SMTP commands are described in RFC 821 (see http://www.ietf.org):
HELO
EHLO
QUIT
DATA
BDAT
MAIL
RCPT
AUTH
STARTTLS
VRFY
RSET
The following script commands are defined by this module:

CONNECT Attempts to establish an SMTP socket connection.
DATASTRING Indicates that the given argument should be interpreted as a literal string and transmitted
(during the DATA command). May be used to transmit message headers.
DATAFILE Indicates the given argument should be interpreted as the name of a file and that the
contents of the file should be transmitted (during the DATA command).
DATAEND Indicates that all message contents have now been transmitted, and a response from the
server is to be expected. An example is 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.
Example 2
Send a message with a random number of recipients. Each recipient has a random name and a random domain.
Each message has a random body file.
CONNECT
EHLO
MAIL FROM: <me>
LOOP RANDNUMBER(100, 1000)
RCPT TO: rcptRANDNUMBER(1, 20)@RANDLIST(domains.txt)
ENDLOOP
DATA RANDLIST(bodies.txt)
QUIT
Where: domains.txt contains the domains to chose from (one domain per line), and bodies.txt contains the
file names to chose from (one line name per line).
Each file listed in bodies.txt ends with CRLF.CRLF. You can also use BDAT instead of DATA. Each recipient
name is in the form: rcptX, where X is a number between 1 and 20.
Example 3
Send a message with headers generated programmatically.
CONNECT
EHLO
MAIL FROM: <me>
RCPT TO: <you>
DATA
DATASTRING From: me\nTo: you\n
DATASTRING Subject: test message #SEQUNUMBER(1, 100000, 10)\n
DATASTRING X-MsgId: SAMESEQUNUMBER(1, 100000, 10)\n\n
DATAFILE <chunk1.txt>
DATAFILE <chunk2.txt>
DATASTRING \n.\n
ENDDATA
QUIT
Neither chunk1.txt nor chunk2.txt contains the sequence CRLF.CRLF. In this example, the ending sequence is
sent explicitly. BDAT does not support this format.
Example 4
Send a message on a secure line and authenticate.
CONNECT
EHLO
STARTTLS
AUTHENTICATE user "password"
MAIL FROM: <me>
RCPT TO: <you>
DATA body.txt
QUIT
The user name and password can be unquoted if they consist of only one word. An empty password is
represented as "".

User
Populate users using example 1 or with an IMAP4 Append-based script.

When customizing the SMTP scripts, focus on the number and frequency of client connections.
The number of clients is controlled through the User Instances property of the ESP module, and the frequency
of client connections is controlled through the terminating SLEEP statement in the scripts. Modify these two
values to accommodate your particular test scenario.
There are two common methods for iterating through userlist.txt files. The first is a SEQULIST macro, and the
second is a RANDLIST macro. SEQULIST maintains the proper state of mailbox connections throughout the
test (because, unlike RANDLIST, you ensure only one client connection to any one mailbox). RANDLIST can
be useful for simulating "real world" scenarios. It provides additional benefit if your mailboxes are populated
with messages of varying sizes and types.
Example 4 above is a good example to simulate "real world" SMTP use.
Step 3: Run
Select all of the counters under the SMTP Server that pertain to your particular script. Some useful counters are
as follows:
• Local Queue Length
• NDRs Generated
• Remote Queue Length
• Messages Delivered/sec
• Messages Sent/sec
• Messages Received/sec

A good stress run will yield the following results. You can observe all of these results through Perfmon:
• SMTP connections can be created throughout the test. (\Connections Current is typically the same value
throughout the test.)
• Number of SMTPs should be directly proportional to the number of total connections. (In other words, if
your script has one quit statement in it, then \Connections Total and \QUIT Total should be equal.)
Note that you should always check event logs for important messages.
NNTP Module for ESP

This module simulates multiple clients using the NNTP protocol. The module supports parameters for
Examples are the server this client is targeting or the port number. Client actions are simulated by running a
script that contains ESP keywords and NNTP module verbs.
This module also reports a number of statistics during runtime. Statistics give counts of the number of modules
or protocol-specific events (for example, errors, successful or failed connection attempts, and so on) occurring
during the course of a test run.
logged.
Run-time Parameters
Table 35 NNTP module run-time parameters

Required
Server The NNTP server against Required Blank <UNC server name
which the tests will run or IP address>
Newsgroups File for Required for the group random Required Blank <valid path>
Group script command.
This file must contain one
group per line
Newsgroups File for Required for the postscript Required Blank <valid path>
Post command.
This file must contain one
group per line.
Authentication method Method to authenticate client Required BASIC NTLM
BASIC
Encryption Method used to encrypt Required NONE SSL
network traffic NONE
Script file The script file name Required Blank <valid path>

Required
Start Delay Time The number of milliseconds Required 0 0-n
between the start of each script
instance
Script instances The number of script instances Required Blank 1-n
to create and run
Statistics
Table 36 NNTP module run-time statistics

Number of successful connections Number of successful connections
Number of failed connections Number of failed connections
Number of current connections Number of active connections
Number of errors Number of unsuccessful commands
Number of xover commands issued Number of xover commands issued
Number of group commands issued Number of group commands issued
Number of post commands issued Number of post commands issued
Number of article commands issued Number of article commands issued
Number of auth commands issued Number of auth commands issued
Number of sleep commands executed Number of sleep commands executed

is optional.
Table 37 NNTP module reserved word script verbs

Connect Connect Connects to the server (required for
all commands except sleep).
Group Group RANDOM Picks a random newsgroup from
the newsgroups file specified in the
module parameters (RANDOM
must be in all uppercase letters.).
Picks the newsgroup given by
Group newsgroup newsgroup.
Note
The watermarks of the group are
stored and used by the special
syntaxes of the xover command.
Xover Xover ALL Does an xover on the entire article
range.
Picks a random range of number
Xover RAND(number)
articles.
Picks a random range of number
Xover FIRST(number) articles.
Does an xover on the last number
Xover LAST(number) articles.
Standard NNTP syntax for xover
where you specify your own range.
Xover range
Post Post article-file #newsgroups Posts an article to a number of one
or more newsgroups.
The article-file should be the body
of the article only (without
CRLF.CRLF). Headers are created
when the article is sent.
Path: news.nntpcomp.com!news
From: NNTP Component
nntpcomp@microsoft.com
Newsgroups: list of newsgroups
Subject: Just a test
Date: current time and date
(blank line)
The newsgroups list includes the
current newsgroup (set by a group
command) and #newsgroups from
the newsgroups for post file
specified in the module parameters.

Article Article FIRST FIRST/LAST/RAND/NEXT must
be in uppercase letters and requires
a successful xover command to be
performed first.
"Article FIRST" returns the first
article in the xover range (from the
last successful xover command in
the current connection).
"Article LAST" returns the last
Article LAST
"Article RAND" returns a random
"Article NEXT" returns the next
Article RAND article after the last article
command.
"Article number" and "Article
message-id" are the standard NNTP
usage of the article command and
Article NEXT do not require an xover command.
Article number
Article message-id
Auth Auth user [password] Authenticates using the specified
user and password. If a password is
not specified, the username is used.
Sleep Sleep msec Sleeps for the specified number of
milliseconds.
Exit Exit Stops the running of the script
instance.
Any other NNTP command Any other NNTP command is sent
as a single line and expects a single
line response.

The following examples describe the general syntax that is used for any WebDAV command supported by this
test module, and for which any valid NNTP command can be used.
Sample Script
The following is a simple sample script. First, it connects to the computer and performs a group command on a
random group. Next, it issues an xover on the entire article range, before cross-posting an article in the current
newsgroup and in two additional random newsgroups. After that, it sleeps for a time between 100 and 600
milliseconds. Finally, it retrieves a random article and sleeps for 10 milliseconds. For example:
Connect
group RANDOM
xover ALL
post c:\esp\scripts\post.txt 2
sleep RANDNUMBER(100,600)
article RAND
sleep 10
To execute this script successfully you need:

• A file containing a list of newsgroups from which the group RANDOM command will choose. You must
enter the path to this file in the module's properties as the newsgroup file for post.
• A file containing a list of newsgroups from which the post command will choose. You must enter the path
to this file in the module's properties as the newsgroup file for post. (You can use the same file for both the
post and group command.)
• A file named post.txt containing the body of the message you wish to post.
Outlook Mobile Access Browse

Module for ESP
Important
SSL is not supported for Mobile Browse connections.
This module enables simulation of Outlook Mobile Access clients accessing the Exchange server using the
HTTP protocol. This module is named Mobile Browse in ESP 2003 and it supports parameters for configuring
different protocol-specific options for simulating typical user actions for Outlook Mobile Access browse.
Client actions are simulated by running a script that contains ESP keywords and Outlook Mobile Access
module command verbs. You can also log client actions and server responses during a test run. The events that
you log are configurable and are described later in this document. Statistics about the simulation give counts of
module- or protocol-specific events and errors during a test run.
Installation
Important
The Mobile Browse module differs from the other protocol modules because it is written in managed
code and therefore requires the Microsoft .NET Frameworks V1.1.
To use this module, you must complete the following:

1. Install .NET frameworks v1.1 or a later version from Windows Update or from the Microsoft Web site.
2. Register associated DLLs with .NET Frameworks.
Verifying That You are Running .NET Framework v1.1 or

a Later Version
You must verify that you are running the v1.1 or a later version of .NET Framework. You can verify the
current version installed by selecting Add/Remove from the Windows Control Panel. If .NET framework is
installed, it will be listed in the list of installed programs (Figure 10).
Figure 10 Verifying which version of .NET Framework you are using
How to register DLLs with the .NET Framework

Regasm.exe is provided to register the mobile browse-supporting DLLs with the framework assemblies. This
step is necessary to enable ESP to recognize the Mobile Browse module.
Regasm.exe is installed with the .NET Frameworks package and is stored in the .NET frameworks home
directory, which is a subdirectory under the default operating system directory for the computer on which ESP
is installed. For example, a commonly used directory is: C:\WINNT\\Microsoft.NET\Framework\v1.1.4322
(Figure 11).
Figure 11 Default directory of the .NET Framework

If you have multiple versions of the Microsoft .NET framework installed, you must select the latest installed
version before running REGASM.EXE. In the example shown in Figure 11, the correct directory to choose is
v1.1.4322.
From a command prompt, go to the appropriate home directory for the .NET Frameworks, and run the
following commands:
• REGASM.EXE C:\ESP\MOBILEBROWSE.DLL
• REGASM.EXE C:\ESP\TestMan_NET2.DLL
Figure 12 provides an example of what occurs when you run these commands from the command prompt.
C:\WINNT\Microsoft.NET\Framework\v1.1.4322>regasm.exe c:\esp\mobilebrowse.dll
Microsoft (R) .NET Framework Assembly Registration Utility 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
Types registered successfully
C:\WINNT\Microsoft.NET\Framework\v1.1.4322>regasm.exe c:\esp\TestMan_NET2.dll
Microsoft (R) .NET Framework Assembly Registration Utility 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
Types registered successfully
Figure 12 Example of registering DLLs with .NET Framework
If an error occurs, check your .NET installation and reinstall or update them according to the requirements
specified above. Ensure that you are in the correct directory and that you have specified the path to the ESP
module DLL files to avoid additional potential problems.
To complete the process, close ESP, if it is open, and then restart the application.
Adding the Mobile Browse Module

You add the Mobile Browse module and connect to the host just as you would with any other module for
ESP 2003. For more information, see "Installing Modules" earlier in this document.
Run-time Parameters
Table 37 Mobile Browse module run-time parameters

Required
Enable Local Logging? Enables/Disables Optional NO YES
creating a per module NO
log file
Local Logfile Path Full path to local log file Required if above is <Valid path>
YES
Send Notifications? Enables reporting of Optional YES YES
errors, warnings, and NO
information in the ESP
UI notifications window
Script Path Full path to script Required <Valid path>
Sleep Duration on Error The duration (in Required 1000 0-n
(ms) milliseconds) for which
each script instance (or
user) will be delayed
(put to sleep) when an
internal error occurs
Encryption Method Encryption method to Required - BASE64
use when doing
authentication
Server Name Target Front-End server Required - <server name
string or IP
address>
wait for a server
connection. 0 (the
default) means wait
indefinitely.
Port Number Server port to connect to Required 80 Only port 80 is
currently
supported.

Required
Start Delay Time (ms) Interval (in Required 200 <0-n>
milliseconds) to wait
between the start of
each user instance
User Instances Number of simultaneous Required 1 <1-n>
client sessions to
simulate
Authentication Method Method used to Required BASIC BASIC
authenticate users to the
server
Statistics
The following are the run-time statistics that are shown in the ESP UI and an explanation of each (Table 38).
Table 38 Mobile Browse module run-time statistics

Active Connections Number of currently connected users
Total Connections Number of active connections established so far
Server Socket Close Number of connections that have been ended
Script Warnings Number of warnings generated
Script Errors Number of errors generated
HTTP 500 level Number of 500s returned to the client
HTTP Bad Number of unknown http responses
SLEEP Commands Number of Sleep commands executed
CLICKLINK Commands Number of Clicklink commands executed
CLICKITEM Commands Number of Clickitem commands executed
LOGIN Commands Number of Login commands executed
AUTH Commands Number of Auth commands executed
ADDHEADER Commands Number of Addheader commands executed
SET Number of Set commands of required variables
Parser config (SET) Number of Set commands for user defined variables
Unknown Commands Number of Unknown commands executed

is optional.
Table 39 Mobile Browse module reserved word script verbs

ADDHEADER ADDHEADER <HdrLbl><:> <HdrVal> Adds the header to the server
request.
ADDHEADER Accept-Language: en-us

DELHEADER DELHEADER <HdrLbl><:> <HdrVal> Removes the header from the next
request.
DELHEADER Accept-Language: en-us

AUTH AUTH <username> <password> Sends the user name and
credentials.
AUTH user10@omatest.com
myPassword
LOGIN No Parameters Finishes the Logon process and
establishes the user session.
CLICKLINK CLICKLINK <Link Name> Sends a request to follow the link
specified by <Link Name>.
CLICKITEM No Parameters Selects a random item from the
current folder.
Variables Specific to This Test Module

The following are reserved word variables and an explanation of each variable:
$OMADIR$ Name of the virtual directory hosting Outlook Web Access
$OMAHOME$ Name of the Outlook Mobile Access home page – always oma.aspx
$LOGREQUEST$ Set to TRUE if you want to log all requests
$LOGRESPONSE$ Set to TRUE if you want to log all responses
$INFOREPORT$ Set to TRUE to see informational messages displayed in the user interface
Scripting With the Mobile Browse

Module
To script with the Mobile Browse module you must set the URL path variables, set the headers to be sent with
each request, specify the user set, and specify the actions to be taken by each user instance.
Constructing the URL

The URL for accessing Outlook Web Access is of the following form:
http://servername/oma/oma.aspx. Setting the server name is done in the run-time parameter
configuration section. The virtual directory and home page are set in the script using the $OMADIR$ and
$OMAHOME$ variables.
Setting the HTTP headers

A set of standard HTTP headers must be sent with each Outlook Web Access request. Typically, these will not
change with subsequent requests. Headers are added with the ADDHEADER keyword, as shown in the
example script. Adding the same header with a different value serves as an update for future requests. Headers
that you do not want in subsequent requests can be removed with the DELHEADER keyword.
User Agents
User agents determine the rendering and format of the responses returned to the client. The ESP Mobile
Browse module currently supports only HTML. The only HTML browsers Outlook Web Access supports are
Pocket IE 3.02 and 4.01. Other HTML browsers, such as IE 6, can be used, but they will generate unsupported
device warning messages when the script is run, and an additional line must be added to the script to handle
this condition. Outlook Web Access is not guaranteed to function properly when using an unsupported device.
Auth and Login

User name can be supplied in either domain\username or username@domain.com format using the auth
command.
Multiple users are typically implemented either by using numerically incremented user names and common
passwords or by using lists of user names and passwords. Standard ESP frameworks commands are used in
either case. In the Mobile Browse module, the AUTH command sends the credentials while the LOGIN
command handles the HTTP 302 that is normally returned upon initial authorization and also establishes the
user session. After the LOGIN command, the Outlook Web Access main menu is displayed.
Script Body
The Mobile Browse module implements a simple UI-based scripting model, which simulates a user following
links on their device. The script must be written in a linear, step-by-step fashion. You cannot jump directly to a
location or action, and only the links visible to the user can be selected at any time. If you attempt to follow
nonexistent links, this will result in errors.
The parameter to the CLICKLINK keyword is the link that the user wants to follow. The script engine uses
text matching to determine which link is to be selected and sent in the next request. The parameter must be in
the form of the complete first word of the target string or in the form of multiple complete words. The string to
be matched is the folder name when viewing a folder list, the command name when following an action link, or
the subject line of an item within a folder.
For example, when currently in the Inbox, the command CLICKLINK test will match messages with subjects
such as test message, testing another test item, and so on. Matching is case sensitive. In the case of multiple
matches, a link to follow will be selected randomly. If there are no matches, a script error will occur, and that
user instance will stop and restart with a new user, as specified by the AUTH command.
You can use the CLICKITEM keyword in place of the CLICKLINK keyword when inside a folder. It requires
no parameters and returns a random selection from the available items regardless of the subject line. If the
folder is empty, a warning, instead of an error, will be reported to the ESP UI. The user instance will still stop
and restart.
Good scripting form uses CLICKLINK for folders and actions and CLICKITEM for items. This requires both
the script and the user data to be created in such a way that all subsequent actions will be valid on any
randomly selected folder item. If a particular folder item is required, it must have a unique subject line.
Fields that require user input, such as creating items or entering search strings, can be scripted by using the
CLICKLINK keyword, followed by the link string OK, followed by the string representing the user input to the
text box.
Example Script
The following script provides an example of creating a Mobile Browse session by randomly selecting a user in
the test domain with a password of pwd. The script logs in the user and performs some actions on the mailbox.
SET $OMADIR$ OMA
SET $OMAHOME$ oma.aspx
REM SET $LOGREQUEST$ TRUE
REM SET $LOGRESPONSE$ TRUE
REM SET $INFOREPORT$ TRUE
ADDHEADER Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

ADDHEADER Accept-Language: en-us
ADDHEADER Content-Type: application/x-www-form-urlencoded
ADDHEADER Accept-Encoding: gzip, deflate
ADDHEADER User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240x320)
ADDHEADER Connection: Keep-Alive
AUTH testuserRANDNUMBER(1,1000,1)@test_domain.com pwd

LOGIN
REM~~~~~~~Inbox Actions~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CLICKLINK Inbox
CLICKLINK Test
CLICKLINK Delete
CLICKLINK Close
CLICKITEM
CLICKLINK Reply
CLICKLINK Message:
CLICKLINK Ok This is my reply to your message
CLICKLINK Send
CLICKLINK Close
CLICKLINK Folders
CLICKLINK MySubFolder
CLICKLINK Test
CLICKLINK Home
SLEEP 3000
REM~~~~~~~End Inbox Actions~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REM~~~~~~~Calendar~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
%50 SKIP 8
CLICKLINK Calendar
CLICKLINK Go To Day
CLICKLINK <
CLICKLINK 22
CLICKITEM
CLICKLINK Details
CLICKLINK Home
SLEEP 3000
REM~~~~~~~End Calendar~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SKIP 8
Debugging Script Errors

When an error is reported in the user interface, it is important to determine whether it is an Outlook Web
Access error or a scripting error. The Mobile Browse module provides some useful logging levels to help make
this determination.
Standard ESP logging is enabled by selecting properties of the top level of the module tree in the ESP user
interface. It will record every script line and the matching response. If there is an error, the HTML body of the
response will also be included.
Matching of the requested link to the available links shown in that HTML body will show if the requested link
is appropriate for the user state, if the link is misspelled, or if there are no matches for the subject line in the
current folder.
If there is an Outlook Web Access system error, you will see that an error page was returned to the client. A
common practice is to test a script by first running it with only one user instance. If the script completes several
loops without generating any errors, you can be confident of its syntax. If there is an error for every LOGIN or
AUTH command, then the script is not running to completion, and it is probably hitting the same error every
time.
If there are larger problems with access to Outlook Web Access, for example, problems involving network
connectivity or authorization, you can set the variables $LOGRESPONSE$ and $LOGREQUEST$ equal to
true inside a script to record the full HTTP request and response. This verbose level of logging is not
recommended to be run continuously during large-scale test runs because of the large log files it generates.
You can get another level of logging by setting the script variable $INFOREPORT$ to true. This will send
informational messages to the ESP notification UI. This is not typically used because of the volume of
notifications that it can generate.
Simulating an Exchange 2003 User

The basic requirements for using the Outlook Mobile Access Browse module are that the Exchange server that
you are testing has a population of users with data in the Inbox, Calendar, Contacts, and Tasks. Data can be
generated manually or by using any number of scripting tools.
Outlook Mobile Access browse functionality is enabled by default on a per-user basis but globally it is disabled
by default.
To enable Outlook Mobile Access browse functionality for all users
1. Start Exchange System Manager.
2. Expand Global Settings.
3. Right-click Mobile Services, and select Properties.
4. Select the boxes for Enable Outlook Mobile Access and Allow unsupported devices, and then click
OK.
After you create users, you can use Outlook or Outlook Web Access to access the mailbox and populate
content in the mailbox manually. You can also use personal store files with sample data appropriate to your
testing. You must instantiate the mailbox using either Outlook or Outlook Web Access before running your
scripts.
There are several scripts in the public domain that enable automated user creation and content setup. However,
those scripts are not provided in the context of this tool. Testing with the Mobile Browse module does not
require any specific user data, but the scripts should be written with knowledge of the user data. For example,
trying to open a specifically titled message that does not exist or attempting to open a calendar item for a day
with no meetings will generate a script error.
Mobile Browse does not have any special requirements for using passwords or certain user accounts. To
troubleshoot login or other access problems in scripts, you can use any Internet Explorer browser to log in
directly to the Exchange server over Outlook Mobile Access. It is recommended that this be done before
running scripts.
The URL for accessing Outlook Web Access is of the following form:
http://servername/oma/oma.aspx.
After you verify login, you are ready to create and run scripts against your test users.
Step 2: Create the Script

You can take the basic form of the script from the example provided. To modify the script, you must update
the URL of your server with the correct server name. First, set the server name in the run-time parameter
configuration section. Set the virtual directory and home page in the script using the $OMADIR$ and
$OMAHOME$ variables. Next, change the authorization section to the applicable user accounts and
passwords. The user determines the script actions to implement according to what is appropriate for the test
that you want to run. You can generate a script by manually accessing Outlook Mobile Access through Internet
Explorer against a test mailbox and transcribing the desired sequence of user actions into the script body.
Remember to follow the syntax described earlier in this document.
Step 3: Run
Run the written script. If the test is running correctly, you will see the counters incrementing upward in the
ESP statistics pane. If you see the number of errors incrementing, this indicates a script problem. Additionally
if HTTP 500s are being returned, you must verify that the Exchange Vroot is running and that you can access
Outlook Mobile Access through Internet Explorer. For more information, see "Debugging Script Errors" earlier
in this document.

To analyze the results of your scripted tests and the effect of Mobile Browse on the server, you can use
Perfmon with the standard counters for memory, processor, and network use.
More importantly, you can also use the MSExchangeOMA object to monitor all aspects of the Mobile Browse
performance, including HTTP return codes. You can monitor these in Perfmon and compare them to the
statistics included in ESP to validate a successful test run.
Using Event Viewer to check the error logs on the Exchange 2003 back-end and front-end servers is another
way to determine if your test was successful.
Mobile Synch Module

This module simulates multiple Outlook Mobile Access ActiveSync® clients using the AirSync protocol. This
module is named "Mobile Synch" in ESP 2003. The module supports parameters for configuring different
protocol-specific options, options for how the test executes, and security options. Examples are the server this
client is targeting or the encryption method. Client actions are simulated by executing a script that contains
ESP keywords and SYNC-related commands. This module also supports simple script variables.
protocol-specific events (for example, errors, or successful or failed connection attempts) that occur during a
test run.
logged.
Adding the Mobile Synch Module

You add the Mobile Synch module and connect to the host as you would with any other module for ESP 2003
(Table 34). For more information, see "Installing Modules" earlier in this document.
Run-time Parameters
The following are the run-time parameters shown in the ESP user interface and an explanation of each
(Table 40).
Table 40 Mobile Synch module run-time parameters

Required
Enable Local Logging Logs results to a file Required NO NO
YES
Local Log Path Logs file path Required if <Blank> <valid path>
logging enabled
Script Path Scripts file to run a test Required <Blank> <valid path>
Sleep Duration on The duration (in Required 1000 1-n
Error (ms) milliseconds) for which
each script instance or
user will be delayed (put
to sleep) when an
internal error occurs
Encryption Method Encryption method for Required SSL SSL
the data NONE
Server Name Server name Required <Blank> <UNC server name
or IP address>
Timeout (sec) Connection timeout in Required 60 1-n
seconds
Start Delay Time (ms) The duration (in Required 200 1-n
milliseconds) for which
each script instance will
be delayed from starting
User Instances Number of users Required 1 1-n
Statistics
The following are the run-time statistics that are reported to the ESP user interface and an explanation of each
(Table 41).
Table 41 Mobile Synch module run-time statistics

Active Connections Current active user connections
Connections Closed by Server Total number of connections closed by server
Failed Connections Total number of failed connections
Authenticated Connections Total number of successful authenticated connections
Failed Authenticated Connections Total number of failed authenticated connections
Errors Total number of errors
Timeouts Total number of connection timeouts
100 Level Status Total number of 100 status-level responses received from the server
Unknown Level Status Total number of unknown status level responses received by the server
AUTHENTICATE Command Total number of AUTHENTICATE requests
GETHIERARCHY Command Total number of GETHIERARCHY and FOLDERSYNC requests
GETESTIMATE Command Total number of GETESTIMATE requests
SYNC Command Total number of SYNC requests
SYNCADD Command Total number of SYNCADD requests
SYNCDEL Command Total number of SYNCDEL requests
SYNCCHANGE Command Total number of SYNCCHANGE requests
SYNCFETCH Command Total number of SYNCFETCH requests
SENDMAIL Command Total number of SENDMAIL requests
SLEEP Command Total number of SLEEP requests
SETDEVICETYPE Command Total number of SETDEVICETYPE requests
SETDEVICEID Command Total number of SETDEVICEID and SETDEVICEID2 requests
SETEMAILTRUNCATION Total number of SETEMAILTRUNCATION requests
Command
SETEMAILFILTER Command Total number of SETEMAILFILTER requests
SETCALENDARFILTER Total number of SETCALENDARFILTER requests
Command
FOLDERCREATE Command Total number of FOLDERCREATE requests
FOLDERDELETE Command Total number of FOLDERDELETE requests
NOTIFY Command Total number of NOTIFYPROVISION and NOTIFYBINDING
requests

is optional.
Table 42 Mobile Synch module reserved word scrip verbs

AUTHENTICATE AUTHENTICATE <domain>\<user Sets the user credential for the
name> <password> current instance. All further
requests to the Nexus Server
will have this user credential
AUTHENTICATE testdomain\nexus- until another
user-1 pwd AUTHENTICATE command
is issued with a different user
credential. This must be the
first Mobile Synch specific
command in the script.
GETHIERARCHY GETHIERARCHY Syncs the folder hierarchy of
the current user. It is
equivalent to FOLDERSYNC.
FOLDERSYNC FOLDERSYNC Equivalent to
GETHIERARCHY.
FOLDERCREATE FOLDERCREATE <parent folder name> Creates a new mail folder. All
<new folder name> the folders in the folder
hierarchy must have unique
names.
FOLDERCREATE inbox test
FOLDERDELETE FOLDERDELETE <name of folder to be Deletes an existing folder.
deleted>
FOLDERDELETE test
NOTIFYPROVISION NOTIFYPROVISION "<device smtp Provisions the device for
address>" notification.
NOTIFYPROVISION
"4251234567@carrier.com"
NOTIFYBINDING NOTIFYBINDING <folder binding life Sets up folder bindings for
time in minutes> [ default | none] notification.
The lifetime value must be between 0 and Can only be called after
9999. provisioning the device. That
is, after calling
If the optional parameter is not specified,
NOTIFYPROVISION.
it sets the binding for all possible folders.
When the optional parameter is set to:
Default – it sets the binding for only
inbox/contacts/calendar folders.
None - all folder binding will be deleted.
NOTIFYBINDING 100
NOTIFYBINDING 200 default

GETESTIMATE GETESTIMATE <folder name> [folder Obtains a count of items out of
name]* sync in a specific folder on the
Exchange Server. The folder
* Means you can name several folder
has to be SYNCed at least
names one after the other as parameters to
once before GETESTIMATE
this verb, up to 9 folders total.
can be called.
GETESTIMATE Inbox contacts drafts

SETDEVICEID SETDEVICEID <device ID> Sets the DeviceID of the first
device for the current user.
The default DeviceID is
SETDEVICEID MyIPAQ
NexusCom.
SETDEVICEID2 SETDEVICEID2 <device ID> Sets the DeviceID of the
second device for the current
user.
SETDEVICEID2 MyAnotherIPAQ
The default DeviceID is
NexusCom2.
SETDEVICETYPE SETDEVICETYPE <PocketPC| Sets the DeviceType for the
SmartPhone> Device.
The verb parameter can only have one of The default DeviceType is
the two values: PocketPC or SmartPhone SmartPhone.
SETDEVICETYPE PocketPC
SETEMAILFILTER SETEMAILFILTER <filter value> Sets the e-mail filter for the e-
mail SYNC operation.
The filter value can be one of the
following: The default filter is 1WEEK.
1DAY
3DAYS
1WEEK
2WEEKS
1MONTH
3MONTHS
SETEMAILFILTER 1MONTH

SETEMAILTRUNCATION SETEMAILTRUNCATION <truncation Sets the e-mail body truncation
value> for the mail SYNC operation.
The default truncation is
HALFK. The unit is bytes.
The truncation value can be one of the
following:
NONE
1K
2K
5K
10K
20K
50K
100K
HALFK
SETEMAILTRUNCATION 5K
SETCALENDARFILTER SETCALENDARFILTER <filter value> Sets the calendar filter for the
calendar SYNC operation.
The filter value can be one of the
following: The default filter is 2WEEKS.
1DAY
3DAYS
1WEEK
2WEEKS
1MONTH
3MONTHS
SETCALENDARFILTER 1MONTH
SETSYNCWINDOWSIZE SETSYNCWINDOWSIZE <window Sets the window size for the
size> SYNC operations.
The Window Size must be an integer
value between 10 and 2000.
SETSYNCWINDOWSIZE 100
SYNC SYNC <folder name> Performs the Nexus Sync
command on the specified
folder.
SYNC Inbox

SYNCADD SYNCADD <Contacts|Calendar> Performs a client-side add to
["<filename>"] the Calendar or Contacts
folder. If no file is provided,
The first parameter can be either Contacts
the module will create a
or Calendar. The second optional
certain item for you.
parameter is a file containing an iCal or a
vCard, depending on the first parameter. The addition will be effective
only after a SYNC is called on
the folder.
SYNCADD Contacts
SYNCADD Calendar
"c:\test\newappt.ics"
SYNCDELETE SYNCDELETE <folder name>.<script Performs an item deletion in a
function> specified folder.
The first parameter indicates the folder in The deletion will be effective
which you want to delete an item. The only after a SYNC is called on
second parameter is a script function that the folder.
indicates the item to be deleted.
SYNCDEL Inbox.RND
SYNCCHANGE SYNCCHANGE <folder name>.<script Performs a change to an item
function> ["<filename>"] in a specified folder. If no file
is provided, the module will
The first parameter indicates the folder in
change it to a certain item.
which you want to edit an item.
The change will be effective
The second parameter is a script function
only after a SYNC is called on
that indicates the item to be changed.
the folder.
The optional parameter is a file containing
an iCal or a vCard, depending on the first
parameter to which the current item will
be changed.
SYNCCHANGE Calendar.FIRST
SYNCCHANGE Contacts.RND
"updatedcontact.vcf"
SYNCFETCH SYNCFETCH <folder name>.<script Performs a fetch on an item in
function> a specified folder.
The first parameter indicates the folder in The fetch will be effective
which you want to fetch an item. only after a SYNC is called on
the folder.
The second parameter is a script function
that indicates the item to be fetched.
SYNCFETCH Calendar .FIRST
SENDMAIL SENDMAIL "<message file path>" Sends an e-mail message
represented by the message
The message file must have an RFC822
file.
message
SENDMAIL "c:\temp\msg-1k.txt"

ADDMAILRECIPIENT ADDMAILRECIPIENT "<recipient>" Adds a new recipient for next
SENDMAIL command.
Multiple recipients can be
added by calling this command
multiple times.
ADDMAILRECIPIENT If ADDMAILRECIPIENT
"test1@microsoft.com" command is not called before a
SENDMAIL command, the
mail is sent to the recipient in
the message file.
The next SENDMAIL
command will clear the
previously added recipients.
Script Functions
The following reserved word variables act as script functions that traversal and item access mechanism. These
script functions are named and described below (Table 43).
Table 43 Mobile Synch module reserved word variables

Script Function Syntax and Example Description
.RND OBJECT.RND Used to access a random
folder in the user's folder
hierarchy or a random folder
SYNCDEL Inbox.RND deletes a random item item in a specific folder.
from the Inbox folder.
.FIRST OBJ.FIRST Used to access the first
SYNCDEL Inbox.FIRST deletes the first item
hierarchy or the first folder
item in a specific folder.
.LAST OBJ.LAST Used to access the last folder
in the user's folder hierarchy
or the last folder item in a
SYNCDEL Inbox.LAST deletes the last item specific folder.
.NEXT OBJ.NEXT Used to traverse to the next
hierarchy or to the next item
FOLDER.NEXT in a specific folder.
.PREVIOUS OBJ.PREVIOUS Used to traverse to the
previous folder in the user's
folder hierarchy or to the
FOLDER.PREVIOUS previous item in a specific
folder.
Script Function Syntax and Example Description

.# OBJ.#<value> The value after the # denotes
a specific value folder in the
user's folder hierarchy or a
SYNCDEL Inbox.#2 deletes the second item specific value folder item in
from the Inbox folder. a specific folder.
("folder name") OBJ("<folder name>") Used to access a specific
folder (indicated by the
folder name enclosed in
SYNCDEL FOLDER("My contacts").#3 deletes double quotes) in the user's
the third item from the folder named "My folder hierarchy.
contacts."
Script Object
The module employs a script object reserved by the name FOLDER to allow the script user to perform
manipulation on individual folder(s) and folder items.
The FOLDER object is used as a parameter for the script verbs that need folder information, for example,
SYNC FOLDER("Inbox").
When the Script functions are used on the FOLDER object, together they allow the script user to do traversal,
access, and manipulation of folder(s) and folder item(s), for example, FOLDER.FIRST, FOLDER.NEXT,
SYNC (FOLDER #8).
Example Script
Table 44 Mobile Synch module example script
AUTHENTICATE RANDLIST(C:\users.txt ) Gets a random user credential from
the user's text file.
GETHIERARCHY Gets the user's folder hierarchy.
NOTIFYPROVISION SEQUNUMBER(1,30000)@remote.com" Provisions device for notifications and
binds default folders
NOTIFYBINDING 60 default
(inbox/contacts/calendar) for one
hour.
SLEEP RANDNUMBER(60000,180000) Syncs each folder for the first time to
set up partnership. No item is synced
SYNC calendar
down yet.
SYNC contacts
SYNC inbox
GETESTIMATE calendar Gets number of items that will be
synced in each folder.
GETESTIMATE contacts
GETESTIMATE inbox

SYNC calendar Syncs each folder to get items.
SYNC contacts
SYNC inbox
ADDMAILRECIPIENT RANDLIST(C:\recipients.txt ) Sends a random RFC822 message to
two randomly selected recipients.
ADDMAILRECIPIENT RANDLIST(C:\recipients.txt )
SENDMAIL RANDLIST(C:\common-messages.txt)
SYNCCHANGE FOLDER("contacts").rnd Changes an existing contact, adds a
new contact, and syncs the change/add
SYNCADD contacts "c:\newcontacts.vcf"
to the server.
SYNC contacts
SYNCDEL FOLDER("calendar").last Deletes an existing appointment, adds
a new appointment, and syncs the
SYNCADD calendar
delete/add to the server.
SYNC calendar

User
To simulate Exchange Server 2003 users, you must create user accounts and populate these user accounts. You
can run the suites against empty mailboxes, but if you do so, errors will be logged when items are expected to
exist in the mailboxes. For example, a GETHIERARCHY and SYNC will always work on empty as well as
populated accounts, but a SYNCDELETE will log an error if the mailboxes are empty.

Although the files required to run the Mobile Synch module are installed to your hard disk when you run
ESP 2003 Setup, you must manually register the MasClnt2.dll before you can customize and run the Mobile
Synch Module.
Important
The Mobile Synch test will not run until you manually register MasClnt2.dll.
After you register MasClnt2.dll, open ESP, and configure the Server property to be the Exchange front-end
server that the ESP module is running against. Set the Script File property on the Mobile Synch Module
properties to be the file that you want to run. To validate that it is possible to run the scripts, set the Script
Instances property to 1. In the Host Properties, set the Log Results property to YES, and set the Local Log
Path to the log file path.
Step 3: Run
To successfully run the suites in your environment, you must create the following files (Table 45).
Table 45 Mobile Synch module files that must be created

File Content
users.txt Aliases, domain, and password for all of the users to be used.
recipients.txt Alias for mail to be sent to.
line.
common-messages.txt Paths to file locations. These files represent messages to be loaded and
sent using the SENDMAIL script verb.
Format is in the form of the file path – drive:\path.
Each of these files must contain an RFC822 message.
For the purposes of this verification, start with a single user in the users.txt file that will be logged in to.
Likewise, listing the same user in the recipients.txt file will ensure that testing has been isolated to a single user
who should be sending and receiving all messages. To start, the goal is to reduce complexity so that you can
verify that these suites can be run.
Other variables and script entries may need to be updated to run required scenarios, but the defaults should run
successfully. For a list of other potential changes, see the section titled "ESP Modules."

With the script stopped, open the log file (for example, c:\log.txt). All actions and responses and any ECHOed
comments and errors have been logged here. An initial 401 error is expected as part of the user login. Errors
may be logged if a mailbox is empty, because the suites expect items to exist in the Inbox. Circumstances may
arise in which the tool reports no failures, but actions have not actually been successful. After what looks like a
successful run, log in to a mailbox that you are sure has been targeted by the automation, and verify that mail
was received in the Inbox, that mail was sent from the Sent Items, and that Contacts and Appointments exist (if
the suite created them).
Now you can start adding loads to your server with multiple script instances and multiple clients pointed at the
same server.
It is important to load the appropriate counters in Perfmon to monitor resource use. Server ActiveSync also
provides several sync-related counters. The resource utilization counter and the sync-related operations profile
help to analyze resource management and performance trends. For example, if the CPU Usage spikes to 100%,
the throughput will be lowered. This can cause denial of service to other incoming requests.
Additional Resources
For the latest documentation about Microsoft Exchange Server 2003, go to the Microsoft Exchange Technical
Library at http://www.microsoft.com/exchange/library. The Microsoft Knowledge Base articles
provide additional information that will help you use ESP 2003.
Microsoft Knowledge Base Articles

The following Microsoft Knowledge Base article is available at http://go.microsoft.com/fwlink/?
LinkId=3052&kbid=299778.
• 299778: XGEN: How to Activate Protocol Logging for POP3 and IMAP4
Other Microsoft Exchange 2003

Tools
For the latest information about Exchange Server 2003 tools, go to the Exchange Server 2003 Tools and
Updates page at http://go.microsoft.com/fwlink/?linkid=25097.
Does this tools document help you? Give us your feedback. On a scale of 1 (poor) to 5 (excellent), how do
you rate this book?
Mail feedback to exchdocs@microsoft.com.

Exchange Stress and Performance Tool 2003

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exchange Stress and Performance Tool 2003

Uploaded by

Copyright:

Available Formats

Exchange Server Stress and

Performance 2003 Tool

Exchange UE Writer: Jon Hoerlein

Exchange Server Stress and Performance 2003 Tool.................................1

IMAP4 Module for ESP..............................................................................36

Simulating an Exchange 2003 User.....................................................................98

Table 1 ESP 2003 system requirements

When to Use ESP 2003

Installing ESP 2003

Configuring ESP 2003 on a Client

Figure 1 An example of an ESP 2003 workspace with four hosts

Creating Workspaces and Hosts

Figure 2 Adding a host to a workspace

Installing Test Modules

Configuring the Connection to the Host

Figure 4 Target Host tab of the properties dialog box

Customizing Test Configuration

To change test configuration properties

Configuring Test Modules

Figure 6 Host computer lest80 with one LDAP module

Configuring Module Properties and

Configuring Module Parameters

Figure 7 Settings tab of the LDAP module within a workspace

Configuring Logging and

Figure 8 Statistics tab of the LDAP module within a workspace

Saving the Workspace

Restoring the Workspace

Running Test Modules

Command Line Parameters

Table 2 Command line parameters

Parameter Flags Description Example

Setting up the Test

Table 3 Common scripts for all modules

WebDAV Module for ESP

Table 4 Outlook Web Access run-time parameters

Parameter Description Optional/ Default Legal Values

Parameter Description Optional/ Default Legal Values

Figure 9 Settings tab of a DAV module

Table 5 Outlook Web Access run-time statistics

Script Verbs Specific to This Test Module

Table 6 Outlook Web Access reserved-word script verbs

Reserved Script Syntax and Example Description

SET $server$ server_1

SET $name4$ $xml$.NEXT The second four SET commands

RESPHEADER RESPHEADER(<HdrLbl>) Used to get header information

Reserved Script Syntax and Example Description

Reserved Script Syntax and Example Description

SET $fifthprop$ $xml$.5 The example to the left is doing a

Reserved Script Syntax and Example Description

Reserved Script Syntax and Example Description

Reserved Variables Specific to This Test

Table 7 Outlook Web Access reserved-word variables

Commands Specific to This Test Module

How to Script a WebDAV Verb

The HTTP Version

The Content-Length Header

How to Script WebDAV Verbs

Table 8 WebDAV verbs and how to script them

ADDHEADER host: server1

ADDHEADER host: server1

ADDHEADER host: server1

HTTP/DAV Syntax/Example Description

LOCK /fs/text.txt c:\<filename>.txt