Tài liệu Module 13: Using the Microsoft Exchange Server Event Service pptx

Contents
Overview 1
Introduction to the Exchange Server
Event Service 2
Introduction to Event Scripts 7
Writing an Event Script 14
Debugging Event Scripts 24
Using Event Scripts in Solutions 30
Exchange Server Routing 38
Lab A: Creating the Escalation Event
Script 43
Review 53

Module 13: Using the
Microsoft Exchange
Server Event Service


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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.

 1999 Microsoft Corporation. All rights reserved.

Microsoft, Active Desktop, Active Directory, ActiveX, BackOffice, Developer Studio, FrontPage,
JScript, MSDN, MSN, NetMeeting, Outlook, PivotChart, PivotTable, PowerPoint, Visual Basic,
Visual C++, Visual FoxPro, Visual InterDev, Visual J++, Visual SourceSafe, Visual Studio,
Windows, Windows Media, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.


Project Advisor: Janet Wilson
Project Lead and Instructional Designer: Anne Bockman (Excell Data Corporation)
Instructional Designers: Josh Barnhill (Volt Technical) and Jo Berry (Exchange)
Lead Program Manager: Greg Bott
Program Managers: Colleena Carr and Chris Boar (Intl Vendor)
Graphic Artist: Andrea Heuston (Artitudes Layout and Design)
Editing Manager: Lynette Skinner
Editor: Jennifer Kerns (S&T Onsite)

Copy Editor: Shari G. Smith (R & S Consulting)
Online Program Manager: Arlo Emerson (Aditi)
Production Support: Irene Barnett (Barnett Communications)
Manufacturing Manager: Bo Galford
Manufacturing Support: Mimi Dukes (S&T Onsite)
Development Services: Kimber Dodge
Lead Product Manager: Mary Larson
Group Product Manager: Robert Stewart


Module 13: Using the Microsoft Exchange Server Event Service iii


Instructor Notes Module 13: Using the Microsoft
Exchange Server Event Service
This module provides students with the ability to use the Microsoft® Exchange
Server Event Service within collaborative applications. The module also
provides an introduction to Exchange Server Routing. At the end of this
module, you will be able to create, edit, and debug an event script on an
Exchange Server public folder. You will also be able to encapsulate event-script
functionality within Component Object Model (COM) add-ins. In addition, you
will be able to describe how to use the tools of Exchange Server Routing to
create workflow and process-design applications.
Materials and Preparation
This section provides you with the materials and preparation needed to teach
this module.
Materials
To teach this module, you need the following materials:
 Microsoft PowerPoint® file 1593a_13.ppt
 Module 13, “Using the Microsoft Exchange Server Event Service”

Preparation
To prepare for this module, you should:
 Read all the materials for this module.
 Read the instructor notes and margin notes for the module.
 Complete the lab.

Presentation:
60 Minutes

Lab:
45 Minutes
iv Module 13: Using the Microsoft Exchange Server Event Service


Module Strategy
Use the following strategy to present this module:
 Introduction to the Exchange Server Event Service
Describe the architecture and set-up process of the Microsoft Exchange
Server Event Service.
 Introduction to Event Scripts
Explain the benefit, limitations, important registry settings, and common
uses of event scripts.
 Writing an Event Script
Explain how to bind an agent to a server and select the folder event that you
want to be monitored. Explain how to create and edit a script. Describe how
to use the intrinsic objects that are passed when a script runs. Describe the
security considerations for event scripts.
 Debugging Event Scripts
Explain how to use the Microsoft Script Debugger for error trapping.

Describe how to use the Microsoft Windows NT Event Log for error
logging.
 Using Event Scripts in Solutions
Explain how to simplify debugging by encapsulating the functionality of an
event script within a COM add-in. Explain how the MoveApp escalates
messages by using an event script.
 Exchange Server Routing
Describe server-side routing architecture. Explain that Exchange Server
Routing Objects can be used to build workflow and process-design
applications. Explain that the Exchange Server Routing Wizard is a sample
application that demonstrates the use of Exchange Server Routing
components.

Module 13: Using the Microsoft Exchange Server Event Service 1


