Exchange 2010 compliance at Exchange Connections


I’ve already published an article about the news about Microsoft’s PST capture tool that Ankur Kothari shared at the Fall 2011 Exchange Connections in Las Vegas. Here I’d like to record some of the interesting observations and Q&A interchanges that occurred at the session. In passing, the deck that was used in this session is similar to that posted here.

The session was attended by about 120 people. Ankur asked how many were planning a PST eradication project in the next year. I was surprised that about 50% raised their hands. I’m not surprised that PSTs should be eradicated as this is absolutely the right long-term strategy to pursue. I’m just a tad taken aback that such a high number are actively embarked on such a strategy. Perhaps this was a proactive crowd.

On Office 365, Ankur noted that Single Item Recovery (SIR) is enabled by default for all mailboxes. SIR means that all changes to deleted items in a mailbox such as attempts to purge the items or to edit their contents will be tracked by Exchange for the retention period that’s specified. In this case, Office 365 uses a retention period is 14 days. On-premises Exchange 2010 mailboxes are not enabled for SIR by default. You have to enable mailboxes explicitly by running the Set-Mailbox cmdlet. For example:

Set-Mailbox -Identity Tony -SingleItemRecoveryEnabled $True

The retention window is configured per-mailbox or per-database. For example, if I wanted to set a retention period of 365 days for a mailbox, I’d run a command like:

Set-Mailbox -Identity Tony -RetainDeletedItemsFor 365

Whereas for a mailbox database I’d use a command like:

Set-MailboxDatabase -Identity DB2 -DeletedItemRetention 365

Of course, expanding the deleted item retention period (for a database in particular) increases the storage requirement for a database and shouldn’t be altered unless necessary. It’s also worth noting that calendar items are retained for 120 days at least even if a smaller retention period is specified.

The next factoid that I learned is that Office 365 uses a Managed Folder Assistant (MFA) workcycle of seven days. By comparison, the on-premises Exchange 2010 MFA uses a one-day workcycle. The workcycle sets a goal for the MFA in terms of how often it should process a mailbox to stamp items with retention tags and action items whose retention period has expired. I guess it’s logical that Office 365 would want to minimize the amount of processing load that MFA imposes on mailbox servers but a 7-day workcycle does mean that items in mailboxes might not be processed as quickly as you’d expect. For example, an item that you’d expect to move to the archive after 30 days might linger in the mailbox and only move after 36 days. A small point to keep in mind.

It’s logical but might escape some that retention policies have to be maintained in two places if you operate a hybrid on-premises/cloud environment. For on-premises Exchange 2010, retention policies and tags are maintained in the Exchange configuration data in Active Directory and are not shared with the cloud. Therefore, if you’ve created a set of retention policies and tags to enforce compliance, you have to duplicate them in both places.

Some scripts are provided on the Exchange 2010 kit that can help, even if the ongoing synchronization will be a manual process. Details of the scripts can be found in the deck referred to above. As per this TechNet article, the magic that assures that both policies are deemed to match is having a similar RetentionId property. Having the same policy and tag occurs automatically in at least one instance. If you enable an archive mailbox for an on-premises user, their mailbox is assigned the “Default Archive and Retention Policy”. This policy is the same on both sides of the cloud divide so it follows that the policy can be implemented consistently. Before you rush to implement archive mailboxes and their associated retention policy, you might like to read this post.

If policies are not identical on both sides, mailboxes that are moved to Office 365 cannot maintain the tags that the on-premises MFA stamped on them. The tags are removed by MFA when it processes the Office 365 mailbox for the first time because MFA cannot resolve the tags (this is the same behavior that exists when you delete a retention tag from on-premises Exchange). All of this means that it’s important the same policies and tags are available on both sides else the Office 365 MFA cannot apply them to the newly arrived mailbox.

Ankur was asked whether it’s possible to apply a retention tag with a transport rule to an outgoing message as it passes through the transport system en route to another domain. The answer is “no” and again it’s pretty logical as Exchange has no knowledge of what kind of target domain you’re sending to and anyway, it’s only Exchange 2010 that would have any chance of understanding and applying the retention tag on arriving items. Also, would you like if an external organization had the chance to apply retention policies to items under your control? The real answer here is that if you want control over outgoing items you’ll have to use Active Directory Rights Management Services to apply templates and then hope that the receiving servers can understand and respect the restrictions.

The question was posed whether Exchange 2010 discovery searches can generate a manifest (perhaps in XML format) of all items discovered by the search so that this can be included in a PST (generated by the New-MailboxExportRequest cmdlet) and provided to a legal investigator. Again the answer is no. Exchange captures items that satisfy search criteria in the target discovery search mailbox and it’s up to you to decide how to process them from there on. I’m sure that someone clever could use Exchange Web Services to scan the discovery search mailbox and enumerate the items retrieved by a search to create a manifest – maybe this has already been done elsewhere or perhaps it’s a feature of one of the third-party compliance products that now compete with Exchange.

Ankur was asked how to migrate items from a third-party archive to Exchange 2010. The answer was that some products include the ability to restore items from their archive into user mailboxes. If this is possible, then the user can move the recovered items into the archive or let Exchange do this automatically through archive tags in a retention policy. The alternative is to use products such as those available from Transvault to move data directly from the archiving solution to Exchange 2010.

An interesting question was how best to export data from a discovery search mailbox on Office 365? The problem here is that the New-MailboxExportRequest cmdlet is not available to Office 365 administrators, probably because the cmdlet depends on the ability to access a network file share where it will create the PST to hold the exported data. Of course, Office 365 doesn’t have access to network file shares in your environment so it can’t write out the data. So you have to revert to the age-old answer of using Outlook as an intermediary. Connect Outlook (2007 or 2010 – 2003 can’t connect to Office 365) to the discovery search mailbox where the data is located and drag and drop to a local PST and then provide that PST to whoever needs it. A kludge, but it works.

An interesting session, if only because of the Office 365 gotchas that I hadn’t really considered up to now.

- Tony

About these ads

About Tony Redmond

Exchange MVP, author, and rugby referee
This entry was posted in Cloud, Email, Exchange, Exchange 2010, Office 365, Outlook and tagged , , , , , , . Bookmark the permalink.

3 Responses to Exchange 2010 compliance at Exchange Connections

  1. Dan Clark says:

    Interesting article, thanks Tony. it is worth noting that TransVault Migrator has the ability to export the discovery mailbox from Office 365 – as well as any other Mailbox or Personal Archive. Great if you want the power of the cloud – but want to replicate your data onto backup storage under your control!

  2. agelessgeek says:

    Hey Tony, Another great Article! I think that you can actually receive a “manifest” while doing searches in Exchange 2010 SP1 by choosing the option to “Enable Full Logging” under the Results area of the search. You will always receive a message in the root of your search folder that lists all of your search parameters for each search that you do. If you choose to enable the full logging, you will also recieve a zipped CSV file as an attachement to that message that will include an inventory of all of the messages that were included in the search. You could easily open this in Microsoft Excel and save as an XML file if required.

    • Thanks for your comments. While the logging is useful, I am not sure that it is quite what the questioner meant when he asked about a structured manifest as the expectation was that Exchange should be able to output something that is formatted in such a way that it would make sense to a regular human being such as a lawyer who has to figure out whether the search has uncovered something. But it’s certainly something that they could play with (the CSV file, I mean).

      TR

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s