There are many aspects of an Enterprise Vault Exchange-based Email Archiving Policy. Just a few years ago everything you could want to do was all in one policy, but it has been changed so that there is a desktop part, and an archiving part.
There are dozens of settings that can be changed, and the question is how to make the best policy for the users in an organisation which be spread across the globe encompassing many different types of user, and many different cultures. With all the different settings available, and the huge range of combinations of settings, how can you find out the ‘best’ policy settings?
For me though, I’d like to try to distill the thoughts around the archiving policy into five main areas that I’ll cover in this article.
Will you make shortcuts?
The first question that comes to my mind is whether or not shortcuts should be created. This is a setting on the ‘Archiving Actions’ tab of the archiving policy:
Usually the reason for keeping shortcuts comes down to the users needing to be able to see all of their mail, both live and archived, in one place. Some users need that, others don’t mind not having ‘old’ or unused items being removed (and stored in the archive, of course)
If you decide that you will create shortcuts to archived items, then there is another big range of options such as how much content will go in to the shortcut, and so on. But again, boiling things down to the basics, my additional thoughts and questions would be:
What will they look like?
Assuming you are going to keep shortcuts to archived items, what is that shortcut going to look like? There are a range of options available, on the Shortcut Content tab:
The biggest choice here is to decide how much content will be kept in the shortcut itself. This is a trade off between saving space, and how close to the original item you want the shortcut to be. You can go to the extreme of ‘use message body’, which means essentially it’s not a shortcut at all. Or you can go to the other extreme of including just a few characters in the body.
If you opt to have part of the body remaining (eg 1000 characters) then I would suggest including the ‘banner’ and the ‘Include link to archived item’ options. This way users will be able to easily identify that the item is an archived one, and not a ‘problem’ opening an existing or new email item that might appear blank or short/cut-off.
How long will you keep them?
Another question to ask is how long these shortcuts will be kept in the mailbox? Forever? Or shorter? This is configured on the Shortcut Deletion tab:
Sometimes part of the reason for using Enterprise Vault is that you want to be able to control the size of mailboxes, at least to some extent. So, keeping shortcuts to archived content forever might not be a real option. This again is something that you have to figure out for the environment you’re working on.
Remember though that even though the shortcuts are small.. tens of thousands of them will still consume quite a sizeable amount of a users mailbox quota.
Will you archive based on age, quota or a combination?
A big question that comes up is what to archive. To answer this sort of question you have to think about the user experience. If you archive simply based on age, for many situations, that is good. All the ‘old stuff’ will be archived. All the live data will still be untouched.
The other original option is archive purely based on quota.. to keep mailboxes under the imposed Exchange limits. And the third option, as shown above, is a combination of the two. As mentioned the things to balance here are the user experience versus the mailbox quotas. Think carefully about this.
Will you expire archived items?
Once you’ve got things covered in terms of what is being archived, and, you’ve gotten to the bottom of how long to keep shortcuts the next thing to consider is how long you should keep the archived items in the archive.
Deleting or expiring archived content is often a contentious discussion amongst IT people and Legal people. Keeping things forever can make both of these groups feel upset; IT people don’t want the storage requirements, and Legal people don’t want to lose anything ‘vital’.
The decision, once made, is then implemented partly within retention categories, and partly on the site properties as shown above.
Will all users get the same policy?
In small organisations based all in the same office, or the same country might be suited to having all users using the same policy. This is not always the case, and is almost certainly not the case when it comes to global organisations.
So, the thing to decide with the archiving policy is who will get hit by which policies, and that’s implemented in Enterprise Vault using Provisioning Groups.
I’ve seen some customers so have a handful, others with just one or two, and a few that have a dozen or more. Think carefully about the types of users that exist in the organisation and are in scope for being archived by Enterprise Vault, and try to distill those people down in to a few groups. These are then your provisioning groups, along with associated archiving and desktop policies.
What will your retention categories be?
The final thing to think about, and this ties in with the idea of how long will data be kept for, is the list of retention categories. These are defined at a site level within Enterprise Vault, and are typed to each provisioning group.
So you might have a VIP retention category where data is kept for 10 years, and a provisioning group for VIP users and tying these together will be the users and the retention category.
Defining the retention categories and implementing them is a joint task between the Enterprise Vault team, and the legal team within a company. Care should also be taken when again thinking about cross cultural needs, and different legal requirements in different countries.
Overall
As you can see there is a huge amount of discussion needed and it’s not a simple exercise to define what is needed when trying to implement archiving policies. Are there other things that you typically consider? Let me know in the comments below.
