Introduction
During a recent migration where a client had just completed moving Public Folders from Exchange 2010 to 2016, we began the process of migrating Public Folders to its final home in Exchange Online. With so many other roadblocks out of the way, the path from Exchange 2016 with Modern Public Folders to Exchange Online, which also has Modern Public Folders, seemed like such a simple move. Confidence in this move was high after having moved Public Folders to Exchange Online many times. However, as we learned with this move, sometimes you need to read the fine print, or in the case of Public Folder, make sure to read the ‘Known Issues’ segment of Microsoft’s documentation for migrating Modern Public Folders.
Known Issues
After working in IT for a couple decades now, I’ve come to expect bumps in the road and Public Folder migrations can have their fair share. In general these issues occur, we find a workaround and we move on. If you are involved in a large Public Folder migration, make sure to read the known issues portion of the documentation.
The issue we ran into had to do with the large number of folders that were present. Although to be fair we ran into a size issue where one Public Folder was 75 GB – now in remediation to hold a years’ worth of content – which was reduced in half. A large number of Public Folders can be relative, but to Microsoft this means over 10,000 Public Folders for a Modern Public Folder migration. Our environment had in excess of 20,000 folders.
Why does this matter?
According to Microsoft’s documentation, when there are more than 10,000 folders, there are also over 10,000 Dumpster Folders that are present. The Dumpster Folders are present in the Non_IPM_Subtree. Thus if we have over 20,000 Public Folders, we have over 20,000 Dumpster Folders and can be verified with PowerShell as part of a healthcheck if you want to do so:
(Get-PublicFolder -GetChildren "\NON_IPM_SUBTREE\DUMPSTER_ROOT").Count
What is funny is that in such a large environment, that cmdlet will not provide the correct number of folders because we can only list the first 10,000 subfolders! We need to add -ResultSize Unlimtited to get a true count:
(Get-PublicFolder -GetChildren "\NON_IPM_SUBTREE\DUMPSTER_ROOT" -ResultSize Unlimtited).Count
Sample list of all Public Folders:
Experience Without Changes
If you did not see this in the documentation, how would you know that this is an issue? First, each of your individual Public Folder migration users (one per Public Folder Mailbox) would fail. Each will fail until they ALL fail. To see the failures, we can use two cmdlets to pull stats, combined with a pipe:
Get-MigrationUser
Our migrations will appear to have failed:
To retrieve the logs, we needed to run this for one or more Migration User’s or destination Public Folder Mailboxes:
Get-MigrationUser PFMailbox1 | Get-MigrationUserStatistics -IncludeReport | Fl Report
Reviewing the logs for one of these Migration Users, we see this:
Options
According to Microsoft we have two options. Both options include removing the old failed migration so we can start over. Only one is currently actionable as it allows for the migration to proceed while the other is reliant on a future Microsoft migration allowance. So again, here are our options:
- Wait for Microsoft to unblock this as an issue
- Add a switch to the New-MigrationBatch cmdlet, excluding Dumpsters from the migration.
From Microsoft’s documentation:
For our migration, we used this code to successfully kick off the migration:
$GUID = (Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid.GUID $Source_Credential = Get-Credential Domain\AdminAccount $Source_RemoteServer = "mail.domain.com" $Bytes = [System.IO.File]::ReadAllBytes('FolderToMailboxMapPath.csv') $PfEndpoint = New-MigrationEndpoint -PublicFolder -Name PublicFolderEndpoint -RemoteServer $Source_RemoteServer -Credentials $Source_Credential New-MigrationBatch -Name PublicFolderMigration-D -CSVData $Bytes -SourceEndpoint $PfEndpoint.Identity -SourcePfPrimaryMailboxGuid $GUID -NotificationEmails 'it@domain.com' -ExcludeDumpsters
After getting the migration successfully kicked off, make sure to monitor it with PowerShell to see if there are any more failures:
Get-MigrationUser | Get-MigrationUserStatistics | Sort PercentageComplete | FT Identifier,SyncedItemCount,BytesTransferred,PercentageComplete,Status,TotalInProgressDuration
Hopefully these all enter a synced state for a future cutover.
Conclusion
While my client decided to move forward with the migration without the Dumpster data, make sure to read the documentation on what this entails. In 99% of the cases, this may not be an issue as long as the migration is relatively quick. However, for a prolonged migration where the decision to make the switch at the end, this may not be an ideal scenario for some companies. I have reached out to Microsoft just to see if they have any further information on their future remediation plans for this scenario. If you are having a similar dilemma, feel free to comment on the post on your experience and outcomes for this scenario.
Further Reading
Comments? Questions?
Feel free to leave your Comments below! Learn to more efficiently utilize PowerShell to manage Exchange Server, Exchange Online, Microsoft Defender for Office or Microsoft Purview Compliance portals by picking up frequently updated eBooks: