Importing PSTs Into Exchange Online – Part Two

In this post, I will cover the PowerShell part of the PST Import process as well as some troubleshooting steps.
PowerShell CmdLets
The basic premise of the Azure PST Import is an Exchange Online Mailbox Import Request. This means that the same cmdlets that you would use to import your PST files for on-premises Exchange now work for Exchange Online. The main difference is that your source files are stored in Azure Storage and not on a local server. Otherwise the cmdlets are the same.
For those proficient in PowerShell, I did run into an issue with PowerShell in Office 365 PowerShell. I was unable to pipe get-mailboximportrequest to get-mailboximportrequeststatistics


For the migrations you will be able to check the status of your imports:

Note that you can see the File Path –> Azure Import.:
Get more detailed information on the imports in progress:

Bad item limit / Bad items found also can be found here:

as well as the reason for any failures:

More interestingly is the report itself:

Lastly, failed or paused imports can be resumed as well:

If you are familiar with these cmdlets, then the new Azure PST Import process will be easy to work with.
Troubleshooting
(1) Can’t create the initial import job in the console?
The name for the job is probably incorrect. Read the naming convention and you will notice that all characters need to be lowercase, no spaces, etc:

Error messages:


Fix the name per the standards and go on to importing your PST files.
(2) Import cannot find the file:

• Check your file path – check your CSV file, see Step 4 for Azure Storage Explorer to validate paths as well.
• Case is correct – check your CSV file, see Step 4 for Azure Storage Explorer to validate paths as well.
• Correct rights? – You need the Mailbox import / export rights to do so, see my previous article on Azure PST Importing
• If this is a retry, rename the PST file, change the CSV file and then try the import and copy again.

(3) Reading the AZCopy log file (make sure you create the log file!):
* Possible error messages:
(a) “The remote name could not be resolved: ‘.blob.core.windows.net'”

• Check you path, make sure the URL is the same as the one provided by the wizard as the one in your PowerShell cmdlets.

(b) Error messages similar to this:
“The remote server returned an error: (403) Forbidden.
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
[2015/08/24 11:38:33.928-05:00][ERROR] Microsoft.WindowsAzure.Storage.DataMovement.TransferException: The remote server returned an error: (403) Forbidden.
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.”
Notice there is a mention of forbidden, check the Authorization header … There are a couple of possibilities here. One the time on your import server is off. If you are using AZCopy to copy your PST files to Azure, then your clock could be off. The timing needs to be close similarly like on your local LAN. The other possibility is you are using the wrong information for your unique code. Recheck this, check the server clock and try again.
(4) Bad item limits
Just like an Exchange migration, PST Imports are limited to the number of failed or corrupt messages that can be skipped in the process. The number is over 200 for an Azure PST Import and appears to be around 218 ish. I recently had a large number of PST files to import and had two of them fail with this issue. What is strange is that if you look at the status of the import it stated that it completed. But if you check the status of the files, it will show “In-Progress”. Then click on Download for the Error Report information and something like this will appear:


The fix for this is to log into your Office 365 tenant and changing the value for bad items to something much higher. In my case we had to change it to a very large number as we had already hit a 218 / 219 bad item limit for the imports:

To fix this, adjust the limit higher:

# Find the failed jobs
get-MailboxImportRequest -status failed

# Increase the limits
Set-MailboxImportRequest -BadItemLimit 1000 -Identity 2f516d11-7092-4dd2-84f4-10fcc392f29a

# Resume the import request
Resume-MailboxImportRequest -Identity 2f516d11-7092-4dd2-84f4-10fcc392f29a

(5) Validating files are in Azure Storage?
To do this we need to get a third-party app that is currently in Preview. A bit of searching on the Internet provides us with Azure File Storage viewing like the Azure Storage Explorer.
Installation is a breeze:

Once installed, you can add your Azure Storage account using the same unique key and URL. For the Storage Endpoint, leave the core.windows.net. For the Storage Account name you need the unique ID on the URL that was given to you with https://.blob.core.windows.net. The are what you need.

Comments and Notes
I think the reporting interface could be better as I noticed that I did not get a chance to download a report for some jobs that had failed. Others I could. Also the reporting of a completed status, but finding the job not complete is a bit confusing:

To fix the job, find out what is wrong using the get-mailboximportrequeststatistics -includereport command.
Further Reading
Azure Storage Troubleshooting