Overview
 Introduction to the Exchange Server Event Service
 Introduction to Event Scripts
 Writing an Event Script
 Debugging Event Scripts
 Using Event Scripts in Solutions
 Exchange Server Routing


At the end of this module, you will be able to:
 Explain the purpose of the Microsoft® Exchange Server Event Service, a
feature of Microsoft Exchange Server.
 Describe the benefits, limitations, security considerations, registry settings,
and common uses of event scripts.

 Create and edit an event script on an Exchange Server public folder.
 Resolve programming errors in event scripts by using the Script Debugger.
 Explain how to encapsulate event-script functionality within Component
Object Model (COM) add-ins and describe how the MoveApp escalates
messages by using an event script.
 Describe the architecture of Exchange Server Routing and describe how to
use its tools to design workflow and process-design applications.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
how to incorporate the
Exchange Server Event
Service and the Event
Scripting Agent in a
collaborative solution.
2 Module 13: Using the Microsoft Exchange Server Event Service




 Introduction to the Exchange Server Event Service
 Architecture of the Exchange Server Event Service
 Setting Up the Exchange Server Event Service


The Microsoft Exchange Server Event Service (Events.exe) is a Microsoft

Windows NT
® service that runs on a Microsoft Exchange Server computer.
This service is installed as part of the Exchange Server version 5.5 setup. By
using Microsoft Outlook
® 2000, you can configure this service to monitor
events that occur in folders you specify. The Exchange Server Event Service
extends the possibilities of what you can develop on the Exchange Server
platform—from automated administrative tasks to workflow applications.
Slide Objective
To outline this topic.
Lead-in
The Exchange Event Server
Service enables you to
develop a range of
collaborative applications,
from automated
administration to workflow.
Module 13: Using the Microsoft Exchange Server Event Service 3


Architecture of the Exchange Server Event Service
Exchange Server
Information Store
Exchange Server
Information Store
Application Folder
Docs
Exchange Server
Event Service
Exchange Server

Event Service
Change List
Event Handler
(agent)
Notify
ICS


The Exchange Server Event Service receives notifications from Exchange
Server folders about the state of folder items. The Exchange Server Event
Service passes events, such as the creation of a new message in a folder, to the
correct event handler—an agent—with some information about the source of
the event, the message, and the folder that caused the event.
Detecting Changes to Monitored Folders
The Exchange Server Event Service uses Incremental Change Synchronization
(ICS) technology to determine when an item is added, changed, or deleted in a
particular folder. ICS allows the client—in this case, the Exchange Server Event
Service—to query the information store on the server and request information
about all changes that have occurred in a particular folder since the last
synchronization. By using ICS, the Exchange Server Event Service never
misses an event, even if Exchange Server Event Service is taken offline. When
the Exchange Server Event Service goes back online, it queries for any changes
to the folders it is monitoring and fires the correct events to the corresponding
event handlers for that folder.
Firing Events Asynchronously When Changes Are
Detected
The Exchange Server Event Service fires events asynchronously when an item
is added, changed, or deleted in a folder, or according to time intervals. The
events for adding, changing, and deleting items are self-explanatory. The fourth
event—the timed event—requires more explanation. You specify intervals to

indicate when to fire the timer event. These intervals can be hourly, daily, or
weekly, depending on the needs of your application—for example, every 15
minutes, every three hours, or every week on Monday at 3:00 P.M.
Slide Objective
To show the architecture of
the Exchange Server Event
Service.
Lead-in
The Exchange Server Event
Service receives
notifications of events from
Exchange Server folders
and passes events to the
correct agent.
4 Module 13: Using the Microsoft Exchange Server Event Service


Setting Up the Exchange Server Event Service
1 Change the Account Under Which the Exchange Server
Event Service Runs
2 Give Users Permission to Create Agents
3 Install the Server Scripting Add-in
4 Configure the Monitored Folder


Before you can start to work with the Exchange Server Event Service and write
agents, you must install the service and get it running correctly in your
environment. By default, the Exchange Server Event Service is installed when
you install Exchange Server 5.5.

If you are upgrading from a previous version of Exchange Server, you
must add the Exchange Event Server Service during installation.

