Exchange Server 2010 Compliance Capabilities

Exchange 2010 now has more features to assist System Admistrators with Compliance, but are these features sufficient? Are they easy to use? Michael Smith gives a roundup of these new features, and points out where are useful, and where they fall short of providing a complete solution to the compliance task

In Exchange Server 2010, Microsoft continued the process of enhancing the feature set available as a part of Exchange Server, adding many new capabilities. An area that experienced much effort was the area of compliance. In this article, we will discuss a number of the newly available features, both where they provide benefits and where they fall short.

The topics we will cover include only those compliance capabilities available within the core Exchange product. These are:

  • Message Classification
  • Messaging Records Management v1 – Managed Folders
  • Messaging Records Management v2 – Retention Policies
  • Rights Management
  • Transport Rules
  • Discovery Search
  • User Archive Mailbox

Message Classification

Beginning in Exchange Server 2007 and continuing in Exchange Server 2010, Microsoft made the decision that identifying the class of any given message was a user activity. An Exchange administrator creates the message classifications that are available to users and the user may optionally assign a classification to a message when they create the message.

Specifying a classification allows the sender to inform all recipients that the message will either have special handling imposed by Exchange itself or that the message should be handled in a certain way by the recipient.

As shipped, only two message classifications are available without installing additional software (such as Rights Management Server) or the administrator adding additional classifications. These two classifications are “No Restrictions” and “Message Expires After…” In Outlook 2007 and Outlook 2010, there are two additional items listed; one for “Do Not Forward” and the other for “Restrict Permission As…” (which is called “Manage Permissions” in Outlook 2010, although that could change before the Outlook 2010 is finally released). However, these two additional items require Rights Management Server to either be installed locally, or for the sender and receiver to have signed up for a “free” Microsoft service known as the Information Rights Management Service via a Live ID.

Message classifications can be manipulated by Transport Rules. That is, message classifications can be added, deleted, and/or required for sending to certain destinations by a transport rule. Message classifications are manipulated by the Exchange management Shell (created, deleted, and modified). They not only have names, but they also have priorities and precedence and descriptive text that must be assigned to each classification.

The primary enhancement to message classifications in Exchange Server 2010 was to simplify the process for making new classifications available to end-users.

A common usage for message classifications would be to mark a message as “Attorney/Client Privileged”. This is illustrated by Figure 1.


Figure 1: Illustrating Message Classifications

Managed folders were introduced in Exchange Server 2007 and have continued, unchanged, in Exchange Server 2010. They are significant in that they represent version 1 of what Microsoft refers to as Messaging Records Management. Truth be told, they are at least version 3, given that Mailbox Manager was available in Exchange Server 5.x, as well as Exchange Server 2000/2003. However, managed folders are carried forward in Exchange Server 2010 primarily for backwards compatibility with Exchange Server 2007. Moving forward, Microsoft recommends using Retention Policies (discussed in the next section).

Managed folders provide a mechanism for classifying message disposition. That is, what happens to messages that reside in a user’s mailbox, based on a given policy? For many companies, this is a key part of their compliance policies. A specific example may include “all messages older than 1 year are to be deleted”. Or “all items in the Deleted Items folder for more than 2 weeks are to be deleted”. Or “nothing may ever be permanently deleted”. The deployment of these capabilities is very much a matter of enforcing a given companies policies associated with data retention. Or, in the case of the Deleted Items folder, keeping user’s mailboxes to a reasonable size!

A managed folder mailbox policy consists of a list of managed content settings. A managed content setting is a folder (either a default folder or a custom folder), an optional message class (e.g., mail message, contact item, calendar item) and a disposition (which may include journaling, removal, movement to a custom folder, and other actions). Exchange ensures that when a policy includes multiple managed content settings that they do not conflict with each other in any way.

Please note that managed folders are not an archiving solution, as the managed content mailbox policies will not examine all items processed by Exchange for a mailbox. Managed folders are simply another facet of a company’s overall policies for Information Lifecycle Management.

Also, when comparing managed folders (MRM v1) to retention policies (MRM v2) always remember that managed folders are folder based. All items of a given message class in a folder are subject to the managed content setting defined for that folder.  Similarly, to change the policy applied to a given message requires only that the message be moved to a folder which has a different policy.

