Managing Compliance in Microsoft Exchange Server 2010

  • 11/24/2010

Messaging records management

Exchange 2007 introduced the messaging records management (MRM) system as its “business email” strategy to help users comply with regulatory and legal requirements. The idea is to provide a method for users to retain messages and attachments that are required business records. Another way of thinking about MRM is that it helps users keep control over mailboxes by automating the retention process; marked items are kept as long as required, whereas others can be automatically discarded when their retention period (otherwise known as the expiration limit) expires.

The key to success for any scheme that aims to alter user behavior is to make it as simple as possible while achieving maximum functionality. Exchange 2007 didn’t quite meet this goal. Its version of MRM uses a set of managed folders that have policies attached to them. The folders can be one of the default mail folders (Inbox, Sent Items, and so on) or a specially created folder that can be used to store items that the business wishes to control. The Managed Folder Assistant (MFA) is responsible for the application of the policies attached to the folders. The MFA runs on a regular basis to process items in managed folders. Items are stamped with the retention policy that applies to the folder, and this dictates what happens to the items in the future. For example, if a policy is set on the Inbox to delete any item older than 60 days, the MFA will move items older than this limit to the Deleted Items folder.

Exchange 2007 MRM works if users are disciplined in their filing habits and understand the concept of managed folders. Some people like the structure imposed by managed folders because it creates a structured approach to work. The problem is that the vast majority of Exchange users are relatively undisciplined when it comes to filing, and they do not wish to spend time moving items around unless it’s necessary to delete items or move them into a PST to get their mailbox size under quota so that they can send or receive new messages. Indeed, the radically better search facilities that are available in recent versions of Exchange and Outlook encourage users never to refile anything because they can always search for an item when required. In addition, Exchange is able to handle very large folders that hold tens of thousands of items, so the imperative to refile items to achieve acceptable performance does not exist. The combination of human nature and better software conspired to make Exchange 2007 MRM ineffective in real terms. Microsoft therefore needed to change its tactics to provide a workable implementation of MRM for Exchange 2010.

The new approach to messaging records management in Exchange 2010

Managed folders persist in Exchange 2010, but only for backward compatibility. The future of Exchange-based MRM lies in a structure created by retention tags and policies. Retention tags can be applied to any item in any folder to specify what action Exchange should take for the item when its retention period expires. Supported actions include the hard (permanent) or soft (recoverable) deletion of the item, moving the item to a personal archive, or flagging the item for user attention. Retention policies group retention tags together in a convenient manner to allow administrators to apply policies to mailboxes rather than having to assign individual retention tags to folders. Retention tags and policies are organization-wide objects that are stored in Active Directory and can therefore be applied to any mailbox in the organization after they are created. Just like Exchange 2007, the MFA is responsible for checking mailbox contents against policy and taking whatever action is determined by policy for items that exceed their retention period.

This all sounds like a workable solution. The only issue is that Microsoft didn’t ship any GUI to allow administrators to set up and manage retention tags and policies in the RTM release of Exchange 2010. Instead, you have to perform all management of retention tags and policies through EMS until you deploy Exchange 2010 SP1, which includes the necessary GUI in its version of EMC. In addition, Exchange 2010 SP1 includes a set of retention and archive tags such as “1 Month Delete” (items stamped with this tag are moved into the Deleted Items folder after one month) that you can use as a starting point to develop your own retention policies.

Types of retention tags

Table 15-2 describes the three types of retention tags supported by Exchange 2010. The “type” shown in the third column is a value passed to the –Type parameter when you create a new tag with the New-RetentionPolicyTag cmdlet. Exchange uses this value to understand the scope of the items in a user mailbox to which it can apply the tag.

Table 15-2. Types of retention tags

Tag type



Retention policy tags (RPT)

Administrators can apply these tags to default mailbox folders such as the Inbox, Sent Items, and Deleted Items. In Exchange 2010 SP1, tags cannot be applied to the Tasks and Contacts folders.

If an RPT is assigned to a default folder, all items in the folder automatically come under the control of the tag unless the user applies a personal tag to the item. Only one RPT can be assigned per default folder.










Default policy tags (DPT)

A catch-all tag that the MFA applies to any item that does not inherit a tag from its parent folder or has not had a tag explicitly applied to it by the user. In other words, if no other tag applies to an item, Exchange will respect the instructions contained in the default tag. A retention policy only includes a single DPT that is used to delete items; you can specify another to control the default movement of items into the personal archive. It’s logical but sometimes overlooked that if you specify two DPTs in a policy, the tag that moves items into the archive must have a shorter retention period than the tag that deletes items.


Personal tags

Users can apply these tags to nondefault folders and individual items in a mailbox. Personal tags that move items into the archive can also be applied to default folders.

Personal tags mark an item with an explicit retention, usually to comply with a business requirement. For example, you might use an “Audit” tag to mark items that users are compelled to retain for audit purposes. A retention policy can include many different personal tags.


