Managing Compliance in Microsoft Exchange Server 2010

11/24/2010

Contents

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	Context	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.	DeletedItems Drafts Inbox JunkMail Journal Notes Outbox SentItems All
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.	All
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.	Personal

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.

INSIDE OUT: There is a way to create retention policy tags for calendars

Microsoft’s thinking on the subject evolved in Exchange 2010 SP1, and you can now use the New Retention Policy Tag Wizard to create retention policy tags for almost all of the default folders. Although the wizard interface allows you to select the Contacts folder and create a tag, this is really a bug, and the MFA ignores any tag placed on Contacts. Somewhat bizarrely, the wizard interface does not allow you to select the Calendar folder to create a retention policy tag for it, but you can create a retention policy tag for the Calendar with the New-RetentionPolicyTag cmdlet. Perhaps the logic here is that you should be careful when applying a retention policy to user calendars because users often want to keep the items stored in these folders for longer than items in other folders, so you are forced to do more work to create a retention policy tag for the calendar. After all, no one will thank you if you clean out the CEO’s calendar after 120 days! Once you create the retention policy tag for the calendar with EMS, you can manage it as normal with EMC, and you can include it in retention policies and apply it to mailboxes.

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 Listing of folders for which you can create retention policy tags.

INSIDE OUT: Some items are timeless

Items in some of these folders tend to be more “timeless” than general-purpose messages, so you should be careful to think through the potential consequences when you create retention policy tags for folders such the Journal or RSS Feeds. For example, how long do users reasonably want to keep items in the Drafts folder? Some users like to keep drafts for a long time because it’s their practice to create a message and compose it through multiple edits over time before they decide whether they want to send it. Others view the Drafts folder as strictly transient and never keep items there for longer than a day or so. For this reason, it might be best to create retention policy tags that mark some items to “never expire.” This is done by setting the tag to be disabled rather than giving it a retention period. When an item is stamped with a disabled retention tag, it tells the MFA that it should ignore the item and the item will therefore never be processed.

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.

NOTE

When you apply a tag to a conversation, you really just apply the tag to the items that make up the conversation at that point in time. Exchange knows that the items are part of the conversation and is able to apply the tag, but it won’t look for and tag new items as they arrive and join the conversation. This is because a conversation is not a real storage container within a mailbox and therefore cannot be tagged permanently. In short, tags only exist in a persistent manner for folders and individual items.

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.

Why are you creating this retention policy?

Before you rush to create a retention policy for anyone—even the finance department—you should sit down and determine the why, when, and how for the policy:

Why you are implementing the policy? What business need will the policy serve?
When will you implement the policy? What mailboxes will the policy be applied to? How will you communicate the policy to end users so that they understand the purpose of the policy and how it will affect the contents of their mailboxes?
How will you implement the policy? What tags and types of tags are required? What actions will you enforce through tags and what retention periods are used? Do any restrictions exist as a result of other aspects of your deployment? For example, if you use an archiving product from another vendor, you cannot deploy tags to move items into an archive mailbox after a designated period.

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	Action
RPT-Inbox	RPT	Inbox folder	Move items to Recoverable Items after 30 days
RPT-SentItems	RPT	Sent Items	Move items to Recoverable Items after 30 days
RPT-Deleted	RPT	Deleted Items	Permanently remove items after 7 days
RPT-JunkMail	RPT	Junk Mail	Permanently remove items after 3 days
DPT-General	DPT	All folders	Move items to Recoverable Items after 365 days
PER-Retain	PER	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.

INSIDE OUT: Keep it simple

Exchange allows you to create and apply as many retention policies as you want, but the question of long-term supportability arises. You should also consider the question of how many retention policies are really required for the organization as a whole and attempt to restrict the number to the minimum necessary to meet business needs. A couple of well-designed, logical policies that satisfy the vast bulk of requirements will be easier to create, deploy, and manage on an ongoing basis than a mass of granular policies generated to meet the specific needs of a department or other business group that might disappear following the next corporate reorganization. The more policies that exist, the more potential there is to confuse administrators and users alike.

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 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 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
-AgeLimitForRetention
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                2.00.00.00
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:

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.
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 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 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.

TROUBLESHOOTING

I created multiple tags for the same folder.

This is a common error, and if it is detected, Exchange flags the error as shown in Figure 15-11. Fixing the error is easy: Note the problem tag reported by Exchange and then check it against the set of tags that you have included in the policy to determine which of the duplicate tags you want to retain in the policy. Once you’ve addressed the problem, go through the wizard pages again to finish and create the new retention policy.