Managed folders support two kinds of folders: default folders (those present by default in all mailboxes) and custom folders (those identified by the administrator that will be created in mailboxes subject to a policy that defines them). The default folders meet many uses. The default folders are:

Calendar                                            Contacts
 Deleted Items                                   Drafts
(Entire Mailbox)                                 Inbox
Journal                                               Junk E-mail
Notes                                                  Outbox
RSS Feeds                                        Sent Items
Sync Issues                                       Tasks

The message classes that are understood by managed folders are as follows:

All Content                                         Calendar Items
Documents                                        E-mail
Meetings                                             Missed Calls
Posts                                                   RSS Items
Voice Mail                                           Journal Items
Contacts                                             Faxes
Notes                                                  Tasks

You can have many managed content settings for any default folder, but only a single managed content setting that affects a particular default folder and a particular message class in a managed folder mailbox policy.

If, in your managed folder policy, you have a need to use any folder that is not in the default folder list above, then you must create a custom folder. Any user who has a custom folder must be assigned an Exchange Server Enterprise CAL. Typical uses for custom folders include project based or customer based policies (e.g., end-users are required to move all messages from a customer into a folder named for that customer).

It is important for the administrator to name the folders within managed content settings appropriately and to include relevant descriptions that are informative to your users (during the process of creating a managed content setting, the administrator can supply descriptive text that is shown in both OWA and in Outlook when the folder name is hovered-over). Confusing names can confuse your users! An extreme example might be to provide a description for a user’s Inbox of “Delete-after-365” which is confusing on several levels. See Figure 2 for an example.


Figure 2: A managed folder policy description

You may only have one instance of any default folder in any managed content setting. That is, Goethe may have his Deleted Items managed content settings (named “Deleted Items-180”) and Ilse may have her Deleted Items content settings (named “Deleted Items-365”), but neither can have both at the same time.

A special feature available only to managed custom folders is that their size can be limited by the managed content settings. This capability is not available for managed default folders.

Retention Policies

Retention policies are Microsoft’s next attempt at defining message retention capabilities within Exchange Server. Similar to message classifications, retention policies are administrator defined, but user driven. Specifically, this means that the administrator defines the available retention tags and the user assigns those retention tags to messages, as the user desires.

Note that a retention tag is the end-user visible component of a retention policy. You may have only one of a Managed Folder Mailbox Policy or a Retention Policy assigned to a mailbox. You may not have both.

However, unlike managed folders, retention policies must be managed from the Exchange Management Shell (at least at the initial release of Exchange Server 2010, this may change with a future service pack). Also, while the documentation states that a default retention policy (and therefore a default retention tag) can be assigned to any of the default folders (which were listed in the prior section) by an Exchange administrator, this doesn’t work at the initial release of Exchange Server 2010 (this is a product defect, which may be corrected in a future update to Exchange Server 2010). And finally, default retention policies assigned by the administrator cannot (after the above item is corrected) differ based on the message class of a given item.

That is, within a default retention policy, you cannot have different types of messages (e.g., e-mail, calendar, voicemail, contact) with a different retention policy. The default retention policy for a folder will apply to all messages, which do not have a user-specified retention tag assigned to them, in that folder.

This author is of the opinion that retention policies are actually a step backwards from managed folders (and I have expressed that opinion to a number of folks on the Exchange Product Team) due to the lack of administrative control based on the message type within a given folder. However, if your organization needs per-message classifications and needs to allow individual users to assign those classifications on a per-message basis, then retention policies are a much better fit for your organization than managed folders.

Retention policies require that the end-user be using either Outlook 2010 (or above) or Outlook Web App 2010 (or above), to provide access and visibility to the retention policies. To assign the proper retention policy (tag), the user simply should right click on the message and choose the appropriate retention tag that should apply to the message.

With the exception of per-message assignation and the lack of message type isolation, all of the information associated with managed folder in the prior section also applies to retention policies. And, it is worthwhile to raise the question as to whether managed folders will be present in the next version of Exchange Server that follows Exchange Server 2010. It is likely that customers should migrate to retention policies – at least whatever capabilities of them are available within the next service pack of Exchange Server 2010.