Configuring the Exchange Server Event Service is a four-step process.
Step 1: Change the Account Under Which the Exchange
Server Event Service Runs
By default, the Exchange Server Event Service logs on by using the credentials
of the Exchange Server Service Account. Although this account has permission
to access many of the items stored in Exchange Server, it has very limited
Windows NT permissions. If you want to change the level of access this
account has, or audit the account, you can change the Microsoft Windows NT
Server account under which the Exchange Server Event Service runs.
Use the Services program in Control Panel to change the Services account. To
do this, in Control Panel for the Exchange Server Event Service, click the
Services icon, and then change the Log On As settings.
Slide Objective
To list the steps involved in
setting up the Exchange
Server Event Service.
Lead-in
You set up the Exchange
Server Event Service by
changing the account under
which the Exchange Server
Event Service runs, giving
users permission to create
agents, installing the Server
Scripting add-in, and
configuring the monitored
folder.

Note
Module 13: Using the Microsoft Exchange Server Event Service 5


Ensuring the Specified Account Has Correct Permissions
If you do change the Windows NT Server account for the Exchange Server
Event Service, follow these guidelines.
 Ensure that the account you specify for the Event Service has the Log On
As A Service permission set in the User Manager for Domains.
 Ensure that the account has the proper Exchange Server permissions to
access any of the mailboxes or public folders where scripts will be installed.
Otherwise, your scripting agent will not function correctly. You set
permissions (such as Mailbox Owner and Send As permissions) for all
necessary resources in the Microsoft Exchange Server Administrator
Program.

Step 2: Give Users Permission to Create Agents
If you want users to write agents, you must first give them permission to do so.
You give users permission to create and bind agents by setting their permissions
for a system folder named EventConfig_servername, where servername is the
name of your server. You must have at least Author permissions for the
EventConfig_servername folder to grant additional permissions to users.
Giving Users Permissions to Create and Bind Agents
To give users permissions to create and bind agents:
1. Start the Exchange Server Administrator program.
2. Locate and select the EventConfig_servername folder, where servername is
the server on which the Exchange Server Event Service is running.
3. On the File menu, click Properties.
The Properties dialog box appears with the General tab active.
4. Click Client Permissions.

The Client Permissions dialog box appears.
5. Click Add, and then select the user (or account name) who will have
permission to run agents on this server.
6. In the Roles dialog box, click Author or another role with greater
permissions (for example, Owner).

6 Module 13: Using the Microsoft Exchange Server Event Service


Step 3: Install the Server Scripting Add-in
The Server Scripting add-in is not installed in Outlook 2000 by default. You
must install this add-in for event scripts to run properly.
Installing the Server Scripting Add-in
To install the Server Scripting add-in:
1. In Outlook 2000, on the Tools menu, click Options.
The Options dialog box appears.
2. Click the Other tab and then click Advanced Options.
The Advanced Options dialog box appears.
3. Click Add-In Manager.
The Add-In Manager dialog box appears.
4. Select the Server Scripting check box.
5. Click OK on each of the three open dialog boxes.

Step 4: Configure the Monitored Folder
Configuring the monitored folder is the final step in the process of configuring
the Exchange Server Event Service.

You must have Owner permission for the folder you intend to monitor.

Configuring the Monitored Folder

To configure the monitored folder:
1. In Outlook 2000, right-click the Exchange Server folder that you want to
monitor, and then click Properties on the shortcut menu.
The Properties dialog box for that folder appears.
2. Click the Agents tab.
3. Create, change, disable, or delete agents in your folder, and then click OK.

Note
Module 13: Using the Microsoft Exchange Server Event Service 7




 Introduction to Event Scripts
 Benefits of Event Scripts
 Limitations of Event Scripts
 Registry Settings for Script Authors


Event scripts respond to the user actions and timer events that occur on folders
monitored by the Exchange Server Event Service. You can programmatically
respond to folder events by:
 Writing your own agent.
 Using the Microsoft Exchange Server Routing Engine, which is a custom
agent that runs under the control of the Exchange Server Event Service.