You’ll notice that some default folders that you expect to find in every mailbox are excluded from the list of folders that support retention policy tags. The RTM version of Exchange 2010 doesn’t allow retention policy tags to be applied to the Calendar, Contacts, Journal, Notes, and Tasks folders. However, items in these folders were covered by the default retention policy and so could be removed unexpectedly.

Overall, the set of default folders covered by Exchange 2010 SP1 is much broader than before and includes those where items often accumulate without users noticing, such as the Sync Issues and RSS Feeds folders, so you can now create and apply retention tags that clear out these folders for users automatically. You can see the list of folders for which you can create retention policy tags in Exchange 2010 SP1 in Figure 15-6. The All Other Folders In The Mailbox choice is used when you create a default policy tag.

Figure 15-6

Figure 15-6 Listing of folders for which you can create retention policy tags.

Retention tags cannot be applied to items directly. They first have to be assigned to a retention policy and the retention policy assigned, in turn, to the mailboxes that you want to manage. A retention tag can be reused several times in different policies. Although there is no practical limit to the number of retention tags that you can define for an organization, it makes sense to create a set of tags that can be shared and reused between retention policies rather than creating separate tags for each policy.

Exchange can only apply one retention policy tag and one archive tag to an item. Two simple rules are used when Exchange evaluates policies that it can apply to an item. The first rule states that the policy with the longest retention period always wins and is intended to ensure that Exchange never deletes an item before its time truly expires. The second rule is that an explicit policy is always respected ahead of an implicit or default policy. In other words, if you apply a personal tag to an item to retain it for six years and the default retention policy for the folder requires deletion after 12 months, the item will be kept for six years. Retention tags can be placed on items, conversations, or complete folders, and they are transferred with items if you move them between folders.

Of course, to make any sense of retention policies, you also need to deploy clients that include the necessary intelligence and user interface. At the time of writing, the only clients in this category are Outlook 2010 and Outlook Web App. As we’ll see when we review how retention policies function from a user perspective, Outlook’s user interface provides the richest views of retention policies and tags. Outlook Web App is less capable, but still highly usable.

System tags

Exchange 2010 supports two types of retention tags: system tags and nonsystem tags. System tags are used by Exchange for its own purposes and are not shown when you run the Get-RetentionPolicyTag cmdlet unless you specify the –IncludeSystemTags parameter. By default, Get-RetentionPolicyTag only lists nonsystem tags (those created to be used with normal retention policies). To see the system tags defined in an organization, you can execute this command (nonsystem tags will be listed afterward):

Get-RetentionPolicyTag -IncludeSystemTags | Format-Table Name, Type, SystemTag
Name                                      Type                   SystemTag
-------                                   ------                 ---------
AutoGroup                                 Personal               True
ModeratedRecipients                       Personal               True
Personal 1 Year move to archive           Personal               False
Default 2 year move to archive            All                    False
Personal 5 year move to archive           Personal               False
Personal never move to archive            Personal               False

The first two entries (AutoGroup and ModeratedRecipients) are system tags that are used by Exchange to prevent items from accumulating in arbitration mailboxes. The tags instruct the MFA to clean out these mailboxes as items expire. To see details of the retention policy used for arbitration mailboxes and its links to the two system tags, run these commands:

Get-RetentionPolicy -Identity 'ArbitrationMailbox'
Get-RetentionPolicyTag -Identity 'AutoGroup'
Get-RetentionPolicyTag -Identity 'ModeratedRecipients'

The last four entries are nonsystem tags that belong to the Default Archive and Retention Policy. Exchange automatically applies this policy after a personal archive is enabled for a mailbox. The idea is to provide a set of tags to allow users to control how items are moved into the archive. The tags are revealed by clients after the user’s mailbox is processed by the next run of the MFA. The default archive policy is replaced when another retention policy is applied to a mailbox.

Designing a retention policy

Many different retention policy tags can exist within an organization. This allows great flexibility in creating appropriate policies for different groups that work within a company. For example, the finance department might want Exchange to permanently delete everything in the Deleted Items folder more than three days old (the shred principle), whereas users in other departments are not concerned if items survive in the Deleted Items folder for 30 days or more. You can apply a retention policy to members of the finance department that includes a retention policy tag for the Deleted Items folder that instructs the MFA to remove items after three days. The same policy might include a personal tag that allows members of the finance department to mark items that have to be archived for audit purposes after a month in the primary mailbox. The MFA will move items with this tag to the archive mailbox when it processes the mailbox.

The design for a retention policy might be captured in a simple table format that makes it clear what tags are included in the policy, their purpose, and the folders that are processed by the MFA. Apart from its other advantages, capturing the design like this makes it easier to communicate the policy to users. Table 15-3 lays out a simple policy that could be applied to help managers cope with overloaded mailboxes.

Table 15-3. Laying out a retention policy

Retention Policy Name:

Management retention policy

Applies to:

Mailboxes with CustomAttribute7 = “Management”

General purpose:

Automatic clean-out of Inbox and Sent Items folders to encourage users to keep these folders tidy. Items in all other folders can remain in place for a year. Removal of items from the Deleted Items folder after a week and permanent removal of anything filed into the Junk Mail folder after two days. A tag is provided to allow users to mark items for retention for five years.

Tag name

Tag type

Applies to




Inbox folder

Move items to Recoverable Items after 30 days



Sent Items

Move items to Recoverable Items after 30 days



Deleted Items

Permanently remove items after 7 days



Junk Mail

Permanently remove items after 3 days



All folders

Move items to Recoverable Items after 365 days



All folders

Move items to Recoverable Items after 1,825 days (5 years)

Logically, you can only have a single RPT for each default folder within a retention policy. It would be very confusing to have two retention policies compete within a single folder! In addition, a retention policy can only have one default retention policy that applies to all folders.

Exchange uses the date and time when an item is created in a user’s mailbox as the baseline to calculate the age of the item for retention purposes, so an age limit of 30 days for the Inbox default retention tag essentially means that items become eligible for processing by the MFA 30 days after they are delivered into the Inbox. The creation date is used for retention purposes even for modifiable items such as posts. You can create a tag to mark items never to be processed by the MFA. Such a tag will have no value set for its AgeLimitForRetention property, and its RetentionEnabled property will be set to $False.

The MFA is responsible for implementing the actions specified in retention and archive tags when it processes a mailbox. For example, if the retention period for the Inbox is 30 days, the MFA will tag any item aged up to 30 days and take the specified action for items aged 30 days. Therefore, before you implement a policy that potentially will affect thousands of items in user mailboxes, it is critical to clearly communicate what is going to happen, when it will happen, and how users can prepare for the implementation of the retention policy and respond to its actions afterward. You might have to communicate several times before the retention policies are implemented to avoid a deluge of calls to the help desk the morning after the MFA runs.

Naming retention tags

The tags described in the example management retention policy that we created follow a specific naming scheme. Retention policy tags are prefixed with “RPT,” default policy tags are prefixed with “DPT,” and personal tags are prefixed with “PER.” The tag name is then completed with some text to convey its meaning and to associate it with the retention policy where it is used. Thus, DPT-General makes sense in an administrative sense because the name conveys that the tag is a default policy tag used generally across the organization. Of course, the last sentence means nothing to end users, especially if they have never coded and have not been exposed to the cryptic (but always logical) naming schemes beloved by programmers.

The problem that has to be solved when you determine a tag naming scheme is that the retention policy menu displayed by Outlook 2010 and Outlook Web App lists tag names and their retention period (such as “6 months”) to end users but doesn’t display any other detail such as the action that will be taken when the tag’s retention period expires. Tags can have a variety of associated actions, from permanent deletion to merely warning that the retention period has expired. Outlook 2010 users can view the actions for the default tag on a folder by viewing the folder properties, but this information is not available to Outlook Web App, and they are the only two clients that expose retention tags today. It can be argued that the tags used in an archive policy and displayed in the archive menu are an exception because users should know that the purpose of these tags is to move items into the personal archive when their retention period expires, but that’s still no reason to use cryptic tag names.

The question, therefore, has to be asked whether you should use a more user-friendly naming scheme for retention tags. For example, would “RPT-Inbox” be better named “Inbox retention policy” and should “PER-Retain” be called “Retain for five years”? Some prefer the structure of the first approach, but users probably find the second approach easier to understand.

Another approach that is often taken is to use names that give clear business directives for retention tags. For example, you might use names such as these:

  • Business Critical

  • Partner Negotiations

  • Legal Retention

Tags named like this are usually more specific to departments or groups than more generic names such as “Keep for five years” or “Required for Annual Audit,” so you might end up defining a set of retention tags for each department to match their work practices.

It’s impossible to give a definitive answer about a naming convention that is suitable for all deployments. Some organizations are happy with cryptic tags because they are a standard that is valid no matter what language is used to connect to Exchange; others will elect to use more user-friendly names because it’s easier to communicate the purpose of a retention policy to users and they feel that this will both ease the introduction of retention policies within the organization and avoid some calls to the help desk. The important thing is to make a decision before you start to design and implement retention policies, as changing the names of tags halfway through a deployment is guaranteed to cause maximum confusion.

Creating retention tags

Retention tags can only be created using EMS with Exchange 2010 RTM. With SP1, you have the choice of working with EMC or EMS. EMC is easier to deal with, so we’ll begin with it. Under Organization Configuration, go to the Mailbox section and select the New Retention Tag option to launch the New Retention Policy Tag Wizard. As you can see from Figure 15-7, this wizard is very straightforward, and all we need to do is input the settings laid out for each tag in the policy described previously in Table 15-3.

