The default archive and retention policy
When you enable a personal archive for a mailbox, Exchange
assigns a retention policy called Default MRM Policy to the mailbox
unless the mailbox has a retention policy already assigned. This policy
is designed to help the mailbox’s owner use the archive by
automatically moving items from the primary mailbox into the archive as
their retention period expires. Assigning a retention policy
automatically to a mailbox might be considered helpful, but the action
has some consequences for users, which are discussed in the following
paragraphs.
The
retention period applied by the default tag in the policy is two years,
so the effect of applying the policy is that any item in the mailbox
that is not stamped with another tag will be moved into the archive
after it is two years old. The retention policy assigned to the mailbox
becomes effective the next time the Managed Folder Assistant (MFA)
processes the mailbox. The default policy is not assigned if the
mailbox is already under the control of another retention policy.
The
name of the default retention policy Exchange supplies has changed over
the versions; if you previously deployed Exchange 2010, you will find
that another policy, the Default Archive and Retention Policy, has been
applied to mailboxes that had archives enabled with Exchange 2010. In
fact, an even earlier policy, Default Archive Policy, might also be
present. This policy was provided with the original release to
manufacturing (RTM) of Exchange 2010. Even if the other two policies
are available, Exchange will apply the Exchange 2013 version to
mailboxes that are newly enabled with archives.
It
might be strange to have multiple default retention policies within an
organization. In fact, apart from their name, the policies differ
slightly in terms of the retention tags they contain. The Default
Archive Policy contains only archive tags and therefore does not
function well in terms of an overall retention policy, which ideally
should contain tags to help remove unwanted items from a mailbox and
archive items that need to be retained. However, although a good reason
exists for the change made from Exchange 2010 RTM to Exchange 2010 SP1,
the two default retention policies in Exchange 2010 SP1 and Exchange
2013 appear functionally identical, apart from the name. The only
reason Microsoft changed the name seems to be to align the default
retention policies across Exchange Online and Exchange on-premises
because both now use Default MRM Policy.
In any case, the
Exchange 2010 SP1 version of the default retention policy will continue
to work with Exchange 2013, and there is no reason to replace it with
the Exchange 2013 version for the mailboxes that use the older policy. Table 1
describes the retention and archive tags that are included in the
default policy. You can add retention archive tags to or delete them
from the policy if required.
Table 1. Tags included in default archive and retention policy
Tag name | Type | Purpose |
|---|
Default 2-year move to archive | Default | Automatically
move items to the personal archive when they are two years old. This
tag is applied to any item in the mailbox that does not have an
explicit tag applied by the user or is inherited when an item moves
into a folder that has a default policy. |
Personal 1-year move to archive | Personal | Tag
that the user can apply to items to instruct the MFA to move the items
into the personal archive after they are one year (365 days) old. |
Personal 5-year move to archive | Personal | Tag
that the user can apply to items to instruct the MFA to move items into
the personal archive after they are five years (1,825 days) old. |
Personal never move to archive | Personal | Tag that the user can apply to items to block the MFA from ever moving the items into the personal archive. |
Recoverable Items 14-days move to archive | Recoverable Items folder | Move items placed in the Recoverable Items folder to the personal archive after 14 days. |
1 Month Delete | Personal | Move items into the Deleted Items folder after one month. |
1 Week Delete | Personal | Move items into the Deleted Items folder after one week. |
6 Month Delete | Personal | Move items into the Deleted Items folder after six months. |
1 Year Delete | Personal | Move items into the Deleted Items folder after one year. |
5 Year Delete | Personal | Move items into the Deleted Items folder after five years. |
Never Delete | Personal | Disabled tag that prevents the MFA from processing the item; the effect is to stop the item from ever being deleted. |
Notice
that the default MRM policy contains only a single default tag to move
items into the archive after two years; no default tag is present to
delete items. Therefore, the impact of applying this policy to
mailboxes is that every item more than two years old will be moved by
MFA into the archive the first time MFA processes the mailboxes after
the policy is applied. And because Exchange automatically applies the
default MRM policy to mailboxes after they are enabled for archives,
this sequence of events becomes immediately apparent if items exist in
the mailbox that are more than two years old. In effect, this results
in the disappearing-items syndrome in which users log problem reports
for missing mailbox items. In the majority of cases, the missing items
are found in folders in the archive mailbox. It just takes time for
users to realize that Exchange moves items automatically after they
reach a certain age; this underlines the importance of communication
with the user community as you implement archive mailboxes.
Assuming that your mailbox is archive-enabled and a suitable
client is at hand, working with items in the archive is just like
working with items in the primary mailbox. You can create new items,
reply to messages, move items around, and so on. After the archive
mailbox is created, it is up to the user to populate it, most likely by
using drag and drop to move folders or items from his primary mailbox.
Administrators can import the complete contents of PSTs into a mailbox,
but there are some limitations with this approach, as discussed
previously.
Exchange
doesn’t support offline access for data held in archive mailboxes. When
Outlook is configured to use cached Exchange mode, it has access only
to the offline copies of the folders from the primary mailbox that are
stored in the OST and uses background synchronization to keep those
folders updated. This arrangement enables Outlook to work through
transient network interruptions. Outlook has to be able to connect to
the server before it can work with the data stored in an archive.
Troubleshooting I can’t access my archive mailbox when I’m offline.
If
you want something to be available offline (or available to a mobile
device), you have to store it in the primary mailbox. The archive is
designed to hold information that isn’t always required immediately and
that you can wait to access until you can get back online, so if you
need something from the archive and know that you have to work offline
(for example, on a road trip), you have to plan ahead and move the
desired items from the personal archive into the primary mailbox
beforehand.
Disabling an archive mailbox
If present, you can disable the archive for the selected
mailbox in EAC by clicking the Disable link under In-Place Archive
shown in the action pane. Alternatively, you can edit the mailbox’s
properties, open the Mailbox Features section, and disable the archive
there. If you have an active EMS session, you can run the
Disable-Mailbox cmdlet. For example:
Disable-Mailbox –Identity 'Smith, John' –Archive
EMS
prompts for a confirmation before it proceeds unless you add the
–Confirm:$False parameter. This is not a good idea unless you are
absolutely sure that you want to disable the archive. If the archive’s
owner is logged on and connected to her mailbox when the archive is
disabled, she can continue to access data in the archive until the next
time the client disconnects.
When it disables an archive
mailbox, the Information Store disconnects it from the primary mailbox
and keeps it in the database until the deleted mailbox retention period
expires. If you make a mistake and have to re-enable the archive before
it is removed from the database, the Store reconnects the original
archive, and all the information in it becomes available to the user
again. Note that you cannot disable a mailbox when it is on hold; this
action can interfere with the ability to preserve information that
might be required for discovery purposes. If necessary, you can specify
the IgnoreLegalHold switch with the Disable-Mailbox cmdlet to force
Exchange to disable a mailbox. It would be wise to seek approval from
your legal department before taking such an action.
