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