Figure 15-7

Figure 15-7 Creating a new retention policy tag.

After creating all of the retention policy tags that we need, we should end up with something like the situation illustrated in Figure 15-8. This is the complete set of the retention policy tags defined for the organization, and you can immediately see the advantage of following a well-thought-out naming convention for tags, as this set contains both structured and free-form names. In addition, you can see how it is possible to quickly accumulate a large number of tags that are used by different retention policies in an organization. With some forethought, it is possible to reduce the total number of tags by designing some utility tags that are included in every policy, which then means that the only additional tags that you need to define are those specifically required by a policy. For example, you can probably define utility tags to clean out folders such as Junk E-Mail and RSS Feeds that apply the same retention period and action for every policy. You might not be as successful in defining utility tags for default folders, such as the Inbox or Sent Items, as different sets of users might need to keep items in these folders for different periods.

Figure 15-8

Figure 15-8 Viewing the set of retention policy tags defined for the organization.

As an example of how to accomplish the same task with EMS, let’s create the four retention policy tags for the Inbox, Sent Items, Junk Mail, and Deleted Items folders.

New-RetentionPolicyTag -Name 'RPT-Inbox' -RetentionAction DeleteAndAllowRecovery
30 -Type Inbox -Comment 'Inbox items are automatically deleted after 30 days'
-RetentionEnabled $True

New-RetentionPolicyTag -Name 'RPT-SentItems' -RetentionAction DeleteAndAllowRecovery
-AgeLimitForRetention 30 -Type SentItems -Comment 'Sent Items are deleted
after 30 days' -RetentionEnabled $True

New-RetentionPolicyTag -Name 'RPT-JunkMail' -RetentionAction PermanentlyDelete
-AgeLimitForRetention 2 -Type JunkEmail -Comment 'All junk mail is permanently
removed after two days'
 -RetentionEnabled $True

New-RetentionPolicyTag -Name 'RPT-Deleted' -RetentionAction DeleteAndAllowRecovery
-AgeLimitForRetention 7 -Type DeletedItems -Comment 'Deleted Items are removed after
7 days; they can be recovered if necessary'     -RetentionEnabled $True

We can check the properties of our new retention tags with the Get-RetentionPolicyTag cmdlet. For example:

Get-RetentionPolicyTag -Identity 'RPT-Inbox' | Format-List
IsPrimary                            : False
MessageClassDisplayName              : All Mailbox Content
MessageClass                         : *
Description                          : Managed Content Settings
RetentionEnabled                     : True
RetentionAction                      : DeleteAndAllowRecovery
AgeLimitForRetention                 : 30.00:00:00
MoveToDestinationFolder              :
TriggerForRetention                  : WhenDelivered
MessageFormatForJournaling           : UseTnef
JournalingEnabled                    : False
AddressForJournaling                 :
LabelForJournaling                   :
Type                                 : Inbox
SystemTag                            : False
LocalizedRetentionPolicyTagName      : {}
Comment                              : Inbox items are automatically deleted after 30 days
LocalizedComment                     : {}
MustDisplayCommentEnabled            : False
LegacyManagedFolder                  :
AdminDisplayName                     :
Name                                 : RPT-Inbox
Identity                             : RPT-Inbox

The output from Get-RetentionPolicyTag confirms that the tag can cover any class of item (MessageClass = *, the default for Exchange 2010), that it is for the Inbox folder (Type = Inbox), and that items tagged with this RPT will be moved to the Deleted Items folder after 30 days (indicated in the RetentionAction and AgeLimitForRetention properties). In fact, unlike managed folders, retention tags don’t accommodate the notion of item segregation. In other words, you cannot build a retention tag that only applies to items of a certain class in a folder (such as apply the policy to items of class IPM.Note but ignore those of class IPM.Contact).

Let’s now create the other tags that are required for the management retention policy. This time a personal tag (type = personal) is needed to allow users to mark items to be kept in their mailbox for five years (1,825 days), after which the items will be automatically moved into the Recoverable Items folder. Exchange gives the action and retention period defined in a personal tag priority if a user applies it to an item in a folder that’s already under the control of a retention policy tag. In other words, if a user applies the PER-Retain tag on an item in the Inbox, Exchange will not move it to the Recoverable Items folder after 30 days as called for by the retention policy tag associated with the Inbox. Instead, Exchange will respect the action and retention period defined in the personal tag because the rule is that an explicit policy always trumps an implicit policy. In addition, you should also remember that Exchange will keep a personal tag on an item even if the item moves to another folder that has an associated retention policy tag.

We create the new personal tag with the following command:

New-RetentionPolicyTag -Name 'PER-Retain' -RetentionAction PermanentlyDelete
-RetentionEnabled $True -AgeLimitForRetention 1825 -Type Personal -Comment 'Item to
be kept forfive years before it is moved to Recoverable Items'

