Introduction
During a migration of Public Folders from Exchange 2010 (Legacy Public Folders) to Exchange 2016 (Modern Public Folders), an situation occurred where the Public Folder migration would not complete properly as the migration batch for PFMailbox1 would fail. The error received was ‘Error Unexpected Mailbox State. This is a very non-descript error with no real information to go on:
Typically the very first Public Folder mailbox is the holder of the primary hierarchy for Public Folders and every other Public Folder mailbox holds a secondary copy of the hierarchy. The initial configuration and setup of the new folders was done following Microsoft’s article on this scenario:
https://learn.microsoft.com/en-us/exchange/collaboration/public-folders/batch-migration-from-previous-versions
Now, when the error occurred, attempts were made to reset the hierarchy or restart the migration job with the same end result. During a troubleshooting session, we reviewed the hierarchy settings. The one-liner that was run was:
Get-Mailbox -PublicFolder | Ft Name, *Hier*
Resulting in this output:
Note that for some reason, PFMailbox2, which should be the holder of a Secondary Hierarchy, is not configured correctly. IsExcludedFromServingHierarchy and IsHierarchyReady should both be set to ‘False’ as a secondary hierarchy owner. Even a Primary Hierarchy owner (PFMailbox1) should not be set this way, and should have the IsExcludedFromServingHierarchy and IsHierarchyReady values set to ‘False’ / ‘True’ in that order.
Solution
In order to correct this issue, we needed to follow these steps:
(1) Remove the existing Public Folder Migration (‘PFMigration’ is the name of the migration, change this text to whatever yours is called.)
Remove-MigrationBatch -Name PFMigration
(2) Remove Public Folders
Get-Mailbox -PublicFolder | Remove-Mailbox -PublicFolder
(3) Remove mailbox database that contained the original Public Folder mailboxes: (‘PublicFolders’ is the name of the mailbox database containing all Public Folder mailboxes.)
Remove-MailboxDatabase PublicFolders
(4) Create new database for Public Folder mailboxes
New-MailboxDatabase -Name "PublicFolders" -EdbFilePath 'D:\databases\PublicFolders\PublicFolders.edb' -LogFolderPath 'f:\logs\PublicFolders'
(5) Manually create new Public Folder mailboxes (CSV File contained in our case 27 Public Folder mailbox names
$CSV = Import-Csv c:\files\publicfoldernames.csv Foreach ($Line in $CSV) { New-Mailbox -PublicFolder $Line.Name }
(6) Create new Public Folder migration
New-MigrationBatch -Name PFMigration-New -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server <Server Name>) -CSVData ([System.IO.File]::ReadAllBytes('c:\files\foldertomailboxmappath.csv')) -NotificationEmails <your email address>
After these steps the migration for Public Folders completed successfully and we had Public Folders on the Exchange 2016 servers. When rechecking the hierarchy prior to completing, we were able to see a much different picture
Get-Mailbox -PublicFolder | Ft Name, *Hier*
We can also confirm which mailbox ended up with the primary hierarchy:
$GUID = [string](Get-OrganizationConfig).RootPublicFolderMailbox Get-Mailbox -Identity $GUID -PublicFolder
Alternate Solution?
In theory the IsHierarchyReady property could be changed so that PFMailbox2 could be set to False (like we had in the correct set up screenshot above), but it is not supported according to Microsoft:
“Note: While IsHierarchyReady value can be manually forced to True using PowerShell, this is not supported”
Source: https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-public-folder-deployment-best-practices/ba-p/606172
Conclusion
While researching this issue, we continually ran into articles where other people experienced the same issue when Public Folder mailboxes were created via the included Microsoft script. Their solution ended up being like the one we deployed as well. Now, typically when creating mailboxes for a migration, I have create these mailboxes without the Microsoft script and have not seen this issue. I cannot comprehensively say this is THE issue, but, I will not be creating Public Folder mailboxes via Microsoft scripts for the foreseeable future. But, if you have or do, just verify your hierarchy looks similar to the last screenshot above as this appears to the correct configuration.