The Artisan Mailbox Manager Rules System

A key component of the ArtiSan system is the Rules Engine. This component integrates the standard Microsoft VBScript engine into the system and is used for storing both rules and policies. The purpose of the ArtiSan rules system is to evaluate whether an item needs to be archived or stubbed and, if so, what retention period should be applied to the item.

The rules tree structure is created through a combination of queries to the active directory and Exchange. The rules tree is just a model of the various users and groups, mailbox and public folders in the ADS and Exchange. There are also nodes that represent an internal rule mechanism called a template.

In general, the system looks for a rule that is specific to a folder and then searches iteratively to ever more generalised rules that might apply to a message. For instance, you can apply a default rule for the entire organisation and then have specialised rules that override the company default for specific groups or individuals within the company. The groups, users and folders exist by virtue that they exist in Exchange and ADS, requiring no major additional data input and ensuring that the software tracks updates in those systems.

Each rule can either be a custom rule in its own right or it can refer to a template. The system comes with a series of builtin templates to suit specific business requirements.

The management UI stores the rule definitions in industry standard XML files. These files can be shared across multiple ArtiSan servers allowing the definition of company archive policy to be centraised and consistent.

The scripting engine is a standard VBScript engine exactly the same as used by ASP files and cscript/wscript. Consequently, many administrators will have some familiarity with it as these are common tools for automation of administrative tasks. Since the rules system is using a standard and extensible scripting engine, the rules system is very flexible whilst remaining familiar.

The system executes the scripts in order that it has found them in the tree until either there are no more scripts or a script indicates that archival should take place. In general, if there is no rule defined, then the system will do nothing. The scripting engine can execute rules very quickly; measured in 1000s of evaluations per second.

During the evaluation of each rule, the Rules engine presents information about the item being examined allowing the scriptlet to adapt its behaviour on the basis of the content in the mail message. Rules can be scripted on the basis of information from the mail such as subject, sender, recipients, size or on the basis of chronological information such as date the message was sent, date of archival, etc. This permits rules to be modelled against sophisticated business requirements.

Finally, the Rules engine also supports the option to avoid or defer further processing on individual messages. This feature, termed Smart Rules, allows specific actions to be scheduled relative to other events. For example, rules can specify that message archival occurs immediately but message stubbing should only occur 30 days after the message was first archived. This type of rule ensures that there is enough time between archival and stubbing to guarantee that the archive has been sufficiently backed up before the content within Exchange is stubbed.

Smart Rules also works in tandem with the Engine to optimise the processing of user mailboxes. The Engine is intelligent enough to skip messages that have been fully processed or where rules have previously deferred processing. In the event of rules being subsequently modified, the Engine can also detect this and reprocess all folder messages regardless of their current state.