Setting the Type parameter to Personal is the critical thing here because it makes the tag personal and explicit rather than the implicit tags applied to all items in a folder. To create a personal tag with EMC, select Personal Folder as the tag type.

To complete the design, the policy needs to provide managers with a default retention tag that forces any items older than a year (365 days) to be moved into the Recoverable Items folder. As you’ll recall, a default tag is used when no other tag has been applied to an item.

New-RetentionPolicyTag -Name 'DPT-General' -RetentionAction DeleteAndAllowRecovery
-RetentionEnabled $True -AgeLimitForRetention 365 -Type All -Comment 'Items older
than a year are moved to Recoverable Items unless otherwise tagged'

You’ll have noticed that all of the tags that we created specify –RetentionEnabled $True. This means that the tag is active and should be processed by the MFA. To disable a tag, you set –RetentionEnabled $False. A tag in this state is ignored by the MFA.

Most of the tags that we have created so far use the DeleteAndAllowRecovery action. The other actions are as follows:

  • PermanentlyDelete Immediately deletes the item in such a way that it cannot be seen using the Recover Deleted Items option. If the mailbox is on retention or litigation hold, the item is retained and still available to discovery searches.

  • MoveToArchive Moves the item to a folder of the same name in an archive mailbox. Clearly this action is only possible if the mailbox has a personal archive. If not, the action is ignored. Moving to the archive is analogous to the Outlook Auto-Archive option that moves items into a PST on a regular schedule to help keep a mailbox under quota. The big difference is that users don’t get to vote whether they want to use the option, as Exchange moves items into the personal archive automatically without asking for user opinion. Policies that move items into an archive mailbox are known as archive policies. Exchange will ignore the archive tags if you create a retention policy that includes tags to move items into the archive and apply it to a mailbox that doesn’t have a personal archive. If the mailbox is subsequently assigned a personal archive, the MFA will apply the archive tags for the mailbox the next time that it runs.

To check that we have all of the required tags in place to build the retention policy, we can review the set of tags through EMC or execute the following EMS command:

Get-RetentionPolicyTag | Format-Table Name, Type, RetentionAction, RetentionEnabled,
AgeLimitForRetention -AutoSize
Name            Type         RetentionAction          RetentionEnabled    AgeLimitForRetention
--------        ------       --------------           --------------      -----------------
RPT-Inbox       Inbox         DeleteAndAllowRecovery  True                30.00:00:00
RPT-SentItems   SentItems     DeleteAndAllowRecovery                      30.00:00:00
RPT-JunkMail    JunkEmail     PermanentlyDelete       True      
RPT-Deleted     DeletedItems  PermanentlyDelete       True                7.00:00:00
PER-Retain      Personal      DeleteAndAllowRecovery  True                1825.00:00:00
DPT-General     All           DeleteAndAllowRecovery  True                365.00:00:00

All seems correct in this case, but if you make a mistake, you can remove a retention policy tag with the Remove-RetentionPolicyTag cmdlet. If the tag has already been applied to mailbox items, the MFA will clean up by removing any reference to the removed tag from items as it processes mailboxes.

Creating a retention policy

Now that we have created the necessary retention tags to help managers impose order on their mailboxes, we can proceed to create a new retention policy. In EMC, under Organization Configuration in the Mailbox section, select the New Retention Policy option to launch a wizard to help guide us through the process. We have two tasks to accomplish:

  1. Select and add the retention tags that we want to include in the new policy. Figure 15-9 shows that the six tags that we created have been selected for inclusion in the new policy.

  2. Select the mailboxes that we want to apply the new retention policy to after it is created (Figure 15-10). This is an optional step, and you are not required to select any mailboxes now. A retention policy can be added to mailboxes at any time after it is defined.

Figure 15-9

Figure 15-9 Creating a new retention policy with EMC.

Figure 15-9 illustrates a retention policy containing a number of tags that specify actions that have been removed in Exchange 2010 SP1. Microsoft no longer supports the use of the Move to the Deleted Items and Mark as Past Retention Limit actions. Although these actions are still respected by the MFA, they might cease to work in a future release of Exchange. The policy shown here was created with Exchange 2010 RTM and needs to be updated to use the set of retention actions available in SP1. It is possible that Microsoft will reintroduce a more expansive set of retention actions in a future version of Exchange.

Figure 15-10

Figure 15-10 Adding mailboxes to a new retention policy.

When you click Finish to complete the wizard, Exchange first reviews the set of retention policy tags that you have assigned to the policy to validate that you are not including multiple tags for the same folder.

Assuming that everything goes according to plan, Exchange will create the new retention policy and then apply it to any mailboxes that you selected. The MFA will stamp the tags defined in the retention policy on items in the mailboxes the next time that it processes the mailboxes.

