At a former position, we wrapped up our email migration to Office 365. The mailbox migration itself was smooth and very textbook, but then there was Public Folders https://youtu.be/cphNpqKpKc4 that needed to be migrated. I am not talking about a few Public Folders either, the company has approximately 600 Public Folders, 80 are mail enabled, 300 GB of data, and the whole company revolves around these Public Folders for processing clients orders. Messing this migration up would directly affect my clients bottom line, to the tune of millions of dollars. Keep in mind, I inherited this infrastructure so I had to make the best of it, which typically involved re-architecting the existing infrastructure to bring it up to best practices just so I could get it migrated to Office 365.

For the most part, I was able to follow this article from Microsoft and it worked just fine: https://technet.microsoft.com/en-us/library/dn874017(v=exchg.150).aspx. However, when we got to actually migrating the data, the migration for one of the Public Folder Mailboxes failed with an error similar to the following:

Error: MigrationMRSPermanentException: Error: there are X mail public folder(s) that were not linked to any public folder during migration.

And then log proceeded to list 15 Public Folders with this issue. I looked into these Public Folders and upon further inspection, there were some old, legacy system mailboxes left over from an Exchange 2007 migration to 2013 that were still hiding. Apparently what had happened is one of the people before me did not know much about Exchange and did just enough to get the Public Folder migration from Exchange 2007 to 2013 complete, then just “turned off” the Exchange 2007 server and forcefully removed it from the domain. I figured I will clean that mess up later, I needed to get the Public Folders migrated so I issued this command on every Public Folder with the error above:

Get-MailPublicFolder -identity <Public Folder>| Set-MailPublicFolder -IgnoreMissingFolderLink:$true

This allowed me to continue the migrations without errors.

After a week of successful delta migrations, I decided that it was time to continue on with the migration. So I continued on with the document and everything was going along nicely until this step, where you have to lock the Public Folder Mailboxes for new connections:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

Issuing the command just threw all sorts of errors. I started to investigate the errors and came up with the idea that the error was being caused by issues with the Exchange Management Shell. Therefore I started up a generic Powershell session and issued the following commands:

get-pssnapin -Registered|add-pssnapin   (which gets all the registered snap-ins and adds them to the current session)

Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections:$true

Guess what? My suspicions were right and it worked. The Public Folders were not accepting any more connections and I could continue with the migration.

Over the course of the next 24 hours, the migration continued. The actual data migration happened much faster than that, but there were issues on Microsoft’s side that could not complete the migration. In a timely manner, so all I could do was sit and wait. When the migrations were finally complete, I continued to issue the final few commands. I got to this command and guess what:

Set-OrganizationConfig -PublicFolderMailboxesMigrationComplete:$true -PublicFoldersEnabled Remote

Issuing the command failed, I half expected it to. So I issued the command in the generic Powershell session above, and it worked.

I then continued with the last command and completed the migration.