Exchange 2010 SP1 introduces a new cmdlet set to handle mailbox export requests to avoid the previous requirement to install Outlook on mailbox servers. With SP1 you can run the New-MailboxExportRequest cmdlet to create a request for the Mailbox Replication Service (MRS) running on a Client Access Server (CAS) to export data from a mailbox to a PST located in a file share that is protected from prying eyes by the Exchange Trusted Subsystem security group.
Much the same approach is taken for mailbox import requests. In this instance, you create an import request with the New-MailboxImportRequest cmdlet to instruct MRS to access data in a PST located in a file share and import the data into a target mailbox.
It seems clear that Microsoft is steadily moving toward using the MRS as the fulcrum for mailbox maintenance operations. It therefore comes as no surprise that the mechanism used for mailbox export and import requests shares some of the maintenance issues that afflict mailbox move requests, which were the first operation moved to MRS in Exchange 2010. Mailbox export and import requests accumulate and are not cleared out automatically even when they are successful. There is no aging mechanism either whereby Exchange might clean up old requests after they exceed a set limit such as 30 or 60 days. The logic might be that it is possible that you want to retain export or import requests as proof that a certain operation occurred.
The upshot is that you therefore should remove old requests periodically. This is much the same basic housekeeping that you have to perform for mailbox move requests as described in this post.
The appropriate way to do this is to run the following commands to clean up old import and export requests that have completed successfully (make sure that you are sure that you don’t want to keep any requests for whatever reason before you execute these commands).
Get-MailboxImportRequest -Status Completed | Remove-MailboxImportRequest
Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest
Some administrators perform mailbox exports before they delete mailboxes to be sure that all of the mailbox content is accessible should the need arise. Others opt to hide the mailbox and disable the Active Directory account and are happy for the mailbox content to stay in the database for a month or so before they delete the mailbox. Whatever approach you take, you won’t be able to remove old mailbox import or export requests if you delete the Active Directory account beforehand. This is because Exchange uses some Active Directory attributes to link the mailbox to the information MRS maintains about requests so you’ll end up with a “lingering” or “orphan” export or import request if you delete the Active Directory account before you clean them up.
Microsoft acknowledges that this is a bug and code will no doubt appear in the future to manage orphan import and export requests a tad better. In the meantime, the sequence is:
- Export the mailbox and check that the export request completed successfully (use the Get-MailboxExportRequestStatistics cmdlet with the -IncludeReport parameter)
- Check that all is well with the data exported to the PST (open the PST and validate the contents)
- Remove export requests for the mailbox with the Remove-MailboxExportRequest cmdlet.
- Delete the Active Directory account and mailbox. This can be done with the Remove-Mailbox or Remove-StoreMailbox cmdlets. Remove-StoreMailbox is new for Exchange 2010 SP1 and is used to remove a mailbox from its database immediately.
MRS is certainly a central player for Exchange management going forward. For now, it works very well in most circumstances and issues like this are just minor tweaking. For more information about how to export mailbox data with Exchange 2010 SP1, see pages 758 to 760 in chapter 12 of Microsoft Exchange Server 2010 Inside Out
– Tony
Follow Tony @12Knocksinna
Thoughtsofanidlemind's Blog 
Pingback: Esportare ed importare posta in Microsoft Exchange 2010 Sp1 | sandeisacher
Okay, so what happens in a dial-tone recovery situation, where you have a large number of import jobs which were related to the previous database…
you can’t remove them, because you can’t connect to the old DB, but you have issues creating new ones, because of the old fluff hanging around?
Where does MRS keep it’s queue, and is there a way to “force” the removal?
What you’re describing is a situation where we have “orphan” requests. MRS maintains details of move requests in the system mailbox of the target database. These data are in the form of XML blobs that inform MRS about the parameters of a move request (mailbox being moved, source and target databases, bad item limit, and so on). Other information about a move is held in the Active Directory object for each mailbox that is being processed – data such as move status. MRS treats a move request as complete if the XML data and the Active Directory data are available. If one or the other is unavailable then the move request is “orphaned” and will be either removed (XML data exists but no corresponding AD data) or the move request will be failed (AD data is present but system mailbox has no XML data) after 24 hours. So, your “old fluff” should disappear roughly 24 hours after the dial-tone database recovery is complete.
TR
I am getting the same error when doing importing part. some times it goes up to 50% of importing and suddenly it says Failed. then when i ran the same command again to import the pst to the same mailbox then it goes up to 10% and get failed. Why is this?
Did you check the full import report to discover whether there are any bad items in the PST that you are attempting to import?
You can always increase the bad item limit and retry…
TR
I am not sure if I am highjacking this thread but my issue is realted to an ‘orphaned requestjob’. I tried moving an Exchange 2007 mailbox to Exchange 2010 and the job just vanished with not logs to indicate a problem. Subsequent attempts to move the mailbox fail but I can see the following information that indicates the initial, failed moved left a ‘ghost’ mbx in the destination db:
VERBOSE: [01:36:35.588 GMT] New-MoveRequest : [WARNING] Orphaned RequestJob: AD user USER DISPLAYNAME is not
being moved.
I have performed cleanup db to list disconnected mbx., querying the move history from account returns null results. I dont’ know how to cleanup that orphaned request. We have 5000 more mbx moves and I need to find the solution in case we run into the same problem.
An orphaned move request is one where data exists for a request in either the system mailbox or the mailbox’s Active Directory user object. Exchange needs the two sets of data to be in sync to have a complete move request so if one is missing, it’s deemed to be an orphan. Orphaned move requests are cleaned up automatically and should be eliminated after 24 hours or thereabouts. In the meantime, you could try to remove any lingering traces of a move request for a mailbox by running the command:
Get-MoveRequest -Identity mailbox | Remove-MoveRequestTR
Pingback: Butsch.ch | Powershell Links for Exchange 2007/2010
Hello,
I have created script to remove mailbox export request but it asks “[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is “Y”):” and script don’t run as I want to use it as a schedule task. Can anyone please give me the correct command to do this?
e.g. I want to remove all completed export request using bellow script. What should I add in below script so it can remove all completed request without pressing “A” in powershell.
Get-MailboxExportRequest | where {$_.status -eq “Completed”} | Remove-MailboxExportRequest
Thanks,
I got this working using bellow command.
get-mailboxexportrequest -status completed | remove-mailboxexportrequest -confirm:$all
Thanks,
Try adding -Confirm:$False to the Remove-MailboxExportRequest call.
Just updated to 2010 SP2 with Rollup 4v2. I had a script written which took output from Get-MailboxExportRequestStatistics and used the property SourceAlias to do additional work like Get-ADUser etc. After the update my script broke. In testing I found that while the Export Request is running the command does return the SourceAlias. But when it is not running and is completed that property is null. There is another property called SourceMailboxIdentity but that does not work for the Identity for Get-Aduser. But I can now pass SourceMailboxIdentity into Get-User and then read the Distinguished Name from that for the rest of my commands. Just thought I’d post in case anyone runs into it…
Hi Dave,
Thanks for sharing. I have no idea why the developers changed the way that they use SourceAlias but am sure that they have a good reason. Maybe it’s something to do with timing or that they have decided that SourceMailboxIdentity is a better bet going forward – in Exchange 2013 the focus is on mailbox GUIDs as the way to always go back to a mailbox no matter where it is (server, active database) and this seems like it might be an associated change. Just speculation on my part as I haven’t asked the developers.
TR
Nice thank you!