Exchange 2010 only allows you to create retention policies through EMS using the New-RetentionPolicy cmdlet. In this command, we create the policy and associate the six tags that we want to use with the new policy.

New-RetentionPolicy -Name 'Management retention policy'
-RetentionPolicyTagLinks 'RPT-Inbox', 'RPT-SentItems', 'RPT-Deleted',
'PER-JunkMail','PER-Retain', 'DPT-General'

We can examine details of the new retention policy with the Get-RetentionPolicy cmdlet:

Get-RetentionPolicy -id 'Management retention policy'
RetentionPolicyTagLinks : {DPT-General, Per-retain, RPT-Deleted, RPT-SentItems, RPT-Inbox}
AdminDisplayName        :
ExchangeVersion         : 1.0 (
Name                    : Management retention policy
DistinguishedName       : CN=Management retention policy,CN=Retention Policies Container,
CN=contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Identity                : Management retention policy
ObjectClass             : {top, msExchRecipientTemplate, msExchMailboxRecipientTemplate}

A six-tag policy is a reasonably simple retention policy, as other policies can incorporate a lot more tags to create a very exact retention environment for a user to operate within. Obviously, you might have more tags than this if you decide to include a retention policy tag for every default folder. Using retention policy tags to clean out items that otherwise accumulate and are never cleared out in default folders such as Sync Issues, Junk E-Mail, and RSS Feeds is a good example of where you can gain real value from a well-designed retention policy. Figure 15-7, shown previously, is a good example of such a “good folder health” retention policy tag.

Applying a retention policy to mailboxes

The Set-Mailbox cmdlet is used to apply a retention policy to an existing mailbox. The New Mailbox Wizard available in the original release of Exchange 2010 does not allow you to set a retention policy on a mailbox when it is created, but this problem is addressed in the SP1 version. The policy becomes active the next time the MFA processes the mailbox. SP1 also allows you to select a retention policy from the Mailbox section of Organization Configuration and add one or more mailboxes to it. Because you can use the mailbox picker to browse and select from all the mailboxes in the organization, this is the easiest way to add a large number of mailboxes to a retention policy in one operation.

Set-Mailbox -Identity 'JSmith' -RetentionPolicy'Management retention policy'
-RetentionComment 'Management retention policy applies to this mailbox'

Exchange will warn you that clients earlier than Outlook 2007 don’t support retention policies. More correctly, this should be Outlook 2010. Of course, if you’re setting a policy for a group of users, you’ll probably do it in one operation by selecting the mailboxes with the Get-Mailbox cmdlet and piping the results to Set-Mailbox. For example:

Get-Mailbox -Filter {CustomAttribute7 -eq'Management'} | Set-Mailbox
-RetentionPolicy 'Management retention policy'
-RetentionComment 'Management retention policy applies to this mailbox'

The new policy will be applied to the mailboxes the next time that the MFA processes the mailboxes. See the section “How the Managed Folder Assistant implements retention policies” later in this chapter for more information about the processing performed by the MFA.

To discover the set of mailboxes that have retention policies in place, you can use a command like this:

Get-Mailbox -Filter {RetentionPolicy -ne $Null} | Format-Table Name, RetentionPolicy

Of course, after you begin to deploy retention policies to mailboxes, the question arises of how to integrate the assignment of retention policies with any user provisioning process that your company has in place. Exchange doesn’t have a default retention policy that can be assigned automatically, so an explicit administrative action is always required to allocate a retention policy to a mailbox. This action is not difficult to code with EMS, but it is something that needs to be considered as part of your deployment plan.

Modifying a retention policy

Policies can evolve over time by the addition or removal of tags. As we’ve discussed, you add multiple retention tags to a policy by separating the entry for each tag with a comma. You can add new tags to the policy afterward with the Set-RetentionPolicy cmdlet. To add a new tag, you need to include it in the full list of tags submitted to Set-RetentionPolicy in the –RetentionPolicyTagLinks parameter. It is not sufficient to merely specify the new tag on its own, as this will update the policy to only include the new tag.

You can use two approaches to including a new tag in a retention policy. The first approach is best for simple policies that only include a few tags and requires you to write the complete list of tags into the policy to overwrite the existing list. For example:

Set-RetentionPolicy -Identity 'Audit Department'
-RetentionPolicyTagLinks 'RPT-Audit-Inbox', 'RPT-Audit-SentItems'
Get-RetentionPolicy -Identity 'Audit Department'

The second approach is best when dealing with complex policies that have six or more tags, and the potential exists that you might forget to input one of the tags. RetentionPolicyTags is a multivalued property, so to add a new tag to an existing list, you first extract the existing tags into a variable, then add the new tag to the variable, and finally write the new set back into the policy. Here’s code that updates a complex policy with a new tag:

$TagList = (Get-RetentionPolicy -Identity
'Management Retention Policy').RetentionPolicyTagLinks
$NewTag = Get-RetentionPolicyTag -Identity 'Per-New-ArchivePolicy')
$TagList += $NewTag
Set-RetentionPolicy -Identity 'Management Retention Policy' -RetentionPolicyTagLinks
Get-RetentionPolicy -Identity 'Management RetentionPolicy' | Select Name,

