At the end of the last year we had a request from an existing customer to export the content of a few mailboxes they had hosted on O365 servers. In this O365 PST Export post I would like to share what we have learned and the most appropriate solution in our case.
The customer did not want to get technically involved into this migration. We specified the parameters for the exports and they gave us an admin account for their O365 tenant.
First I would like to point out that the solution or workaround we have used here is only appropriate for a smaller number of mailboxes, since manual interaction is needed.
The whole experience :
Prepare an account on source side with FullAccess to all mailboxes Solution
We have created a migration user in O365 with mailbox and granted FullAccess permission on all mailboxes in the customers O365 tenant.
It is faster to do this via remote-powershell. Connect and enter your credentials :
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “https://outlook.office365.com/powershell-liveid” -Credential $credential -Authentication “Basic” -AllowRedirection
Once logged in grant FullAccess on all mailboxes to the migration user without Automapping.
Do not activate Automapping because we will use Outlook for a proper O365 pst export.
O365 pst export via GUILearned
To bring it straight to the point. The outcome of this method didn’t fit our needs in any way. An eDisocvery will be performed and the results will be available for download in .pst format.
Unfortunately these .pst files have a folder structure beginning with the mailboxname , one level down you find ( in our case ) an ApplicationDataRoot folder and the Top Of Information Store folder. The real mailbox structure begins here :
It would be confusing to anyyone to adapt these folder structures on the target mailboxes.
Since this method did not provide a real solution I will not go into details on how to make an O365 pst export via GUI.
Connect migration mailbox via Outlook and export mailboxes Solution
This step is the main part of the solution and why I mentioned at the beginning that it is only suitable for few .pst exports. We have connected the mailbox of the migration user via autodiscover and an Outlook 2016 client. This was the host for the evening 😉
The next step was to disable Cached Mode. Outlook should be in online mode to prevent data loss through synchronization issues. This is also the cause for disabling Automapping. Outlook limits the auto mapped delegate mailboxes to 10 ( we had over 20 ). Further would Outlook have been overwhelmed with so many shared mailboxes in online mode.
After this we manually mapped the 1st mailbox to export ( Online Mode ! Important ! ) within the profile of the migration user. You can check the folder sizes on the server via right click on the root of the mapped mailbox > Outlook Datafile Properties. Depending on the size of the source mailbox the O365 pst export can take an extended amount of time. The O365 server provided a good performance in download speeds but some mailboxes were about 18 GB.
We have experienced 2 or 3 connection losses to the O365 server at our first test. The final migration took place on a weekend. There were no further problems then.
Export the O365 mailbox via Outlook to a pst file :
Additionally Export Calendar as PSTSolutionLearned
In our tests we noticed that after an O365 pst export has been imported into the new target mailbox , there were no calendar entries. When querying the import request statistics with -includereport it turns out that all calendar entries have been treated as corrupted items. ( which counts against the bad item limit ). So the mailbox-importrequest needs to be triggered with a high bad item limit and -AcceptLargeDataLoss or the calendar needs to be excluded from the import request.
To only export the calendar repeat the steps shown in the screenshots under point 3. Choose only the the calendar instead of the whole mailbox. When the calendar has sub folders ( what most likely is the case ) keep “Include subfolders” ticked.
We made these exports available for download to to the customer. End users were then able to map only the small calendar pst into their Outlook Client and drag the relevant items into their new mailbox calendar.
Import the O365 PST export to the target mailbox Solution
In compliance with the customer we have chosen to raise the bad limit in the mailbox-importrequest. The detailed import logs were provided to the customer as well. We use the -Priority Emergency switch to prevent an import request from stalling like described here
New-MailboxImportRequest -Name IndivudalMailboxName -BatchName NameOfTheBatch -FilePath \\Server\Folder\NameOfPST.pst -Mailbox TargetMailbox -BadItemLimit 10000 -LargeItemLimit 10000 -AcceptLargeDataloss -priority Emergency
Track the import request with :
Get-MailboxImportRequest -name IndivudalMailboxName | Get-MailboxImportRequestStatistics -IncludeReport | fl report, *transfer*, bad*, *status*,percent*, *failure*
Copy the full report to the clipboard so that you can insert it into a text file :
Get-MailboxImportRequest -name IndivudalMailboxName | Get-MailboxImportRequestStatistics -IncludeReport | fl | clip
Export and Import the next mailboxSolution
Close the mailbox – you just have exported and imported – in Outlook and map the next mailbox into the profile of the migration user. Repeat steps to
I hope this helps should you face the same problem with an O365 pst export.
If you know a more efficient way , where the effort fits the benefit , it would be nice to hear it. I know this is not the most elegant way to do this. But there was no other choice for this small quantity of mailboxes.
Have a nice day !