Managed folders and retention policies are both stored within Active Directory, within the configuration container of the Active Directory forest (as are most configuration items that affect Exchange Server). For managed folders, the two primary containers are the ELC Mailbox Policies container and the ELC Folders container (where ELC stands for “E-mail Lifecycle”). For retention policies, the two primary containers are the Retention Policies container and the Retention Policies Tag container.

Transport rules were present in the initial release of Exchange Server 2007; however, many of the capabilities associated with transport rules were only available on Edge Transport servers and could not be used on Hub Transport servers.  With Exchange Server 2010, those restrictions are gone, and all of the transport rule options (plus a number of new options provided within Exchange Server 2010) are available on a Hub Transport server as well as on an Edge Transport server.

Transport rules allow the inspection and control of the following message types:

  • Internet messages
  • Person-to-person messages (internal and external)
  • Opaque e-mail (messages that are encrypted, and the server only has access to the message headers)
  • Signed messages
  • Unified Messaging messages (primarily voicemail)
  • Message read and message delivered reports
  • IPM.Note messages (custom forms)

All transport rules consist of three items. The items are:

  • Conditions
  • Exceptions
  • Actions

Now, conditions and exceptions are composed of “predicates”. That sounds complicated, but it really isn’t. Predicate is a fancy word for an “if statement”. So, a condition is satisfied if the condition returns “true” for a given “if statement”. Similarly, an exception is satisfied if the exception returns “true” for its “if statement”.

Long story short, an action occurs if a condition returns “true” (that is, the condition is satisfied) and the exception returns “false” (that is, the exception, if present, is not satisfied). What can you do with transport rules? Lots of stuff! This includes:

  • Based on content (including basic regular expressions) you can stop messages from entering or leaving the Exchange organization
  • You can track (copy) and/or archive messages that come from, or are destined to, specific internal or external addresses or distribution groups
  • Based on content or sender or recipient you can redirect messages to a different destination to either be approved for delivery or discarded
  • For all messages, just internal messages, or just external messages you can apply disclaimers (text or HTML) to the end of messages
  • Sign messages
  • Encrypt and/or decrypt messages
  • Apply Rights Management Services restrictions to messages

A common use for transport rules is to create “Chinese walls” within an organization. That is, prevent certain departments or certain individuals from communicating with each other. This is typically done to ensure that certain sensitive information (such as the contents of Security and Exchange Commission filings) is not leaked early or inappropriately.

Discovery Search

Discovery search is a new feature in Exchange Server 2010 and displays many of the immaturities one might expect in a version 1 product. Discovery search is based on the normal Exchange Server full-text search, including all of the filters (such a Microsoft Word, Microsoft Excel, etc.) that are registered on the searching mailbox server.

Individuals performing searches require explicitly granted permissions in order to perform a discovery search. By default, Exchange Administrators and Domain Administrators cannot perform discovery searches (in fact, by default no one can perform a discovery search). If Role Based Access Control (RBAC) is not enabled, then members of the “Discovery Management” Microsoft Exchange Security Group can perform a discovery search on all mailboxes within an Exchange organization. Using RBAC provides for more granular control for discovery searches.

Note that a member of the “Discovery Management” group also has the capability of putting a mailbox under legal hold. A mailbox in legal hold will never actually have any items deleted and all item changes are stored in the mailbox.

Discovery searches are initiated from the Exchange Control Panel (ECP) area of the Outlook Web App (OWA). Only individuals who are authorized to perform a discovery search will see the option for performing a discovery search. See Figure 3.


Figure 3: Discovery Search dialog in OWA

A discovery search is a batch mode operation. When the user creates a discovery search, they specify:

  • The words to be searched for (including Boolean expressions built with AND, OR, or NOT)

  • Multi-word phrases
  • Simplistic wildcards (words ending with “*”, but no general regular expressions)
  • The mailboxes to be searched
  • The message types (discussed earlier in this article) to be searched
  • Whether to consider specific messages either to/from specific e-mail addresses
  • Whether to consider messages within a specific date range
  • What subfolder to use within the discovery mailbox to store the results of this search (this is also the overall name of this specific search)