The second approach requires a little more typing on the part of the administrator, but it absolutely guarantees that all existing tags are preserved.

To remove a tag from a policy, you have to write a replacement list into the policy as in the first approach previously described. If you remove a tag from a policy, users covered by the policy cannot apply the tag to any items to their mailbox, but existing items that have been stamped with the tag continue in place and will be processed by the MFA.

Customizing retention policies for specific mailboxes

You can tailor the retention policy for a specific user by assigning personal tags on a per-mailbox basis. This can only be done if a retention policy already applies to the user’s mailbox. For example, let’s assume that you want to assign a new personal tag to a user to allow him to mark an item to be moved into the archive after a year. You can do this as follows:

Set-RetentionPolicyTag -Mailbox JSmith -OptionalInMailbox 'Per-Move-Archive'

Exchange adds the optional tag to the set of tags covered in the retention policy that already applies to the mailbox and makes the expanded set available the next time that the user connects. Unfortunately, no cmdlet is available to report whether a mailbox has been assigned optional tags. If you examine a mailbox with Get-Mailbox, it tells you if a retention policy is assigned, but nothing else. Therefore, if you want to change the list of optional tags assigned to a mailbox, you have to write the complete list with Set-RetentionPolicyTag. For example, to add an additional tag to the one that has already been assigned, we use this command:

Set-RetentionPolicyTag -Mailbox JSmith -OptionalInMailbox 'Per-Move-Archive',

EMS doesn’t validate that the tags that you assign to a mailbox will be effective. For example, you can assign a new archive tag to a mailbox that doesn’t have a personal archive. This is really a null operation because neither Outlook Web App nor Outlook displays archive tags if the mailbox doesn’t have a personal archive.

To remove all optional retention tags from a mailbox, you set the list to $Null as follows:

Set-RetentionPolicyTag -Mailbox JSmith -OptionalInMailbox $Null

User interaction with retention policies

The first evidence that users see that their mailbox has been assigned a retention policy is when they see indications in message headers that start to appear 30 days before an item expires. These warnings are visible when a message is opened or shown in the message preview. Figure 15-13 shows how Outlook Web App advises that a message has 27 days before it expires as the result of a retention policy tag placed on the Inbox. The user now has the choice to either leave the message to expire, in which case the MFA will process whatever action is defined in the tag (Move to Deleted Items, Permanently Delete, and so on) or apply a different tag to the item.

Figure 15-13

Figure 15-13 Outlook Web App warns that an item is approaching its expiry deadline.

Users have two options to apply a different tag to an item in their Inbox. First, they can move the item to a different folder and so remove it from the influence of the retention policy tag that applies to Inbox items. After it is moved, the item is governed by the default policy tag defined in the retention policy that applies to the mailbox, if one exists, or by an explicit policy that is applied to the folder and therefore inherited by all items that are added to the folder. If neither of these conditions exists, the item is left untagged and therefore will not be subject to processing by the MFA.

The second option is to place an explicit tag on the item. Users can choose from any of the personal tags defined in the retention policy applied to their mailbox by right-clicking an item and then selecting the personal tag to apply. Figure 15-14 shows how Outlook 2010 (left) and Outlook Web App (right) display retention and archive tags included in a single retention policy in the list of options that can be taken for a message. If a tag specifies MoveToArchive as its action, clients list it under Archive Policy rather than Retention Policy. Logically, archive tags can only be used with mailboxes that have personal archives. Outlook provides a richer set of options, even if you can argue that Outlook Web App’s user interface is less confusing for the novice user. You won’t see the user interface for retention policies unless a policy is applied to your mailbox.

Figure 15-14

Figure 15-14 How Outlook and Outlook Web App display the list of available retention and archive tags.

After a personal tag has been applied to an item, the item is no longer subject to the provisions of either the folder policy or the default policy, as an explicit tag always takes precedence over a tag placed on a folder. The personal tag also remains with the item if it is moved to another folder or into the personal archive. If users want to impose a different retention policy on the item, they will have to replace the existing tag with a new personal tag.

Outlook keeps users updated about the retention policy that applies to an item by displaying details as part of the message header. The retention information displayed by Outlook 2010 when a message is read is shown in Figure 15-15. Users can see quite clearly how long it will be before the item expires, and they can also see details of the retention policy that is applied to the item.

Figure 15-15

Figure 15-15 Outlook 2010 displays retention information.

