About Folder Scripting

Scripts may be associated with private Exchange server folders (mailboxes) as well as with public folders. The following types if events can fire up a script: timer events, posting, editing or deleting a message. Collaboration Data Objects may be used within scripts. You may get access to Exchange Server services through them.
 

Bad News First

There are three features in Exchange folder scripting design that disappoint. They are complicated setup, unreliability, and slow speed of execution.
 

Setup
 
Exchange server and all its clients are evolutionary products. This means that each release is different, sometimes radically. Compare, for example, Exchange client and Outlook client.

Folder scripting is managed by Outlook. A user of Microsoft Outlook writes scripts and puts them into folders using Outlook. The problem here is correct setup. Setup is really a two-fold problem. First, on Exchange server permissions should be properly configured. Second, you need to extend (configure) your Outlook client. Sometimes it is difficult to make the thing go because it is buried deep in the user interface. In addition, Outlook versions differ significantly, and what was working for a previous release may not work for next.
 

Reliability and Speed

The other two issues that are important for workflow applications are speed of execution and reliability of execution. I must say that Exchange folder scripting technology is weak in both. Both are limited by design of the whole thing. Information store episodically communicates changes to the Exchange Event Service, which in turn runs agents, which in turn run scripts. Default delay is 1 minute (subject to "not recommended in production" change). You (or other user) can easily remove a message from a folder before your script is given a chance to run. Reliability is thus not available, as well as speed for the same reason.
 

Typical Scenarios

In spite of the limitations described above folder scripting technology may may still be usable in certain situations, where its risks are understood and taken care of. This architecture allows to create workflow applications, where a message may follow a complex route with changes at each node if necessary. For example, an originator may fill out an expense form that first goes to a manager, then to the department that takes care of reimbursements, then back to the originator in a form of payment notification. Another example would be in a web publishing group, where a designer creates a draft for a web page, which is then routed to editors, other designers, and back until everybody is happy, then to quality assurance team, and finally makes its way to a web server.
 

Difference from Rules

Folder scripts are functionally similar to Exchange server rules. They both are associated with a specific folder and are fired when a certain event occurs. There is an important difference, though. A rule and an action associated with it are always enforced. Every change in a folder is subject to all folder rules and associated actions. This is not the case for scripts. Scripts are fired asynchronously. If a predetermined event occurs a script is given a chance to run. Nothing, however, protects folder contents in the meantime. Other processes may interfere and modify the folder. It may happen that your script sometimes will have nothing to do. For example, a script in Outbox will compete with MAPI spooler. A script is likely to loose this competition. You should know about this limitation and use the technique only in appropriate circumstances. Normally they are fine in low or medium volume folders in a non competitive environment. Keep in mind the users may also compete with scripts if they have access to folders.
 
I this chapter I am going to cover basics of Exchange folder scripting and present a very simple script example. The script will just reply to every post in a folder by sending the "Hello, world!" message.