Quantcast
Channel: Exchange 2010 SP2 RU4 – Thoughtsofanidlemind's Blog
Viewing all articles
Browse latest Browse all 4

Beware the effects of enabling an Exchange 2010 archive mailbox

$
0
0

The introduction of archive mailboxes is one of the major new features offered by Exchange 2010. Matters are substantially improved in Exchange 2010 SP1 as it supports the separation of a user’s primary mailbox and their archive mailbox across different databases, giving administrators the ability to consider schemes such as dedicated archive databases or even dedicated archive servers.

Office 365 then offers the prospect of allowing users to maintain their archive mailboxes “in the cloud”. In this scenario, the primary mailbox will be located in a database running on an “on-premise” server and the user will connect to a database running on a server in a Microsoft datacenter whenever they want to access the contents of their archive. All of this depends on the deployment of Exchange 2010 SP1 as the basic platform for Exchange Online within Office 365; this work is ongoing and Office 365 is currently in beta. See this EHLO post for some information on how this setup works.

Of course, you need a client that knows about archive mailboxes before you can use the feature. Outlook 2010/2013 and Outlook Web App (OWA) 2010 are clients that Microsoft has purpose-built to exploit archive mailboxes and the other compliance features supported by Exchange 2010, but it’s a pain (and expensive) to have to deploy new Outlook clients just to be able to use an archive mailbox.

The cumulative update for Outlook 2007 SP2 helps by providing the code that Outlook needs to be able to recognize that an Exchange 2010 mailbox has been enabled with an archive and to then open the archive. Unfortunately the code is incomplete insofar as it doesn’t round out the scenario by providing the ability for users to manipulate archive tags. I guess the impact on the Outlook user interface would have been too large to have the work done for an update. “Large” in this context meaning that Microsoft would have had to change too much code to add all the bits necessary to reveal and manipulate archive tags. Once you start to make extensive code changes, you increase the engineering and testing cost dramatically and create all sorts of other issues such as the requirement for internationalization and translation into all of the languages supported by Outlook 2007. The upshot is that if you want to access archive (and retention) tags then you have to use Outlook 2010/2013 or OWA 2010.

Don’t even think about ever seeing archive support for Outlook 2003 as it’s a dead duck client as far as Exchange 2010 is concerned…

Assuming that you’ve got the right clients and you’re running Exchange 2010 SP1 (or later), all should be well and you can start to enable user mailboxes with archives just as soon as you have moved them to an Exchange 2010 server (and remembered that you need enterprise client access licences or CALs because archives are an extended feature not covered by the standard CAL).

But here’s the rub. Enabling a mailbox to have an archive takes a matter of seconds, or even less if you have an EMS session open and are fast to type and run the Enable-Mailbox -Archive command. It’s the consequences of enabling an archive of which so few administrators are aware. In a nutshell, by enabling a mailbox to have an archive, you stamp the mailbox with Exchange’s default archive and retention policy and you deliver the mailbox into the jaws of the Managed Folder Assistant (MFA).

MFA is an invaluable ally for administrators when it is well understood and used correctly. The problem with MFA is that it can have an unexpected (and unwelcome) effect on user mailboxes after a retention policy is applied. Sometimes administrators want this to happen, as in the case of a well-planned campaign to “help” users control the sprawl of their mailboxes through the deployment of retention policies and tags. But in this case, you’ve just told MFA that you want it to process the newly-enabled mailbox and apply the set of archive tags that Microsoft has thoughtfully included in the “Default Archive and Retention Policy” that the installation of Exchange 2010 SP1 adds to every organization. You can see the policy listed by EMC in the screen shot below. In fact, there are two policies used by archive mailboxes listed here. The other (Default Archive Policy) is an older version used by Exchange 2010 RTM. It is retained after the installation of SP1 but is no longer applied to mailboxes after they are enabled with an archive.

The default archive and retention policy listed in EMC