You can write custom agents by using Microsoft Visual Basic®, Scripting
Edition (VBScript)
, Microsoft JScript®, or Microsoft Visual Studio®
(specifically the Microsoft Developer Studio Integrated Development

Environment) as your script editor. You can debug these scripts by using the
Microsoft Script Debugger program that is included with Microsoft Internet
Information Server.
Slide Objective
To outline this topic.
Lead-in
You can use an event script
to respond to events on
monitored Exchange Server
folders.
8 Module 13: Using the Microsoft Exchange Server Event Service


Benefits of Event Scripts
 Automated Exception Handling
 Availability of Directory Information
 State Tracking
 No Extra Client Logic
 Data Validation


The primary benefit of using event scripts is that servers—rather than client
computers—process business logic. Benefits are realized in other areas, as well.
Automated Exception Handling
You can use an event script to scan items in a folder for exceptions. For
example, an event script could detect messages that have not been updated for a
certain period of time. These messages could then trigger other messages or
update automatically.
Availability of Directory Information
Server-side event scripts can access directory information by using COM

objects such as Collaboration Data Objects (CDO) and Active Directory
Services Interfaces (ADSI). By accessing directory information from the server,
you can deploy applications to users whose computers may not contain object
libraries such as CDO and ADSI.
Slide Objective
To list the benefits to
developers of using event
scripts.
Lead-in
Besides the benefit of
processing business logic
on a server, using event
scripts provides several
other benefits.
Module 13: Using the Microsoft Exchange Server Event Service 9


State Tracking
The state of items within a folder application can be stored once, either within
the folder as messages or within a database. This is particularly useful when
you are waiting for an item to be posted or updated in a folder.
No Extra Client Logic
You can provide application functionality to users of clients other than
Outlook 2000—such as Post Office Protocol version 3 (POP3), Internet
Message Access Protocol 4 (IMAP4) and Web clients—by using server-side
event scripts.
Data Validation
You can move complex data validation from the client to a server. This can free
the client to perform other processing tasks and reduce network traffic while the
server verifies the data contained in a message. Any invalid data can be

returned to the user in the form of a failure message.
10 Module 13: Using the Microsoft Exchange Server Event Service


Limitations of Event Scripts
 Asynchronous Event Firing Limits Item Volume
 Including Business Logic on Folders Slows Exchange
Server
 Single-Threaded Architecture Limits Processing
 One Transaction Per Second Is the Practical Limit
 One-Hundred Scripts Per Server Is the Practical Limit
 Scripts Must Execute Within 15 Minutes


Before you decide to create an event script, you should understand the
limitations inherent in event scripting.
Asynchronous Event Firing Limits Item Volume
The Exchange Server Event Service fires events asynchronously, so the
Exchange Server information store will not block your event script or other
process, and will not stop people from working on items in the folder if your
script has not run.
Because of asynchronous event firing, a user or another process could delete,
move, or change an item before an event based on the item is fired and before
your script is executed. In this situation, your scripts would receive the proper
events, but the items might not be available. For this reason, do not use the
Exchange Server Event Service to monitor folders, such as your Inbox and
Outbox, that have very high volumes of items entering, leaving, or being
deleted. In these types of folders, the chances are greater that the user or the
rules engine on the server will move or delete the item before your script is run.
Including Business Logic on Folders Slows Exchange

Server
You should not use the Exchange Server Event Service to provide a mechanism
for rules containing business logic that you want installed on every folder in the
system. Such a system would slow the performance of the Exchange Server
computer running the Exchange Server Event Service because of the high
volume of messages generating events. In addition, you would have to
manually install the agent in every folder because the Exchange Server Event
Service does not provide this capability.
Slide Objective
To list the limitations of
using event scripts.
Lead-in
You should understand the
limitations of event scripting
before you develop an event
script.
Module 13: Using the Microsoft Exchange Server Event Service 11


Single-Threaded Architecture Limits Processing
The Exchange Server Event Service is single threaded; that is, scripts registered
on the server process one at a time. Because only one script can execute at a
time, all of the other scripts must wait for the first script to complete processing
before they can run.
One Transaction Per Second Is the Practical Limit
You should not consider using an event script for an application that requires
more than one application to be processed per second because the link between
the Exchange Server information store and the Exchange Server Event Service
is asynchronous, and because scripts are interpreted at run time.
One Hundred Scripts Per Server Is the Practical Limit

You should not use event scripting for an application that requires more than
100 event scripts to be registered on a single server. If you exceed this practical
limit, the amount of time required to process these scripts grows exponentially,
slowing response time.
Scripts Must Execute Within 15 Minutes
If a single script takes longer than 15 minutes to complete, the Exchange Server
Event Service considers the script to be in error and stops it from executing.
This 15-minute limit is active even if you are using the Script Debugger. If your
script stops unexpectedly while you are debugging, consider how long you have
had the debug environment open.
12 Module 13: Using the Microsoft Exchange Server Event Service


Registry Settings for Script Authors
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\MSExchangeES\Parameters
 DWORD Logging Level
 DWORD Maximum Execution Time For Scripts In
Seconds
 DWORD Maximum Size For Agent Log In KB
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\MSExchangeIS\ParametersSystems
 DWORD value ICS Notification Internal


Before creating event scripts, you should review the settings for two keys in the
registry to optimize the debugging and control capabilities in your scripts.
These modifications can lower the notification interval for ICS, which cause
events to fire faster, and can increase the amount of information saved to the
Windows NT Event Log.

Slide Objective
To list settings for two
registry keys that you should
review and consider
adjusting.
Lead-in
You can optimize scripts by
adjusting the settings for two
registry settings.
Module 13: Using the Microsoft Exchange Server Event Service 13


Reviewing the Script Registry Settings
To review the script registry settings:
1. Start the Registry Editor (regedit.exe) on your Exchange Server computer.
2. Locate the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
MSExchangeES\Parameters
a. This key has a DWORD named Logging Level. Logging Level specifies
how much information is written to the Windows NT Event Log. The
value for Logging Level ranges from 0 to 5, where 0 is the default value.
If Logging Level is set to 5, the maximum amount of information is
logged, but your log files may become quite large. Adjust the Logging
Level value according to your preference.
b. DWORD Maximum Execution Time For Scripts In Seconds sets the
maximum time a script can execute before it is terminated. When
developing scripts that need to access data sources at other locations or
on the network, you might want to increase the default value of 900 so
your scripts are not prematurely terminated.
c. DWORD Maximum Size For Agent Log In KB sets the log size for your

agents. The default value for this key is 32 KB. The log automatically
overwrites older events as necessary when this size is exceeded.
3. Locate the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
MSExchangeIS\ParametersSystem
α.
• If the DWORD value ICS Notification Interval does not already exist,
add it and set the value to the number of seconds between each ICS
notification to the Event Service. The default value is 60 seconds.
However, for testing and production servers, you might want to lower
this value to shorten the length of time between a change in the store and
the Event Service being notified.

14 Module 13: Using the Microsoft Exchange Server Event Service




 Writing an Event Script
 Binding an Agent to a Server
 Selecting the Events to Monitor
 Editing the Script
 Using Intrinsic Objects Passed When a Script Runs
 Security Considerations for Event Scripts


When you understand the purpose, benefits, limitations, and security
considerations of event scripting, you can write your own event scripts to
respond to folder events in the public folder information store. Writing an event
script involves four processes.

 Binding an agent to a server
 Selecting the events to monitor
 Editing the script
 Using intrinsic objects passed when a script runs

Slide Objective
To outline this topic.
Lead-in
To write an event script, you
bind an agent to a server,
select the event you want to
be monitored, and edit a
default event script that
uses intrinsic objects that
are passed when the script
runs.
Module 13: Using the Microsoft Exchange Server Event Service 15


Binding an Agent to a Server
Microsoft Exchange Administrator
Microsoft Exchange Administrator
File Edit View Tools Window Help
MS
Address Book Views
Folders
Public Folders
System Folders
EFORMS REGISTRY
Events Root

EventConfig_EXCHNGE3
OFFLINE ADDRESS BOOK
SCHEDULE + FREE BUSY
Global Address List
NorthAm
EXCHNG3
0 Object(s)
2:20 PM
Server EXCHNGE3 in Site NorthAm – EventConfig_EXCHNGE3
Server EXCHNGE3 in Site NorthAm – EventConfig_EXCHNGE3
Display Name


