Soon after writing about the need to clean out lingering mailbox move requests for Exchange 2010, I requested the developers to add the ability to remove move requests automatically after a certain period. After all, it’s a royal pain to find that you can’t move a mailbox just because an ancient move request still exists.

As I was researching new features to write about in Microsoft Exchange Server 2013 Inside Out: Mailbox and High Availability, I was delighted to discover that a solution exists in Exchange 2013. It’s taken me a while to comment about the solution, but better late than never (I guess).

If you look at the parameters for the cmdlets that control how the Mailbox Replication Service (MRS) moves mailbox data, you’ll find that they all support the new CompletedRequestAgeLimit parameter. These cmdlets are:

• New-MoveRequest (create a new mailbox move request)
• Set-MoveRequest (amend a mailbox move request)
• New-MailboxImportRequest (import data from a PST into a mailbox)
• New-MailboxExportRequest (export data from a mailbox to a PST)
• New-PublicFolderMoveRequest (move content for a “modern” public folder to a different public folder mailbox – new for Exchange 2013).

Note that the New-PublicFolderMigrationRequest cmdlet, which is used to migrate old-style public folders to their modern counterparts on either Exchange 2013 on-premises or Exchange Online, does not support an age limit parameter. This is very logical because public folder migrations can last for an extended period. Make sure that you read my notes about Exchange 2013 public folder migration if you haven’t started this process yet.

If you don’t pass a value for the CompletedRequestAgeLimit parameter, the default of 30 days is used. And once this period expires, MRS cleans up by removing the request automatically. Of course, Exchange 2013 includes the migration service and mailbox moves are now processed in batches that are controlled by the migration service, but mailbox move requests live on underneath the cover and are the prompts for MRS to move mailboxes.

Some might ask why it took Microsoft so long before they decided to auto-expire mailbox move requests. My theory is that it’s yet more evidence of the increasing attention paid to automation in Exchange 2013 that is brought about by the massive increase in scale seen in Office 365. Consider just how many mailbox moves occur between Exchange Online databases. Now consider just how much of a royal pain in the rear end it would be if all of the mailbox move requests had to be cleaned up manually. Automatic request expiration makes a huge amount of sense when you’re dealing with millions of mailboxes, just like it makes sense if you have just a few to look after.

Another interesting new parameter is Priority, which allows you to provide MRS with an indication of the importance of a job. MRS uses the priority along with other factors such as target server health (as measured by Managed Availability) to decide which job to process next. The default value is “Normal” and it extends from “Emergency” (highest) to “Lowest”.

Follow Tony @12Knocksinna