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

Contents Overview 1 Introduction to the Exchange Server Introduction to Event Scripts 7 Writing an Event Script 14 Debugging Event Scripts 24 Using Event Scripts in Solutions 30 Ex

Contents

Overview 1

Introduction to the Exchange Server

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

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

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

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

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

In this module, you will learn

how to incorporate the

Exchange Server Event

Service and the Event

Scripting Agent in a

collaborative solution

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

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

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

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)

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

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

Benefits of Event Scripts

Automated Exception Handling

Availability of Directory Information

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

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

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

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

Registry Settings for Script Authors

HKEY_LOCAL_MACHINE\System\CurrentControlSet\

Services\MSExchangeES\Parameters

Seconds

HKEY_LOCAL_MACHINE\System\CurrentControlSet\

Services\MSExchangeIS\ParametersSystems

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

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

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

Binding an Agent to a Server

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

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

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

Selecting the Events to Monitor

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

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

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

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

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

Security Considerations for Event Scripts

Exchange Server Scripting Agent Creates CDO Session

Exchange Server permissions

Running scripts with a lower-privilege Windows NT account

Because event scripting uses Exchange Server objects, it is important to consider the level of Exchange Server permissions for scripts However, because event scripting can also use objects other than those provided by Exchange Server, it is also important to consider Windows NT permissions

Exchange Server Scripting Agent Creates CDO Session

The Exchange Server Scripting Agent creates a CDO session based on the mailbox identity of the script author This means that the Exchange Server Scripting Agent has Exchange Server permissions equal to those of the script author when accessing objects within the CDO session

Exchange Server Scripting Agent Permissions Match Exchange Server Permissions

Typically, the Exchange Server Scripting Agent runs on the Exchange Server site service account, whose Windows NT permissions match those of basic Exchange Server components, such as the directory service and the information store This means that the agent has the same broad powers on the system as Exchange Server itself The agent can, for example, open any recipient’s mailbox (In fact, it does open the mailbox of the script author, to determine that person’s Exchange Server identity.)

For this reason, unless you use Microsoft Transaction Server (MTS) as described later in this module, you should only allow trusted developers to create and bind scripts that run on your Exchange Server computers

Slide Objective

To outline the security

considerations you should

take into account when

using event scripts

Lead-in

When creating event scripts,

you should consider

permissions for both

Exchange Server and

Windows NT

For more information about granting permissions to run scripts on your

servers, see the Exchange Server (version 5.5) Getting Started Guide

Running Scripts with a Lower-Privilege Windows NT Account

See the Exchange Server 5.5 Release Notes for information about how to use as

a process manager for running your scripts under a particular Windows NT security account (for example, as the IUSER_MACHINE account that is created for Internet Information Server anonymous logons) MTS is available as

a component of Windows NT Server version 4.0 Option Pack

Note

Debugging Event Scripts

Using the Script Debugger

Error Trapping and Logging

Using the Windows NT Event Log

The Script Debugger included with Microsoft Internet Information Server and the Windows NT Event Log are powerful tools that you can use to find and remove programming errors in your event scripts

Slide Objective

To outline this topic

Lead-in

You can use Script

Debugger and the

Windows NT Event Log to

resolve programming errors,

or you can encapsulate the

functionality of your event

script within a COM

component to simplify the

debugging process

Using the Script Debugger

File Edit View Debug Window Help

End If Stop Set objOL = CreateObject (“Outlook.Application”) Set objNS = objOL.GetNamespace (“MAPI”)

If Err then MakeResponseMessage strSubject, “Couldn’t GetNam exit sub

End if strCurrentUser = AMSession.CurrentUser objNS.Logon strCurrentUser, “”, false, false

If Err then MakeResponseMessage strSubject, “Couldn’t Logon”

Microsoft Script Debugger

Read only – VBScript – script block [break]

You can use the Script Debugger to find errors and test your Exchange Server event scripts Although you cannot edit the script that is being debugged, you can save it under a new name When you have finished editing, you can load the new page in the agent script The Script Debugger is included with Internet Information Server version 4.0 and later and with Microsoft Internet Explorer version 4.0 and later

It is recommended that you use the version of the Script Debugger that is included with Internet Information Server rather than the version that is

included with Microsoft Internet Explorer

By using Microsoft Script Debugger, you can:

View the source code of the script you are debugging

Control execution line-by-line through the script

View and alter variable and property values

Set breakpoints and view the call stack

Switch between threads of execution

Working with the Script Debugger

To force your script to hit a breakpoint—and pause execution—use the Stop

statement in VBScript To stop script execution, press F8, and to resume script execution, press F5 You can also open the Immediate window to examine the current value of variables by pressing CTRL+G

programming errors in event

scripts if you have the

appropriate permissions and

the server on which the

script is running does not

host critical business

applications

Note