When the Exchange Server Event Service detects a change in a monitored
folder, it fires an event. It then looks for a corresponding event handler in the
folder. You associate an event handler with a specific event and folder by using
a process called binding. The Exchange Server Event Service includes a
prebuilt event handler—the Exchange Event Scripting Agent—that you can
bind to events.
The Exchange Event Scripting Agent is an event handler that allows you to
write with script languages such as VBScript and JScript. The scripts are passed
a pre-logged-on CDO session. From these scripts, you can also call other COM
components such as Microsoft ActiveX
® Data Objects (ADO), ADSI, or even
your own custom COM components written by using Visual Basic or Microsoft
Visual C++
®.
Using Outlook 2000 to Bind an Agent to a Server
One server running the Exchange Server Event Service can handle events for
any number of folders. Although the Exchange Server Event Service can be

running on any number of computers, a script runs only once per event, and
each event (and thus each script) is processed by only a single computer.
Therefore, binding an agent to a server means choosing which Exchange Server
Event Service computer will run the agent.
For example, to monitor a public folder for new postings, you first specify an
Exchange Server computer on which to run the events these postings will
trigger.
You can use Outlook 2000 to perform binding while you are creating agents. To
bind an agent to a server, select the server from the Run these agents on this
server drop-down list on the Agents property page. All the agents for a given
folder must be bound to the same server.
Slide Objective
To show the location of the
EventContig_servername
folder, which contains data
that connects folder events
to the server.
Lead-in
Binding enables you to
associate a folder event with
an event handler.
16 Module 13: Using the Microsoft Exchange Server Event Service


Location of Servers, Folders, Scripts, and Registration
Information
A folder on which you want to run a script can be either a private or pubic
folder, but it must exist on an Exchange Server computer.
Binding information is stored in a public folder that represents a server on
which the Exchange Server Event Service is running. Specifically, when an

administrator installs the Exchange Server Event Service, a new folder is
created in the non-IPM (Interpersonal Message) subtree of the information
store, under System Folders\Events Root\. This new folder is named
EventConfig_servername, and it exists to contain data that connects folder
events to this particular server.
The public folder information store, the Exchange Server Event Service, and the
agents can each be on different computer running Windows NT Server, or all
on the same server. To keep configuration simple, it is recommended that you
keep them on the same server whenever possible.
Author Permission is Needed to Bind Agents
The Exchange Server administrator, the user who configures public folders,
controls who is allowed to run scripts on a particular server. You must be
granted at least Author permission or higher to bind an agent to be run on a
particular server.
Module 13: Using the Microsoft Exchange Server Event Service 17


Selecting the Events to Monitor
 Folder_OnMessageCreated
 Message_OnChanged
 Folder_OnMessageDeleted
 Folder_OnTimer


The properties of an agent allow it to monitor one or more of the four events
that can be monitored. Three of the events are triggered by events within the
public folder information store and the fourth—Folder_OnTimer—is generated
by the Exchange Server Event Service.
 Folder_OnMessageCreated. This event is triggered when a message arrives
in the monitored folder. The message can have been sent or posted into the

folder.
 Message_OnChanged. This event is triggered when a message within the
folder is changed.
 Folder_OnMessageDeleted. This event is triggered when a message within
the folder is deleted.
 Folder_OnTimer. The event service generates this event on a scheduled
basis. If you enable this event you can select a Schedule button and specify
the period of the event.

Slide Objective
To list the four folder events
that can be monitored by an
event script.
Lead-in
You can register agents that
respond to any of the four
events that can be
monitored.
18 Module 13: Using the Microsoft Exchange Server Event Service


Editing the Script
 Working with the Default Script
 Editing Scripts by Using Notepad


Once you have specified the events to be monitored, you can add the script to
the agent.
Creating and Edit a Script in a Folder
To create and edit a script in a folder:

1. Start Outlook 2000 and locate the folder to which you want to bind events.
2. On the File menu, point to Folder, and then click Properties for
“folder_name”.
The “folder_name” Properties dialog box appears.
3. Click the Agents tab.
The Agents dialog box appears.
4. Click New.
The New Agent dialog box appears.
5. In the Agent Name box, enter the name of the agent.
The string entered is used as the PR_DISPLAY_NAME property of the
agent message that is written to the folder.
6. In the When the following event(s) occur list box, select one or more
check boxes to choose which folder events to monitor.
7. Click the Script option to use the default script agent, which you can edit.
8. Click Edit Script.
Your default script editor (Notepad) starts. A default script opens.

Slide Objective
To outline the topics
associated with editing
event scripts.
Lead-in
You can edit default event
scripts by using Microsoft
Notepad.
Module 13: Using the Microsoft Exchange Server Event Service 19


Working with the Default Script
The default script contains the Sub statements for all four events that can be

monitored, whether you select to monitor them or not. Any scripting language
installed on the server can be used within the agent script (for example,
VBScript or JScript). The default script assumes that VBScript will be used.

It is not possible to use Visual Basic directly within an agent. For more
information about using Visual Basic and the interface support required by the
Exchange Server Event Service, see the Agent.hlp file on the Exchange Server
5.5 product compact disc.

Editing Scripts by Using Notepad
Most event scripts are small. A typical script might be 30 to 60 lines of code.
Microsoft Notepad is an acceptable editor for scripts of this size. One challenge
presented by Notepad is finding a particular line of code that is reported by the
VBScript engine as in error. Notepad does not provide a method for jumping to
a particular line.
Note
20 Module 13: Using the Microsoft Exchange Server Event Service


Using Intrinsic Objects Passed When a Script Runs
 Using the EventDetails.Session Object
 Using the EventDetails.FolderID Variable
 Using the EventDetails.MessageID Variable


CDO represents the intrinsic object model for your scripts. When you are
writing agents, the Exchange Server Event Service passes you some objects and
variables that you can use to determine what item triggered the event and in
what folder the item is located. To help you access these items quickly, as well
as access other Exchange Server items, the Exchange Server Event Service also

passes a pre-logged-on CDO session so you do not have to log on to the
Exchange Server yourself.
Using the EventDetails.Session Object
The EventDetails.Session object represents the CDO session the agent is
currently logged on as. Because a script is passed this pre-logged-on CDO
session, it automatically has access to all CDO objects, such as messages,
appointment items, and Exchange Server directory information for lookups.
The Exchange Server Event Service determines which identity to use for
logging on to your script by using the identity of the author who most recently
saved the script. This is important to consider for two reasons:
 The functionality of your application might depend on access to specific
items in the Exchange Server Information Store. If the most recent author
does not have access to this information, your script will not work.
 Any mail you send from your script will use the name of the pre-logged-on
CDO session because the Exchange Server Event Service is logging on as
this user. The sent messages will also be saved in the Sent Items folder of
that user.

For these reasons, consider creating unique identities for your agents, and log
on as these users to save your scripts.
Slide Objective
To list the objects and
variables passed when an
event script runs.
Lead-in
You can use objects and
variables passed by the
Exchange Server Event
Service to determine which
item triggered an event and

in which folder an event
occurred.
Module 13: Using the Microsoft Exchange Server Event Service 21


Using the EventDetails.FolderID Variable
The EventDetails.FolderID variable contains the entry identifier of the folder
in which the event took place. By using this variable with the CDO GetFolder
method, you can quickly retrieve the correct folder for the event. You should
assign this variable to another variable in your script.

In Exchange Server 5.5 Service Pack 2 or later, the GetFolder method of
the CDO Session object requires that the StoreID parameter is either passed or
set to Null.

Using the EventDetails.MessageID Variable
The EventDetails.MessageID variable contains the entry identifier of the
message that triggered the event. By using this variable with the CDO
GetMessage method, you can quickly retrieve the exact message to which the
event corresponds. Be aware, however, that timer events do not pass an
EventDetails.MessageID variable, because no message triggers the event.
Rather, an elapsed amount of time triggers the event. Keep this in mind when
creating scripts, because an error related to EventDetails.MessageID for a
timer event can be difficult to track down when debugging.
Note