Public Folder Migration Fail #2

Another day, another Public Folder migration failure. This time, on testing your Public Folder migration to Office 365, they appear to be unavailable and are not visible in the Outlook client.

I always follow the wonderful guide provided by Microsoft on how to migrate your Public Folders from Exchange > Office 365 (I’m not being sarcastic, it is actually a good guide) available here:

The last two times I have run through this process, I have attempted to test the PF Migration on a single user prior to going live for all users. Microsoft suggest the following command for doing this:

Set-Mailbox -Identity <Test User> -DefaultPublicFolderMailbox <Public Folder Mailbox Identity>

However since the Exchange 2016 wave of Office 365 has gone live, this command no longer appears to have the desired effect. What seems to happen is that because the -IsExcludedFromServingHierarchy parameter is set to $true, the command does not fully enable the Public Folders for that user.

In both situations, I have taken the plunge and enabled Office 365 Public Folders for all users by running:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

The end result (after a little patience) is that Public Folders become available for all users. I’m not sure if this is a general bug or a result of the Exchange 2016 backend of Office 365, but I’d be interested to hear your experiences!



Public Folder Migration Fail

The above title isn’t a surprise for anybody working in IT, but unusually for Public Folders, this one has a fairly simple fix!

The situation is thus; when attempting to complete a Public Folder migration to Office 365, you come across the following error:

Before finalizing the migration, it is necessary to lock down public folders on the legacy Exchange server (downtime required). Make sure public folder access is locked on the legacy Exchange server and then try to complete the batch again.

Public Folder migration error

The problem with this error is that you have already locked down Public Folders on the legacy Exchange Server by running:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

So what’s an admin to do when they’ve already run the command they are being told needs to be run?! Some googling may lead you to the idea of rebooting the server, or restarting the Information Store. Both of these will work, but a much simpler solution is simply to dismount the Public Folder database/s, and then mount them. The PFs are already locked so are unavailable to the users so there is no negative impact of doing this.

TL;DR – turn it off, and turn it on again.


Exchange Online Public Folder Migration Fail

Today I have been migrating Public Folders (yuk!) from Exchange 2010 to Exchange Online, and have come across a slightly odd issue.

I had followed the lovely guide to Public Folder migrations provided by Microsoft here, however I could not complete my migration as the migration batch had completed with errors. The error I was receiving was as follows:

Error: MigrationMRSPermanentException: Error: There are 2 mail public folder‎(s)‎ in Active Directory that were not linked to any public folder during migration.

The Public Folders referenced in the error message were both Exchange system folders, so I wasn’t sure why it was bothering to try and synchronise them. Luckily the error message does give us a clue as to what to do;

You may also run "Set-MailPublicFolder -IgnoreMissingFolderLink:$true" for each AD object that is a legacy system folder and resume the migration

Being the silly person I am, I assumed that this command needed to be run against the legacy Public Folders On Premise, but apparently -IgnoreMissingFolderLink is not a parameter in Exchange 2010. What I actually needed to do, which is not obvious from the error message,  was to run this command in Exchange Online. I ended up using a catch all command, which looked like this:

Get-MailPublicFolder | Set-MailPublicFolder -IgnoreMissingFolderLink:$true

Once this was done, I stopped the migration batch, and then started it again. It then performed it’s initial sync and I was able to continue the migration!