Moving Public Folders to Office 365 – Issue 2

I simply cannot wait until Public Folders are gone. Increasingly over the years my customers have abandoned them for greener pastures. Yet, I still run into the occasional customer that has Public Folders and insists on moving them to Office 365. Moving folders to Office 365 is almost exactly the same as moving Public Folders to Exchange 2013 or 2016.

** Note ** This article refers to moving Legacy Public Folders which exist on Exchange Server 2010.

Recently I had a client that was existing in coexistence mode with Exchange 2010 and Exchange Online. The migration took a bit longer than planned with the migration of 1500 – 2000 mailboxes. At the end of the coexistence we needed to cutover Public Folder content to the cloud. We did this ONLY when ALL mailboxes were in Office 365. This is done to ensure no one loses access to the folders as an on premises mailbox cannot talk to Public Folders in Office 365.

The article to use when moving Public Folders to Office 365 is:

At the end of the article Steps 6 and 7 specifically deal with completing the cutover of Public Folder data to Office 365. You need to run specific PowerShell cmdlets to do so:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true


Complete-MigrationBatch PublicFolderMigration

The problem for the client was that the completion never worked. When run from PowerShell, we received this error:

Notice the error code of 0x80070005. This generally denotes as ‘Access Denied’. Well, that’s weird. In the Migration Batch screen for Exchange Online, the batch shows as ‘Synched’ and there were no errors.

We then tried to force completion from the Office 365 EAC and received a failure message here as well:

The migration batch log looked something like this:

Notice the same error.

Problem and Solution
It turns out that the problem stemmed from the initial creation of the Public Folder batch migration. The start of it all comes from this cmdlet which is in Step 5 of the document I referenced earlier. This cmdlet uses your Office 365 credentials to hand the migration. It turns out that those credentials are cached with this cmdlet:

Sync-MailPublicFolders.ps1 -Credential (Get-Credential) -CsvSummaryFile:sync_summary.csv

My account, the one used for Office 365 credentials, had changed passwords at least once since the migration started. Thus what was happening is that the new password was not in the stored credentials. These stored credentials were no longer valid and that is what triggers the 0x80070005 error. To fix it, we need to either reset the credentials for the Public Folder migration batch to a known good account or reset the user account used for making the original connection back to the correct password, synching this password to Office 365. The easiest thing is to update the Public Folder endpoint credentials here:

Make sure to enter a new password, save the endpoint and kick of the migration once more. It should now complete without issue.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s