Naming retention tags
When we started to work with retention policies and tags in
Exchange 2010, the initial advice given from the Exchange development
group was that tags should be named in a way that made their purpose
immediately obvious. The idea was that you could use a prefix of RPT
for retention policy tags, DPT for default policy tags, and PER for
personal tags. Following a naming scheme like the one outlined earlier
is logical, but it runs contrary to the way human beings absorb
information. Having a tag called RPT-Inbox-30 makes perfect sense to
those who are used to interpreting cryptic names that include acronyms.
Thus, an administrator who is accustomed to working with retention tags
understands at a glance that the name means the tag is a retention
policy tag for the Inbox that likely sets a retention period of 30 days.
Client
user interfaces expose the names of tags to end users. Outlook Web App
exposes less than Outlook does, but the fact remains that users can
become aware of tag names. It is for this reason that you need to pay
attention to the names given to tags and make sure that the names are
logical and convey the meaning of the tag to users.
You must
determine a tag naming scheme because the retention policy menu that
Outlook 2010, Outlook 2013, and Outlook Web App display lists tag names
and their retention period (such as six 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. This is apparent from the
screen on the left in Figure 3,
which is revealed when a user right-clicks an item. (We know the item
is in the Inbox because the folder policy is Inbox 30.) Tags can have a
variety of associated actions, from permanent deletion to merely
warning that the retention period has expired, but the action the tag
invokes is not immediately apparent here. Outlook Web App displays
retention tags in much the same way. Logically, archive policy tags
appear only if a mailbox has an archive.
Outlook
2010 and Outlook 2013 users can view the actions for the default tag
(if one exists) for a folder by viewing the folder properties (the
right-side screen in Figure 3).
Here you can see the action dictated by the tag, in this case to remove
items from the Inbox after 30 days. However, this information is not
available through the Outlook Web App user interface, and nothing at
all is exposed about retention tags in the Outlook 2007 user interface.
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 usually 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 have to define a set of retention tags for each
department to match its work practices. The Keep For Audit personal tag
specified in the prototype retention policy discussed earlier is an
example of a business-specific tag name.
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 because
changing the names of tags halfway through a deployment is guaranteed
to cause maximum confusion.
Retention policies and tags are managed through the Compliance
Management section of EAC. To create a new retention tag, click
Retention Tags and then click New (+). You then select the type of tag
(default, folder, or personal) you want to create. In this example, you
create a tag for the Inbox folder. Figure 4 shows the fields you need to complete, split across two screens.
A
folder tag does not offer you the opportunity to move the item into the
archive because Exchange limits this option to a default tag that
applies to all untagged items in a mailbox or a personal tag that a
user can apply himself. If you were to create a new personal tag, for
instance, EAC displays a screen similar to that shown in the right side
of Figure 4, and you can see that Move To Archive is now available.
After creating all the retention policy tags you need, you should have something like the situation illustrated in Figure 5.This is the complete set of the retention policy tags defined for the
organization. You can immediately see the advantage of following a well
thought-out naming convention for tags. In addition, you can see how it
is possible to accumulate a relatively large number of tags quickly,
which different retention policies use 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 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 because different sets of users might
need to keep items in these folders for different periods.
As
an example of how to accomplish the same task with EMS, here is how to
create the retention policy tag defined in the management retention
policy for the Inbox folder.
New-RetentionPolicyTag –Name 'Inbox 30' –RetentionAction DeleteAndAllowRecovery –AgeLimitForRetention 30 –Type Inbox –Comment 'Inbox items are automatically deleted after 30 days' –RetentionEnabled $True
You can check the properties of your new retention tag with the Get-RetentionPolicyTag cmdlet. For example:
Get-RetentionPolicyTag -Identity 'Inbox 30' | Format-List
You
should see that the output from Get-RetentionPolicyTag confirms that
the tag can cover any class of item (MessageClass = *, the default for
Exchange 2010 and Exchange 2013), that it is for the Inbox folder (Type
= Inbox), and that items that inherit this tag because they are stored
in the Inbox folder 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; you cannot build a
retention tag that applies only to items of a certain class in a folder
(such as applying the policy to items of class IPM.Note but ignoring
those of class IPM.Contact).
Now
review the EMS code that could be used to create some of the other tags
that are required for the management retention policy. This time, a
personal tag (Type = Personal) is needed to enable users to mark items
to be kept in their mailbox for 10 years (3,650 days, give or take a
couple of extra days for leap years), 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. If a user applies this tag to an item in the
Inbox, Exchange will not delete it 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, remember that Exchange keeps a personal tag on an
item even if the item moves to another folder that has an associated
retention policy tag. You create the new personal tag with the
following command:
New-RetentionPolicyTag –Name 'Retain for 10 years'' –RetentionAction PermanentlyDelete –RetentionEnabled $True –AgeLimitForRetention 3650 –Type Personal –Comment 'Item to be kept for ten years before it permanently deleted'
Setting
the Type parameter to Personal is critical here because it makes the
tag personal and explicit rather than implicit, like the tags applied
to all items in a folder.
Troubleshooting I created a retention tag with the wrong type. What do I do?
If
you make a mistake and create a retention tag of the wrong type, you
cannot change the type with the Set-RetentionPolicyTag cmdlet. Instead,
you must delete the tag with the Remove-RetentionPolicyTag cmdlet (or
through EAC) and then re-create it afterward with the correct type. The
sooner you realize the mistake, the better because this will restrict
the processing that MFA does to apply and then remove the tag from
items in user mailboxes.
To complete the design, the policy
needs to provide managers with two default tags. The first forces any
items older than two years (730 days) to be moved into the archive; the
second removes items to the Recoverable Items folder after they are
five years (1,825 days) old. Remember, a default tag is used when no
other tag has been applied to an item.
New-RetentionPolicyTag –Name 'Archive after 2 years' –RetentionAction MoveToArchive –RetentionEnabled $True –AgeLimitForRetention 730 –Type All –Comment 'Items older than two years are moved to the archive unless otherwise tagged'
New-RetentionPolicyTag –Name 'Delete after 5 years' –RetentionAction DeleteAndAllowRecovery –RetentionEnabled $True –AgeLimitForRetention 1825 –Type All –Comment 'Items older than five years are removed from the mailbox'
You’ll
have noticed that all the tags you created specify –RetentionEnabled
$True. Therefore, the tag is active and should be processed by the MFA.
To disable a tag, set the RetentionEnabled property to $False. The MFA
ignores a tag in this state.
Most
of the tags you have created so far use the DeleteAndAllowRecovery
action, with the exception being the default archive tag. The full set
of available actions is as follows:
DeleteAndAllowRecovery. Moves the item into the Recoverable Items folder so that the user can recover it if necessary.
PermanentlyDelete. Immediately
deletes the item so that it cannot be seen using Recover Deleted Items.
If the mailbox is on retention hold or subject to an in-place hold, the
item is retained in the Recoverable Items folder and still available in
eDiscovery searches.
MoveToArchive. Moves
the item to a folder of the same name in an archive mailbox. This
action is only possible if the mailbox has an archive. If not, the
action is ignored. Moving to the archive is analogous to the Outlook
AutoArchive option that moves items into a PST on a regular schedule to
help keep a mailbox under quota. The big difference is that users can’t
vote whether they want to use the option because 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 ignores 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 applies
the archive tags for the mailbox the next time it runs.
Tags
that specify MoveToArchive are sometimes called move tags, whereas
those that specify DeleteAndAllowRecovery and PermanentlyDelete are
called delete tags. To check that all the required tags are in place
that you need to build the retention policy, you can review the set of
tags through EAC or execute the following EMS command:
Get-RetentionPolicyTag | Format-Table Name, Type, RetentionAction, RetentionEnabled, AgeLimitForRetention –AutoSize
If
you make a mistake in defining a retention policy tag, you can remove
the tag with the Remove-RetentionPolicyTag cmdlet. If the tag has
already been applied to mailbox items, the MFA cleans up by removing
any reference to the removed tag from items as it processes mailboxes.
