During a production Public Folder migration, a client of mine ran into multiple issues with the migration from Exchange 2010 to 2013 Public Folder. Since the entire process of Public Folder migration is done with PowerShell, how would you know if the migration is held up or crashed or had issues? PowerShell.
OK. So now back to the client and their issues. The first five steps of the migration went well (Microsoft Public Folder migration document). Once the migration was started, we decided to monitor the progress every 5-15 minutes to see if there were any issues to be resolved. To check the migration, we used a condensed PowerShell one-liner to get the information we needed:
- Get-PublicFolderMigrationRequest I Get-PublicFolderMigrationRequestStatistics -IncludeReport I ft name,status*,*transferred*,percentcomplete -auto
After 15 minutes, when were checking the status of the migration we noticed that the migration status showed as failed. To get information on what had failed, we modify the PowerShell script to use ‘fl’ (format list) instead of ‘ft’ (format table).
The main reason we do this is that if you don’t, the amount of detail revealed by ft is too small:
So now we run the command with fl:
- Get-PublicFolderMigrationRequest I Get-PublicFolderMigrationRequestStatistics -IncludeReport I fl
and get these results:
As you can see, we have issues with the illegal characters Alias of some Public Folders. After investigating the ones with issues, it appears that the folders in question have spaces either leading, trailing or otherwise. How do we get rid of the space? First, lets verify the groups have these characters:
- $pfs= Get-publicfolder “\” -recurse | where {$_.MailEnabled -eq “True”} | Get-MailPublicFolder | where {$_.alias -like ‘* *’ -or $_.alias -like ‘*,*’}
- Running it will result in a screen similar to this:
After the issue is confirmed, run this command to remove the spaces from the Alias.
- foreach($pf in $pfs) {set-mailpublicfolder $pf.Identity -Alias:($pf.alias -replace ‘\s|\,’,”)}
Once the offending groups were corrected, we resumed the migration:
- get-publicfoldermigrationrequest | resume-publicfoldermigrationrequest
Once the migration resumed, we carefully monitored the migration to make sure no other errors occurred. After about an hour or so, the migration stopped again.
- We ran the one-liner to check for more detail on the error:
- more on the error:
As you can see, we hit a bad items limit for the Public Folder migration. Let’s increase the limit and resume the migration:
We get an informational warning about raising the limit is not always recommended due to data loss.
If we look at the complete log for a migration, up to the autosuspend part, there is quite a bit of information about what is going on:
In the red circled areas you can see some of the errors that could occur in a typical production migration of Public Folders. From fatal errors (in our case spaces in PF aliases, to corrupted items, even Transient errors which self correct (note the retry (1/60)) as well as the fatal error about too many bad items. All of this information is revealed with the ‘ -IncludeReport’ switch with the Get-PublicFolderMigrationRequestStatistics command we use to monitor the migration.
Well I hope this article will help you troubleshoot any errors you get with migration of your Public Folders to Exchange 2013.
Related Resources
Get-PublicFolderMigrationRequestStatistics
Get-PublicFolderMigrationRequest
