Exchange 2010 MRM: How to Modify and Reduce Help Desk Calls About Retention Policies

125919.zip

Instead of using managed folders like its predecessor, Exchange Server 2010's messaging records management (MRM) system uses retention tags and policies to provide a way for users to control what's in their mailboxes and retain those messages and attachments that are required business records. In "Exchange 2010 MRM: Implementing New Retention Policies" (October 2010, InstantDoc ID 125359), I showed you how to design, create, and apply retention tags and policies using the Exchange Management Shell (EMS). Now I'll show you how to modify, remove, and customize retention policies. I'll also discuss how to help users understand them so you can reduce the number of Help desk calls. 

Modifying a Retention Policy

Policies often need to evolve over time, which means you'll need to add or remove tags. Exchange 2010 SP1 makes this task a lot easier because Microsoft has added a GUI for managing retention policies and tags to the Exchange Management Console (EMC). However, it’s still good to know how to do the work in EMS, as this is the only way that you can work with retention policies and tags on an Exchange 2010 server.

Adding tags. You can add new tags to an existing policy with the Set-RetentionPolicy cmdlet. To add a new tag, you must provide it along with the list of existing tags using the cmdlet's -RetentionPolicyTagLinks parameter. It's not sufficient to merely specify the new tag on its own, as this will update the policy to include only the new tag.

You can use two approaches to include a new tag in a retention policy. The first approach is to manually type in the complete list of tags. This approach works best for simple policies that include only a few tags, such as

Set-RetentionPolicy

  -Identity 'Audit Department'

  -RetentionPolicyTagLinks 'Audit-Inbox', 'Audit-SentItems'

Get-RetentionPolicy

  -Identity 'Audit Department'

