Attachment-less Mailbox Script

Introduction

As email systems get older and older there is one particular problem that will  bug any aspiring Email administrator and email systems in general. This is the size at which mailboxes grow and the fact that humans are hunter gatherers and prefer to store email just in case sometime in the next century the entire fate of  human kind may rest on an email that was sent by Sue in Marketing one Wednesday afternoon. Jokes aside mail stores tend to always grow exponentially every year and if you start to look at the technical statistics of what is being stored in your mail system and the way its stored you may find yourself asking some of the same questions that lead to the development of the following scripts. The following article details two event sinks that are designed to be attached to a mailbox that will download any mail attachments that are received into a users mailbox and save them to a file server or archive server, replace the email attachment with a hyperlink to where the attachment now is stored on the file server and delete the attachment from the email. Another event sink will delete the attachment from the file system with the mail is eventually deleted.

Why would you want to do this ?

I guess the first thing you should realise about this script idea is if it was a really good idea they would have designed the email system to do this in the first place.. So now we know its not a really good idea lets just refer to it as an alternative idea and look at some of the pros and cons and logic that is behind it. Attachments usually take up around 3/4 of the space in your Exchange message store as your mail store gets larger it gets harder to managed,backup and repair if something goes wrong.

Cons

One of the major cons in downloading every email attachment to a file server has to be the loss in Single instance storage. So the space problem you may have been trying to solve in your mail system could now be twice as worse on your file server. For those unacquaintance with single instance storage it goes something like this if I send a 5 MB message to 5 people on my mail server the message is only stored once on the mail server. With these event sinks the same email would be download 5 times therefore using 25 MB on your file server instead of 5 MB on your mail server. But as Microsoft have pointed out the main benefit of using SIS is that it cuts down delivery time of a message "Even a "mature" server is likely to have a storage ratio slightly greater than 1,but you should not count on single instance storage at all when doing capacity planning. In some cases, the ratio may even drop slightly below 1 because of miscellaneous database overhead" . Performance overhead is another major hurdle, if you have a lot of mailboxes on a server with these scripts attached you are going to have a performance hit during any sort of mail out with an attachment.

If your  users use Outllook Web Access because the attachments are now being download to the file server they are no longer going to be available to OWA users. There are also problems if people want to forward a mail with an attachment as they would no longer be able to do this because it will no longer be attached to the mail they received.

The attachment icon in Outlook is also removed so a user can nolonger tell if a message has an attachment or not until they go into that actually message and check to see if there is a hyperlink down the bottom of the email

These are only a few of what are a large number of potential issues for this alternative idea so lets look at what the Pros of these type of scripts are.

Pros

Exchange 2000 has gone someway to improving the problem of everything in your mail system being stored in one large file (now everything is stored in two large files). Multiple mail stores on Exchange 2000 Enterprise Editions are a good start as long as you can afford the licenses. But the fundamental problem is you have these large files that you must backup and sometimes perform maintenance on . The main pro of this script is that on average it will reduce the size of large mailboxes by 75 % so that a 250 MB mailbox can be reduced to around 75 MB. Attachments which are stored uncompressed in the Exchange store can then be stored compressed on your file system. If you use some sort of HFS archive system you can then take advantage of this for your mail attachments For remote sites that don't have an email server but have a file server you can have all the users attachments downloaded to their server so when the user goes to retrieve an attachment they don't have to download it over the WAN (there are some reverse problems here if you think about it). Another Pro of this script is because attachments are saved to a file server a user can go in access these attachments and index etc without having to go into their email to do it. This can assist greatly when trying to search for a particular attachment that someone has sent to you (you can't currently do this with Outlook)

A Warning

Before you look at using these scripts you need to understand one Major point "these scripts are designed to modify the contents of email that is sent to a user". No matter how much testing you do on something there is no guarantees that this will work or work in an adverse way that may cause data loss on your server. Before even considering running these type of scripts make sure you have full backups of your email server and know how to do a restore.  If an email is in Rich Text these scripts will convert the email into HTML because there is no way i know of to append to an RTF email and keep the formatting (this doesn't mean its not possible though it just one of things I couldn't work out how to do). So use at your own risk and if you don't understand how these scripts work its probably better not to use them at all (or use it as an excuse to learn VBS or rewrite them as you own)

Part 2 - How does it work                                                Download Script