All output from a discovery search goes to a specific discovery mailbox. There are no other output options. Within the discovery mailbox, a folder is created based on the name of the discovery search. Within that folder, each mailbox included within the search has its own subfolder. Exchange sends an e-mail to the creator of the search once the search is complete and all results are stored within the discovery mailbox.

After the results of the discovery search are no longer necessary, delete the search to remove the subfolder from the discovery mailbox and all of the subsidiary contents. Note that searches which use common words and phrases can consume significant resources and provide far more results than are anticipated. A discovery search does provide the capability of modifying the search once the search is complete. The normal process for a discovery search is as follows:

  • Create a search
  • Allow Exchange server to execute the search
  • Receive notification that a search is complete
  • Review search results
  • Optionally modify the search
  • Remove the search (which also removes the results of the search from the discovery mailbox)

A discovery search can be arbitrarily complex within the supported predicates and options. However, those are fairly limited. Of course, you can construct more granular searches from within the Exchange Management Shell. However, that will likely be an administrator-only experience; you will probably require your users to utilize the ECP.

User Archive Mailbox

The final new feature within Exchange Server 2010 that we will discuss is the user archive mailbox. The archive mailbox is basically a second mailbox for any user who has one. The intention with the user archive mailbox, along with the complete removal of storage restrictions associated with mailbox database sizes in Exchange Server 2010, is to allow organizations to eliminate PSTs from their environments.

In Exchange Server 2010, given that a company is using Database Availability Groups (DAGs) with at least two copies, Microsoft says that mailbox database sizes up to 2 TB are acceptable, with mailbox database sizes up to 64 TB being supported (note that this is the size limit of a file within the NTFS file system, and a mailbox database is eventually nothing more than a special type of an NTFS file). Along with this significant change in mailbox database size support, Microsoft now supports (and in fact, recommends as long as there are at least two DAG copies) the use of inexpensive SATA disk for mailbox databases.

Given this support, Microsoft is of the opinion that companies will immediately move from expensive SAN storage to inexpensive SATA disk. This author has already seen that that isn’t the case. Many companies want to retain primary mailbox storage on SAN (given the investment they’ve already made in SAN storage and SAN management).

However, in the initial release of Exchange Server 2010, an archive mailbox is located in the same mailbox database as a user’s primary mailbox. This limits the deployment of archive mailboxes to companies who either have SAN storage to allocate to archive mailboxes (likely very few) or to companies who will fully commit to the Microsoft recommendations of inexpensive SATA storage in the initial release (this is also likely to be very few companies).

The contents of archive mailboxes are also not available to users in cached mode. That is, the contents of the archive mailbox are not copied to the user’s OST. Also, in order to view the archive mailbox, a user must be using either OWA 2010 or Outlook 2010 (in online mode). Given that desktop deployment cycles tend to be out-of-sync with server deployment cycles, this can also serve as a significant blocker to the deployment of archive mailboxes.

A MoveToArchive action is available for retention policies, but is not available for managed folder mailbox policies (in fact, you cannot create a user archive on a mailbox which has a managed folder mailbox policy assigned to it). Archive mailboxes are subject to discovery search and to legal hold. Archive mailboxes are subject to separate quotas from primary user mailboxes.


Exchange Server 2010 includes many new features that are oriented toward improving the compliance feature-set of Exchange Server, as well as continuing to provide support for some existing compliance features that were introduced with Exchange Server 2007.

Unfortunately, a number of the new features are not particular easy to use, and some of those introduced in Exchange Server 2010 actually remove feature content from features present in Exchange Server 2007 and before.

The security configuration required for controlling these compliance features is fairly complex, and requires Role Based Access Control for any type of granular control.

The discovery search, a much anticipated new feature of Exchange Server 2010, lacks a number of features necessary for any typical eDiscovery process.

So, while the work done in Exchange Server 2010 is a step in the right direction, and may be suitable for the smallest of companies; it is very likely that medium and large companies will need a more complete solution to meet their compliance requirements.