(Although these commands wrap here, you'd enter each command on one line in EMS. The same holds true for the other commands that wrap.)

The second approach is to let Windows PowerShell retrieve the current list of tags, then add the new tag to that retrieved list. This approach works best when you have complex policies with many tags (e.g., six or more) and the potential exists that you might forget to input one of them.

Listing 1 demonstrates the second approach. This code first uses Get-RetentionPolicy to retrieve the existing tags, putting them in the $TagList variable. It also puts the new tag in the $NewTag variable. Next, the code uses the += operator to concatenate the new tag to the retrieved tags and assigns the resulting list back to the $TagList variable. Finally, it uses Set-RetentionPolicy to write the updated set of tags in $TagList to the policy. As you can see, the second approach requires a little more typing, but it has the advantage of absolutely guaranteeing that all the existing tags are preserved.

To show you how easy it is to do the same task with the new GUI in Exchange 2010 SP1's EMC, here are the steps you'd follow:

Removing tags. To remove a tag from a policy, you have to write a replacement list into the policy using the first approach I described. Or, if you're using SP1, you just need to select the tag to remove, click the "X" icon, then click OK.

If you remove a tag from a policy, users covered by the policy can't apply the tag to any items in their mailbox. However, existing items that have been stamped with the tag continue in place and will be processed by the Managed Folder Assistant (MFA). This situation continues until the user explicitly assigns a replacement tag to an item or you remove the tag from Active Directory (AD) using the Remove-RetentionPolicyTag cmdlet. When you do the latter, the MFA will remove the deleted tag from items the next time it runs.

Removing a Retention Policy

When you want to remove a retention policy from a mailbox, you simply set the policy to $Null. Here's an example of the command you'd use

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

When you want to remove the retention policy from the organization (i.e., AD), you use the Remove-RetentionPolicy cmdlet in a command such as

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

Removing a retention policy has the effect of removing the policy from any mailboxes to which it's currently applied. If any mailboxes are associated with the policy, Exchange will prompt you to confirm its removal. If you proceed, Exchange removes the reference to the now-deleted policy from the mailboxes. Because Exchange won't know which retention policy should replace the one that was just removed, no policy is applied. Therefore, locating the mailboxes that a retention policy is applied to is 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 - PR Department'\} |Select Name

You can easily adapt this command so that it applies a new policy to the mailboxes after it finds them. To do so, you use the Set-Mailbox cmdlet in a command such as

Get-Mailbox | Where \{$_.RetentionPolicy

  -eq "Retention Policy

  - PR Department"\} |

  Set-Mailbox

  -RetentionPolicy

  "Public Relations Policy"

You'd run this command before running the command to remove the old retention policy.

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. A personal tag is one that a user can assign to a folder or an individual item anywhere in his or her mailbox. This can only be done if a retention policy already applies to the user's mailbox. For example, suppose you want to assign a new personal tag that allows the user to mark an item to be moved into the archive after a year. This user's mailbox doesn't have any other personal tags, so you'd use the Set-RetentionPolicyTag cmdlet like this

Set-RetentionPolicyTag -Mailbox JSmith

  -OptionalInMailbox

  'Personal-Move-Archive'

Exchange adds the personal tag to the set of tags in the retention policy and makes the expanded set available the next time that the user connects. You can't assign a default policy tag (DPT) or a retention policy tag (RPT) to a mailbox in this manner. These tags can only be assigned to a mailbox through a retention policy. See Exchange 2010 MRM: Implementing New Retention Policies for detailed descriptions of DPTs, RPTs, and personal tags.

Unfortunately, no cmdlet is available to retrieve a mailbox's assigned personal 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 personal tags assigned to a mailbox, you have to write the complete list with Set-RetentionPolicyTag. For example, to add a personal tag to a policy that already has one assigned, you'd use a command such as

Set-RetentionPolicyTag -Mailbox JSmith

  -OptionalInMailbox

  'Personal-Move-Archive',

  'Personal-Keep-LongTime'

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

Set-RetentionPolicyTag -Mailbox JSmith   -OptionalInMailbox $Null

Informing Users

The first evidence users see that their mailbox has been assigned a retention policy is when they see warnings in message headers, which start appearing 30 days before an item expires. These warnings are visible when a message is opened or viewed in the preview pane. For example, Figure 2 shows a warning in Outlook Web App (OWA). It advises that a message has 19 days to go before it expires as the result of a retention policy tag placed on the Inbox. These warning messages can prompt a lot of Help desk calls if users aren't informed about the retention policies and the options they have when they get a warning message.

When users receive a warning message, they have two options: Let the item expire or apply a different tag to the item. If users decide to let an item expire, Exchange will perform whatever action is defined in the tag (e.g., move to Deleted Items, permanently delete) after the expiration date is reached.

Although the tags indicate the retention period (e.g., 6 months), they don't tell users what action will occur when the retention period expires. Tags have a variety of associated actions from permanently delete to merely warning that the retention period has expired. (An exception is an archive policy, as these tags always mean that an item will be moved to a personal archive when the retention period expires.) Outlook 2010 users can view the actions for the default tag on a folder by viewing folder properties, but this information isn't available in OWA. (Outlook 2010 and OWA are the only two clients that currently expose retention tags.) So, when you create tags, you might want to incorporate the action in its name. For example, a tag named "One year delete" gives a pretty good hint to users as to what might happen, whereas one named "RPT-MGR-Retain" does not.

If users choose to apply a different tag to an item in their Inbox, they can do so one of two ways. They can move it or assign a personal tag to it.

Moving the item. By moving the item to a different folder, users are removing it from the influence of the retention policy tag (RPT) that applies to Inbox items. After it's moved, the item is governed by the default policy tag (DPT) defined in the retention policy that applies to the mailbox if it exists or the policy applied to the folder and inherited by all items that are added to the folder. If neither condition exists, the item is left untagged and therefore won't be subject to processing by Exchange.

Assigning a personal tag. Users can explicitly assign a personal tag to the item. They can choose from any of the personal tags defined in the retention policy that's applied to their mailbox. To do so, they just need to right-click an item and select the personal tag. As you can see in Figure 3, the Retention Policy UI differs between Outlook (left) and OWA (right). Outlook's UI provides a richer set of options, but OWA's UI is less confusing for the novice user. Users will see the Retention Policy UI only when a policy is applied to their mailbox.

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 because an explicitly assigned personal tag always takes precedence over a tag placed on a folder. The personal tag remains with the item if the users move the item to another folder. If users want to impose a different retention tag on the item, they have to replace the existing personal tag with a different tag selected from the set available in the policy.

If a tag specifies "MoveToArchive" as its action, Outlook and OWA list it under the Archive Policy UI rather than the Retention Policy UI, as Figure 4 shows. These tags are under the Archive Policy UI because they can only be used with mailboxes that have personal archives.

Applying Advanced Settings to Facilitate Better Communication

Anything that facilitates better communication with users is likely to reduce Help desk calls, so you might want to have Outlook or OWA display additional information by setting some mailbox properties. For example, you can provide a message box like that in Figure 5 by setting two mailbox properties:

You can use the Set-Mailbox cmdlet to set these properties. To create the message box in Figure 5, the command would look like

Set-Mailbox -Identity 'JSmith'

  -RetentionComment 'The management

  retention policy applies to this mailbox'

  -RetentionUrl

  '  retentionpolicies.html">

  Retention Policy Information

To see whether a mailbox has the RetentionComment and RetentionURL properties set, you can run a command such as

Get-Mailbox -Identity 'JSmith' |   Select Retent*

If your users speak different languages, you can provide localized versions of the retention tag's name and comment, which the Outlook or OWA client will display based on its language setting. An example of a command to provide localized text for a retention tag is

Set-RetentionPolicyTag

  -Identity 'Per-Mgr-Retain'

  -LocalizedRetentionPolicyTagName

  'en-IE: Irish version of tag name'

  'en-US: US version of tag name',

  -LocalizedComment

  'en-IE: Irish text comment'

  'en-US: US text comment',

Notice that the LocalizedRetentionPolicyTagName and LocalizedComment properties have two values: one for clients whose language is set to en-IE (Ireland variant of English) and one for clients whose language is set to en-US (U.S. variant of English). When you set these properties, you need to specify the language identifier (e.g., en-IE, en-US) and the text (i.e., name and comment) in the appropriate language, using the format shown in the sample command. Be sure that you get accurate translations that clearly convey the meaning of the tag. Don't be tempted to cut corners and use school-quality translations or those that you might be able to procure free of charge from the Internet.

To see whether a retention tag has localized text, you can run a command such as

Get-RetentionPolicyTag

  -Identity 'Per-MGR-Retain' |

  Select Local*

MRM: An Important Technology

Exchange 2010's implementation of retention policies establishes a comprehensive, automated, and user-friendly platform for administrators. Retention policies and tags will become an important part of many Exchange deployments, especially for companies that have to keep good records to meet legislative or regulatory requirements. In Exchange 2010, administrators need to use EMS to manage retention policies and tags, whereas in Exchange 2010 SP1, administrators can use EMS or the new GUI in EMC. I anticipate that the new GUI will make retention policies and tags more approachable for many administrators.

Listing 1: Code That Demonstrates the Second Approach to Adding a Tag to an Existing Policy

$TagList = (Get-RetentionPolicy -Identity 'Management Retention Policy').RetentionPolicyTagLinks

$NewTag = Get-RetentionPolicyTag -Identity 'Manager-New-ArchivePolicy')

$TagList += $NewTag

Set-RetentionPolicy -Identity 'Management Retention Policy' -RetentionPolicyTagLinks $TagList

Get-RetentionPolicy -Identity 'Management RetentionPolicy' | Select Name, RetentionPolicyTagLinks