To set a new default policy for a folder with Outlook, select the folder and click Assign Policy on the toolbar, then select Set Retention Policy from the drop-down menu. Outlook then displays the folder properties positioned on the Policy tab (Figure 15-16). You can select any personal tag to use as the new default retention policy for the folder, and items subsequently created in the folder will inherit the default tag. The same inheritance occurs when an item is moved into the folder unless an explicit tag has already been applied to the item, in which case the existing tag is retained. To set a default policy on a folder with Outlook Web App, select the folder from the folder list under the mailbox root, right-click to select the Retention Policy option, and then select the retention policy to apply to the folder.

Figure 15-16

Figure 15-16 Changing the default retention policy for a folder.

Figure 15-17 shows how Outlook 2010 is able to display some information about retention policy in its backstage area. In this example, if we look at the mailbox, we’ll see that its properties are as follows:

Get-Mailbox -Identity 'Ruth, Andy' | Select Retent*
RetentionComment   : The management retention policy applies to this mailbox
RetentionUrl       : <a href=""> Retention
Policy Information</a>
RetentionPolicy    : Management retention policy

The RetentionComment property provides the text that you can see beside “Account Settings,” and the RetentionUrl property is used to provide a URL to a Web site where the additional information resides. These properties are usually set when you place a mailbox on retention or litigation hold. We will come to these topics shortly. For now, although you don’t have to set these properties to impose an effective retention regime, they are helpful to communicate information to users about what’s going on in their mailbox. Experience of many projects demonstrates that anything that assists in effective communications with users is likely to reduce help desk calls. Apart from the two properties that we can set on a mailbox, Outlook tells the user that the default archive policy for the mailbox will move items out of the primary mailbox after they are two years old.

Figure 15-17

Figure 15-17 Viewing retention information in Outlook’s backstage area.

Figure 15-18 shows that you can provide localized versions of retention tags that Outlook will display to users based on the client language setting.

Figure 15-18

Figure 15-18 Viewing a localized retention policy tag.

If we examine the tag that generates the output, we can see this output:

Get-RetentionPolicyTag -Identity 'Per-Retain' | Select Local*, Comment
LocalizedRetentionPolicyTagName : {En-IE: Irish version of tag, En-US: American
version of tag name}
LocalizedComment                : {En-US: General five year tag (US), En-IE:
General five year tag (IRL)}
Comment                         : Item to be kept for five years before it is
moved to Deleted Items

Notice that the LocalizedRetentionPolicyTagName property has two values for “En-IE” (Ireland variant of English) and “En-Us” (U.S. variant of English). The screen shows that Outlook displays the U.S. version, so you know that Outlook is running in that language version. An example of the command to provide localized text for a retention tag is:

Set-RetentionPolicyTag -Identity 'Per-Retain' -LocalizedRetentionPolicyTagName
'EN-US: American version of tag name', 'EN-IE: Irish version of tag name'
-LocalizedComment 'EN-US: US text comment', 'EN-IE: Irish text comment'

Removing a retention policy

The Remove-RetentionPolicy cmdlet is used to remove a retention policy from the organization. For example:

Remove-RetentionPolicy -Identity 'Retention Policy - PR Department'

Removing a retention policy has the effect of removing the policy from any mailboxes to which it is currently applied. If any mailboxes are associated with the policy, EMS will prompt you to confirm its removal. If you proceed, Exchange removes the reference to the now-deleted policy from the mailboxes. Exchange can’t decide what retention should replace the one that has just been removed, so no policy is applied. Locating the mailboxes to which a retention policy is applied is therefore a proactive step that you should take before you remove the policy. You can scan mailboxes to discover where a retention policy is applied with a command like this:

Get-Mailbox | Where {$_.RetentionPolicy -eq "Retention Policy - Audit Department"} |
Select Name

A similar set of commands can be run to locate mailboxes with a specific retention policy and assign a new retention policy to the mailboxes. For example:

Get-Mailbox | Where {$_.RetentionPolicy -eq "Retention Policy - Audit Department"} |
Set-Mailbox -RetentionPolicy 'New Retention Policy for Auditors'

Upgrading from managed folders

You can upgrade a managed folder to a retention tag by using it as the template to create a new tag. For example, let’s assume that you have a managed folder called Never Delete that acts as a repository for items that users never want to have removed from a mailbox because they are so important. You could argue the case that these items could be equally stored in an archive mailbox. However, archive mailboxes didn’t exist in Exchange 2007, and it takes time for people to change their behavior. We can use a command like the one shown here to create a new retention policy tag from the Never Delete managed folder:

New-RetentionPolicyTag -Name 'Mark item to never expire' -ManagedFolderToUpgrade
'Never Delete' -Comment 'Tag created from old Never Delete managed folder'

Of course, to complete the process, we have to associate the new tag with a retention policy and assign it to a user. After this is done, the user will be able to apply the new tag on any item in his mailbox rather than just the items placed in the managed folder.