The Tale of the Stubborn Public Folders

I had a rather meager set of legacy public folders that I was tasked to migrate to Exchange Online, with the single database weighing in at under 5GB.  What was peculiar was the large number of folders and the percentage that were mail-enabled.  The first set up challenges were cleaning up the folder names and mail aliases that had invalid characters (like a folder with a “\” in its name… not so good).

I got all of these names and aliases cleaned up and started the migration according to the steps outlined in the batch migration method on TechNet.  Things were going well, until they weren’t going so well… as they do.  I bumped up the BadItemsLimit and it got a little further.  After much reluctance, I opened a ticket with Microsoft where they eventually determined that there was a service interruption.  This lasted for several weeks.

Finally, the service interruption was cleared.  So, I restarted the migration from scratch and it reached a state of “Synced”!!!

Okay, so I get approval to perform the cut over to Exchange Online, and it fails.  The ErrorSummary reads: “Error: There are 5 Public Folders that could not be mail-enabled. Please, check the migration report starting at…”

Okay, fantastic.  There are no details to be found as to which public folders could not be mail-enabled.  The worst part is, that over 1/3 of all of the sizable number of public folders happened to be mail-enabled.  I happened upon an article that suggested it could be because of mail-enabled folders in the \NON_IPM_SUBTREE space, so I figured I could address that:

I proceed to resynchronize the folders and start the job.  It syncs again, so I follow the steps to cut over again, and it fails… same thing.  Buried in the previous article is mention of a script and an attached article that explains some common issues.  Mainly, that some inconsistencies exist in the mail-enabled public folders.  The script essentially documents some settings, mail-disables the public folders and then mail-enables them again.  That’s great, but the script doesn’t work for me.  It is rather large and seems rather complicated.  So, I decide to just identify if there are certain inconsistencies by borrowing some logic from the script.  First, I use ExFolders to export the list of public folders with the DS:proxyAddresses, PR_PF_PROXY and PR_PF_PROXY_REQUIRED fields.  I cleanup the header row on the resultant tab-delimited file so it reads: FolderPath, ProxyAddresses, PR_PF_PROXY, and PR_PF_PROXY_REQUIRED.  Then I import the file and find all of the folders that have PR_PF_PROXY_REQUIRED set to True, but don’t seem to have valid proxy addresses:

Success!  Five folders were found.  Since these obviously weren’t working (they don’t have any proxy addresses), I just mail-disabled the offending folders:

I began the cut over again… and many hours later, it was still running.  It seemed like it is a good thing, because it failed so quickly.  I assumed it was because of the vast number of mail-enabled folders.  Eventually (after about 7 hours, in total), it finally completed and I finished things up.  It was a very frustrating process that took over a month of calendar time to address just due to the invalid characters and service interruption, not to mention the couple of extra days dealing with these inconsistent folders.

So, if you’re unfamiliar, a mail-enabled public folder has an Active Directory object created for it under “CN=Microsoft Exchange System Objects,<DomainName>”.  This is where the recipient attributes are set that allow it to be addressable.  Sometimes these objects develop some problems over the many years that they have existed, perhaps being migrated from as far back as Exchange 4.0 (the public folders in question were in fact from Exchange 5.5).  If the associated objects are eliminated, then it gets into this inconsistent state.  I have no idea how long it was gone, but it seemed like the rule of thumb for this organization was ,”when in doubt, mail-enable.”  So, there were likely many folders that were never used to receive messages directly.