Records Management in Exchange Server 2007 and Outlook 2007 in 5 Easy Steps

Published Sep 19 2006 02:53 PM 2,206 Views

In my last post, I wrote about why records management is important. This post will cover how Exchange 2007 and Outlook 2007 will help you with this.

1. Place your e-mail content in a place where you can manage it:

Exchange 2007 offers a wealth of records management features but it has to be able to see the e-mail to manage it. This means that e-mail needs to be in your Exchange mailbox and not stored in a client-only location such as a "Personal Folder" (.PST). The first move is to increase the size of your mailbox quotas so that users can fit all the e-mail they needed into them. We've done a lot of work in Exchange, including the new 64 bit architecture, to make larger mailboxes much more performant and manageable. The next step is to wean users from their .PSTs in as painless a manner as possible. Using group policies, you can prevent new items from being added to .PSTs. Users well still have access to what's already there while the same time being encouraged to place mail they want to keep into their Exchange mailbox. Eventually, you may want to remove .PSTs altogether.

2. Give users a way to classify e-mail:

Most laws and regulations governing records management are based on the content of the item being managed. This means that in many cases you cannot simply create a single records management policy for all e-mail and be done with it. Yet even if you do create all the appropriate policies for different classes of items, you still have to classify each e-mail to decide which policy applies. Some automated mechanisms exist, though as yet none have a proven track record and are in widespread use. Our approach in Exchange 2007 has been to allow the user to participate in this classification.

Administrators can create "managed custom folders," folders with configurable names and brief policy descriptions that appear in Outlook and Outlook Web Access. These are mailbox folders (not public folders) that map to the various classifications of e-mail in your enterprise. Administrators can push these into the mailboxes of specific users. There is also the self service model available, whereby a custom web application can leverage Exchange web services to allow users to choose their own folders from a web page. Each one of these folders can have its own policy to control the lifespan of the e-mail (I'll discuss these policies further below). All the user needs to do is move the item into the appropriate folder and Exchange takes care of the rest.

3. Keep the content that you do need

Each one of the managed custom folders or managed default folders (folder that everyone has, such as the Inbox and Sent Items), can have policies that allow a copy of content to be preserved. This works by journaling (copying) any message placed into one of these folders to another location. This location can be anywhere with an SMTP address, including an Exchange mailbox or a SharePoint server. SharePoint 2007 has some excellent features that allow it to receive e-mail from Exchange and enforce advanced retention policies on it (that team's blog is here).

4. Get rid of the content you don't need

On each one of these managed custom or managed default folders, you can also configure policies that remove e-mail that's no longer needed for business or legal reasons. Once this mail reaches a certain age, it can be deleted immediately or moved to another folder where it will remain for a customizable period of time so that it can be reviewed before it's deleted.

One way to use this is to place a relatively short retention period on default folders such as the Inbox and a longer one on managed custom folders. This encourages users to file items that they want to keep into their managed custom folders. The items left in the Inbox will just go away on their own. Of course, you need to structure your policies in keeping with any laws, regulations, and company mandates that affect your documents.

5. Monitor and troubleshoot records management

Once you've implemented your policies, you can keep an eye on what's actually happening. To see how users are using their folders, we have a PowerShell task that allows you to generate a report for one or more mailboxes that shows how users are filing items into each of their folders. On the administrative side, we have optional logging for what the server does to enforce policy (journaling, enforcing retention, etc.) as well as logging at the PowerShell level to track what the administrators are doing. This logging extends beyond messaging records management and keeps a record of any administrative action done using PowerShell or the Exchange Management Console (which uses PowerShell under the covers).

There's a wealth of detail to be added here in each of these areas. You'll see posts from me in upcoming weeks that describe how to use each of these features.

- Julian Zbogar-Smith

Not applicable

Is there any kind of API / programatic access to these 'managed custom folders' and 'managed default folders' to determine what the retention policies are etc ??

How would these be accessed via MAPI, are you extending MAPI to support these ??

.. Ken
Not applicable
The basic problem with trying to do records management in this fashion is that it relies too much on the end user to determine what information needs to be kept and for how long.  No matter what mail system you use, expecting users to manage the retainment of correspondence that could have legal consequences is not exactly what I would call a bullet proof solution.  After a long investigation, the only solution that I came up with is to make a copy of every piece of correspondence that is sent in the organization.  Allowing users to classify that information after it's been captured is always an option, but making them determine what should be saved is a recipe for disaster.

Aside from that, how do you envision handling emails that are encrypted?  Also, since you are planning on moving it Sharepoint, how do you handle data integrity of the underlying meta data?

Not applicable
Hence you always have the option on not using Managed Folders and simply rely on using the Journaling functionality in E2007 in combination with an external archiving solution.  With the volume of emails that some organizations see even SharePoint might not be able to handle that volume / size (i.e. millions of messages per hour).   A company will have to work with its own legal team to see what policies they need to have to become compliant with legal regulations or potential litigations.  This isn't up to a vendor to decide .. they offer only a set of tools to achieve that goal.
Not applicable
Use KVS/Enterprise Vault.
Not applicable
KVS Enteprise Vault uses end of life technology that isn't being disclosed by the vendor
Not applicable
Please explain what you mean about Enterprise Vault going end of life.
Not applicable
It seems the biggest "problem" with Exchange storage management is that attachments are stored along with the mail-content.

Why not separate out the attachments as they are delivered to the server?  For instance, you could have 10 mailbox stores on a server of a small size, and 1 large "attachment-store" that single-instance-stores the attachments.

Fundamentally this is how various "archiving" packages work -- but why not build this into the Exchange message delivery process -- rather than trying to re-process everything after its delivered to the mailbox store?
Not applicable
Does Records Management require an Enterprise CAL?  
Not applicable

Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects....
Not applicable
Greetings, everyone! In this post, we are going to conclude our discussion of e-mail records management
Not applicable
 Outlook 2007 is the latest version of the e-mail client for accessing an Exchange mailbox. To make...
Not applicable
Hello folks, We can see many times in the Exchange Server 2007 documentation that we can keep information
Version history
Last update:
‎Jul 01 2019 03:18 PM
Updated by: