Using VBS Event Sink scripts with the Web Storage System

    The Exchange 2000 Web Storage system provides a scalable way to implement event sink code in a variety of languages and methods. For low volume or development systems an easy way to start taking advantage of these Web Storage System Event sinks is to use VBS scripts (or Jscripts). These type of scripts are easy to write and will run on any W2K server without the need to install any further software.
    To start using VBS event sinks you need to first install the Event sink host COM+ object which is provided with Exchange. All Web Storage System event sinks are implemented as COM+ applications. What the Event sink scripting host allows you to do once installed is create event sinks as VBS scripts that run in the context of this COM+ object. Microsoft provides an event sink script host in the form of two DLL files . These DLL's are copied to your server as part of the Exchange 2000  installation but the COM+ application is not registered as part of the installation. Q base article 264995 address's how to install and register the script host on a server. This article raises a number of Issue's in regards to the security and use of this script host sink that I will try to go through.

Security for the WSS script host sink
    All Web Storage System event sinks need to be wrapped in a COM+ application wrapper and registered on the operating system to function. The Eshmts.vbs script file creates a COM+ wrapper for the event sink script host and sets the account for this to run as the EUSER_EXSTOREEVENT user. This user usually has full administrative rights to your exchange server and active directory environment. Event sinks are usually fired by the NT system account which spawns the appropriate COM+ application.  The security problem this creates is once the script host sink is installed its handles (which are public published in the ESDK) will be available for all users to use. If a user has owner rights to a folder they can create an event sink registration on this folder. This means a user could take advantage of the event sink host in the default mode by registering an event sink script that would execute under the Admin users context. To avoid this situation you have a few options, the first is not to install the script host sink on servers that host user mailboxes, if you have other servers in your organization without user mailboxes this would be a better location for any scripted event sinks. The other option is to change the security of the WSS script host sink COM+ application to a user that only has enough rights to perform the tasks you are doing with the event sink. EG if you want an event sink that downloads attachments sent to a specific mailbox, create a user that only has permissions to that mailbox and the rights to the location you want to download to and no other rights. The third option is to write your own event sinks using VB or C++ these are implemented as compiled code with private handles which increases security and performance
Comments
    Although it would take a decent amount of technical knowledge and software for a user to exploit the security hole created by this script host sink you are still leaving the door open if you do it. To be completely professional consider creating your own event sinks in VB or C and use the ICreateRegistration Interface to check who's trying to register your event sink and stop them if necessary.

The Next Step
    Once you are over the security hang ups and installation woes you are now ready to actually start coding and registering your scripts to run. With the Web Storage system  there are 3 event types  Synchronous, Asynchronous and System events. System events are one of three types onMDBstart, OnMDBshutdown and On Timer these events are useful for performing system actions when the information store is being started or shutdown. Synchronous and Asynchronous events can be used to implement events on folders such as inbox or public folders. The main difference between Synchronous and Asynchronous events is the way in which these events are processed. Synchronous events are fired twice once at the begin and once for the commit phase before a  mail object is committed to the Web Storage System. Exchange waits for each synchronous event sink to finish before calling the next sink if you required an event sink that prevented a mail from being committed to the Web Storage System use a synchronous event . Asynchronous events fire after exchange has performed an action eg. once a mail has been delivered to your inbox. Which event you choose to use depends on the functionality you want, I would always trend toward Asynchronous events as they are easier to deal with and cause less load on your server compared to a Synchronous event which fires twice.

Registering your Scripts
    After you have written your code you then need to create an event sink registration object for your script.  There are a few methods of achieving this all of which involve having the Exchange SDK and utilities which are available from MSDN. The first and easiest method to register a script is using the REGEVENT.vbs script that comes with the Exchange SDK. An example of registering an Asynchronous onsave event sink you would type

cscript regevent.vbs ADD "onsave" ExOleDB.ScriptEventSink.1 file://./backofficestorage/youraddomain.com/mbx/User/inbox/evtsnk1 -file c:\script1.vbs

to remove the script you can type

cscript regevent.vbs delete  file://./backofficestorage/youraddomain.com/mbx/User/inbox/evtsnk1

For more information on using this script refer to the Exchange SDK the are few good examples within the regevent.vbs file itself (look at the wscript.echo's at the end of the code). The other method of registering an event sink is to use the WSS explorer which is one of the ESDK utilitys that can be downloaded from Microsoft.

First Script
    The best way to see how it all works is start with a simple script

<SCRIPT LANGUAGE="VBScript">

Sub ExStoreEvents_OnSave(pEventInfo, bstrURLItem, lFlags)
Set fso = CreateObject("Scripting.FileSystemObject")
set wfile = fso.opentextfile("c:\temp\tevent.txt",2,true)
wfile.write (bstrURLItem)
wfile.close
set fso = nothing
set wfile = nothing
End Sub

</SCRIPT>

    The first important thing you need to do when writing event sink scripts is you must have your code wrapped in the <SCRIPT LANGUAGE="VBScript"></SCRIPT> tags. The next thing you will notice is the three arguments being passed into the Onsave Sub procedure. These are the only arguments that are available to pass into the sub, the most interesting of these being the bstrURLItem which is the WSS URL of the item that triggers the event. You can use this URL to gain access to the mail item by using either ADO or CDO. for example

ADO method (opens the mail that initiated the event and access's the subject and sender properties of that email)

Dim ADODBRec
Set Rec = CreateObject("ADODB.Record")
rec.Open bstrURLItem
Sender =  rec.Fields("urn:schemas:httpmail:sendername")
subject =  rec.Fields("urn:schemas:mailheader:subject")

CDO method

Dim msgobj
Set msgobj = CreateObject("CDO.Message")
msgobj.DataSource.Open bstrURLItem
Sender = msgobj.from
subject = msgobj.subject

Other Useful things to do

       Some other things you can do with WSS event sinks is Attachment processing here is some code you can use to save the attachments of a mail to a local drive

savepath = "c:\temp\"
Set msgobj = CreateObject("CDO.Message")
msgobj.DataSource.Open bstrURLItem
For Each objAttachment In msgobj.Attachments
    savefile = savepath
    savefile = savefile & objAttachment.filename
    objAttachment.SaveToFile savefile
next
set msgobj = nothing

Conclusion

    WSS event sinks are a great leap forward for Exchange 2000, the ability to use VBS scripts brings down the level of skill and complication it requires to start taking advantage of the functions of this product. You should always remain aware of the security implications of any event sinks you implement and its advisable to always air on the side of caution when it comes to user mailbox servers.