Figure 15-11 Encountering an error in creating a new retention policy.

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 (0.0.0.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.

INSIDE OUT: Good reasons to limit the number of tags in a policy

Microsoft recommends that you have no more than 10 personal tags in a policy, as otherwise you might confuse users with too much choice. This is reasonable advice, but as with most advice, there will be edge cases where you need to incorporate more tags in a policy to meet specialized business needs. A more sophisticated policy for a department might have separate retention tags for many of the default folders, a set of personal tags developed specifically to suit the retention needs of the department, and a default retention tag for everything else. User interface constraints are another good reason for limiting the number of tags in a policy. If you have 10 tags or fewer in a policy, there’s a reasonable guarantee that Outlook Web App and Outlook will be able to display all the tags in their user interface. On the other hand, if you have 20 tags in a policy, you’ll find that Outlook Web App is unable to list all of the tags and some will simply drop off the end of the available list. Outlook has a separate dialog box that users can navigate to if they want to discover all of the tags available in a policy, but this requires many separate clicks and additional knowledge of where to go to find the tags. For all these reasons, it’s just a bad idea to go crazy and create a tag-filled policy.

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.

INSIDE OUT: Only one retention policy—ever

A mailbox can only ever have one retention policy, so when you assign a retention policy to a mailbox, the action overwrites any policy that might already be in place. You can change retention policies multiple times on a mailbox, but this isn’t a good idea unless you really need to switch policies because the effect of the different policies might confuse users, as the MFA responds to different retention settings in the different policies. Setting a value for the RetentionURL parameter is not compulsory, but it is a useful way to communicate where a user might go to find additional details about the company’s retention policy. This URL is only visible through Outlook 2010 and isn’t displayed by earlier clients or Outlook Web App.

Set-Mailbox -Identity 'JSmith' -RetentionPolicy'Management retention policy'
-RetentionComment 'Management retention policy applies to this mailbox'
-RetentionURL'http://Intranet.contoso.com/RetentionPolicies.html'

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
-AutoSize

The value of $Null

When you want to remove a retention policy from a mailbox, you simply set the policy to $Null. For completeness, it’s a good idea to set the other properties associated with retention policies to null as well. Here’s the command:

Set-Mailbox -Identity 'JSmith' -RetentionPolicy $Null -RetentionComment $Null
-RetentionURL $Null

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
$TagList
Get-RetentionPolicy -Identity 'Management RetentionPolicy' | Select Name,
RetentionPolicyTagLinks

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.

Changing a retention tag: An exception to the rule

Changing the retention period in a tag is similar to removing a tag. All items stamped with the retention period up to the point where you made the change will continue to use that retention period; items that are stamped with the updated policy will have the new retention period. The exception to this rule is when you set the RetentionEnabled property of a tag to $False, as this value instructs the MFA to leave the tags in place but ignore them when it processes items. For example:

Set-RetentionPolicyTag -Identity 'Keep Items Forever' -RetentionEnabled $False

This situation continues until the user explicitly assigns a replacement tag to an item or you remove the tag from Active Directory using the Remove-RetentionPolicyTag cmdlet. When this happens, the next time that the MFA runs, it will remove the deleted tag from any items where it was used.

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',
'Per-Keep-LongTime'

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

INSIDE OUT: Accessing personal tags in Exchange 2010 SP1

Exchange 2010 SP1 makes the process of accessing personal tags easier by allowing users to see a list of available personal tags through Exchange Control Panel (ECP) to decide what personal tags they would like to use. Figure 15-12 shows the option exposed through the Organize Email section of ECP.

Figure 15-12 User access to personal retention tags through ECP.

A retention policy must be in effect for a user’s mailbox, and the MyRetentionPolicies policy must be included in the role assignment policy for the mailbox before ECP reveals personal tags. If shown, the user sees the personal tags that she can already use because they are included in the retention policy (these tags are listed as Required) and the other personal tags that are defined for the organization that she can choose to use (these tags are listed as Optional). The user cannot remove any of the Required tags because their presence is mandated by the retention policy that is applied to the mailbox. A user can begin to apply personal retention tags to items immediately after adding the tags to her mailbox.

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 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 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 Outlook 2010 displays retention information.

Managed Folder Assistant automatically applies the retention policy

Although most retention policies will include a default policy tag to provide retention instructions for items held in nondefault folders, Outlook and Outlook Web App support the use of personal retention tags to set a different retention policy on a folder. In effect, this means that Exchange will apply the policy defined in the personal retention tag to items held in the folder, much in the same way that it applies the retention policy tags placed on default folders such as the Inbox. In some respects, you can use this approach to create a roughly equivalent situation to the functionality provided by Exchange 2007 managed folders. However, the big difference is that you have to create the folders and apply the retention policies manually, whereas the MFA does the work to push out new folders to user mailboxes and apply the retention policy automatically for managed folders.

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 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="http://intranet.contoso.com/retentionpolicies.html"> 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 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 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.

Save to your account