System tags
Exchange 2013 supports two types of retention tags: system
tags and nonsystem tags. Exchange uses system tags for its own
purposes, and they are not shown when you run the
Get-RetentionPolicyTag cmdlet unless you specify the –IncludeSystemTags
parameter. By default, Get-RetentionPolicyTag lists only nonsystem tags
(those created to be used with normal retention policies). To see the
system tags defined in an organization, you can execute the following
command. (Nonsystem tags are listed afterward.)
Get-RetentionPolicyTag –IncludeSystemTags | Format-Table Name, Type, SystemTag
The
first three entries you will see (AutoGroup, ModeratedRecipients, and
AsyncOperationNotification) are system tags that Exchange uses to
prevent items from accumulating in arbitration mailboxes. The other
entries are nonsystem tags, which 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'
Get-RetentionPolicyTag –Identity 'AsyncOperationNotification'
Caution
You
cannot add system tags to a retention policy that’s applied to user
mailboxes. Deleting a system tag is also a bad thing because you have
no idea of what consequences might follow from this event.
Designing a retention policy
Many
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 delete everything in the Deleted Items folder
permanently that is more than three days old (the shred principle),
whereas users in other departments might not be concerned whether 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 moves 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 which tags are included in the policy,
their purpose, and the folders MFA processes. Apart from its other
advantages, capturing the design like this makes it easier to
communicate the policy to users. Table 1 lays out a simple policy that could be applied to help managers cope with overloaded mailboxes.
Table 1. 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 most other folders can remain in place for
a year, but calendar items are kept for five years. Removal of items
from the Deleted Items folder after a week. Tags are provided to keep
the contents of several utility folders under control. A tag is
provided to enable users to mark items for retention for 10 years.
Another is available to tag audit items so that they are held
indefinitely. |
TAG NAME | TAG TYPE | APPLIES TO | ACTION |
Inbox 30 | RPT | Inbox folder | Move items to Recoverable Items after 30 days. |
Sent Items 30 | RPT | Sent Items | Move items to Recoverable Items after 30 days. |
Calendar 5 years | RPT | Calendar | Move calendar items to Recoverable Items after five years. |
Deleted Items 7 | RPT | Deleted Items | Permanently remove items after seven days. |
Junk Mail 3 | RPT | Junk Mail | Permanently remove items after three days. |
RSS Feeds 3 | RPT | RSS Feeds | Move items to Recoverable Items after three days. |
Sync Issues 1 | RPT | Sync Issues | Clean out synchronization error logs daily. |
Delete after 5 years | DPT | All folders | Move items to Recoverable Items after 1825 days. |
Archive after 2 years | DPT | All folders | Move items into the archive mailbox after 730 days. |
Retain for 10 years | PER | All folders | Move items to Recoverable Items after 3650 days (10 years). |
Keep for Audit | PER | All folders | Never delete—item held indefinitely for audit purposes. |
Logically, you can have only 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 have only one default retention tag and one
default archive policy tag that apply to all folders. If you use two
default tags (which implies that you use archive mailboxes), you should
make sure that items can move into the archive before they are deleted.
This is done by giving the default archive tag a shorter retention
period than the default retention tag. For example, this will work:
Default archive tag retention period 2 years (730 days). MFA will move all items that do not have another tag on them into the archive after items are more than two years old.
Default retention tag period 5 years (1,825 days). MFA
will remove the items (either allowing recovery or removing them
permanently) after they have been in the mailbox for five years. In
fact, the items were in the primary mailbox for two years, then moved
to the archive, and then aged out of the archive after another three
years.
Things would not run so smoothly if the
two retention periods were reversed, because MFA would then delete
items before they had a chance to be archived!
Managed Folder Assistant and retention policies
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 could affect
thousands of items in user mailboxes, it is critical to communicate
clearly what will 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. Having a well
thought-out retention policy that the business agrees on and that is
then clearly communicated to business leaders and end users well in
advance is a good way to avoid problems when you implement this part of
your compliance strategy.
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 means
that items become eligible for processing by the MFA 30 days after they
are delivered to the Inbox. The creation date is used for retention
purposes even for modifiable items such as posts. As noted earlier, you
can create a tag to mark items never to be processed by the MFA. Such a
tag has no value set for its AgeLimitForRetention property, and its
RetentionEnabled property will be set to $False. For example, to see
the set of retention tags that can be added to retention policies to
allow users keep items indefinitely, you can run this command:
Get-RetentionPolicyTag | Where-Object {$_.AgeLimitForRetention –eq $null} | Format-Table Name, AgeLimitForRetention, RetentionEnabled -AutoSizeTags
with a null age limit might have different retention actions (move to
archive or delete), but in effect, they are simply different names for
the same effect, which is to tell MFA to ignore them when it processes
items. Having tags that do the same thing with different names is
generally frowned upon because it increases the number of tags that
have to be managed and can cause a little confusion, but sometimes it
is justified when you want to communicate to the user the exact nature
of the tag and what it will do. Keep For Audit is a good example here;
the user should be under no illusion about what this tag means and what
it should be used for.