In the screen shot show below, you can see that a mailbox that is not enabled with a archive does not have a retention policy. However, once we run Enable-Mailbox to assign an archive to the mailbox, Exchange fills in a number of relevant properties including the GUID that links the default mailbox to the archive. We can also see that the Default Archive and Retention Policy has been assigned to the mailbox.

Using EMS to enable a mailbox with an archive

MFA will do its business very effectively the next time the newly-enabled mailbox appears in its list. The MFA in current versions of Exchange operates on a daily workcycle basis that aims to process every mailbox in a database at least once daily. This means that the newly-enabled mailbox will be discovered and processed by MFA within one day of the archive being enabled.

When MFA processes a mailbox, it checks items in the mailbox to see if they have been stamped with the appropriate tags. Retention and archive tags can be applied to individual items. folders, or even conversations. And then you have the magic of a default tag, which is applied to any item in a mailbox that is under the control of no other more specific tag. Of course, your newly-enabled mailbox has never been processed by MFA and the mailbox owner is highly unlikely to have ever applied specific tags to items, so the net effect is that the default archive tag becomes all-powerful and MFA will merrily stamp it on all and sundry within the mailbox.

Properties of the default tag in the Default Archive and Retention Policy

If we look at the tags included in the Default Archive and Retention Policy, we can see that the default tag (the one that “applies to all other folders”) is called “Default 2 year move to archive” (shown above). The action specified in this tag tells MFA to move items into the archive mailbox when they are two years old. The user won’t notice that this has happened if their mailbox is new and no item is more than two years old. They might not notice for other reasons – boredom, lack of attention, devotion to controlled substances, or whatever… but if a mailbox is more than two years old and the user keeps reasonable tabs on what it contains, they’ll probably notice that items have started to disappear as MFA processes them, discovers that they are more than two years old, and promptly moves them into the archive. Of course, “disappear” is a very emotional word and it’s somewhat inaccurate in this context. The items have disappeared from the primary mailbox but MFA has stored them quite safely in the user’s archive.

At the end of the day, the user gets a nicely cleaned mailbox and a populated archive and all is well if that’s what the user wanted and expected. The situation is less happy if the user panics because they think they have lost data and the help desk is unaware of what happens when archives are enabled (maybe you forgot to tell them). Loud words and swearing ensues and no one is happy.

The moral of the story is that archives are good provided that they are deployed with care, attention to detail, and with due warning to all concerned.

– Tony

Follow Tony @12Knocksinna

Update: See my latest note on retention policies and some changes that Microsoft has made in their interpretation of what you can do with the default MRM policy. Also, it’s worth noting that Office 365 automatically enables the default MRM policy for new mailboxes when they are created – no archive is created, so the archive tags are ignored and only implemented if an archive is subsequently enabled.

Update: Exchange 2010 SP2 RU4 introduces the ability for the Managed Folder Assistant to process calendar and task items for the first time. So after you update to Exchange 2010 SP2 RU4 or later, you run the risk that users will see their calendar and tasks folders cleaned out, which isn’t nice. Pay attention to the advice in the article to disable this behavior until you’re ready to unleash the full power of the Managed Folder Assistant. Note that no client exists – even Outlook 2013 – that allows users to manipulate retention policies for the calendar and task folders. The UI simply doesn’t exist.

For those running Exchange 2013, exactly the same degree of care has to be taken when you enable an archive mailbox and so automatically apply the default retention and archive policy. There is a small difference in that Exchange 2013 calls its default retention policy the “Default MRM Policy” but it has the same effect on mailboxes when applied.

For more information about points that need to be considered for a successful deployment of Exchange 2010 archives plus the workings of the MFA, see chapter 15 in Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site. The topic of retention policies and tags is also covered in chapter 11 of Exchange 2013 Inside Out: Mailbox and High Availability.



Viewing all articles
Browse latest Browse all 4

Trending Articles