Exchange 2010 Public Folder Migration

For so many years organisations have postponed the inevitable.  They have refused to clean up Exchange public folders, and content from 1996 is still present.  Those Outlook forms that someone wrote in 1999 are still present.  Stale Offline Address Book (OAB) folders and OWAScratchPad folders hang on for dear life.  None of these are needed, and its high time to remove them.

Prior to starting a public folder migration, we need to ensure that the source data is is a clean and consistent state.  In 9 out of 10 cases it is not.  Issues will exist that have been ignored for years.  But, guess what?  You cannot complete the Exchange 2010 migration as public folders are still present.  It is time to deal with it.  No more kicking the can down the road...

Public Folder Invalid Characters

Make sure the names only contain legitimate characters.  This includes the Alias and Display Name

Mail Enabled Public Folders

Mail enabled public folders (MEPF) are likely going to be a headache.  All public folders would have been mail enabled in Exchange 5.5 and Exchange 2000/2003 mixed mode.  Even though those public folder were deleted decades ago, there is very good change that stale objects are left in the Microsoft Exchange System Objects (MESO) container.  Or the expected attributes are not set on the current MEPF.

When it comes to public folders, few have more experience that Bill Long.  Bill moved his blog off TechNet as well.  These two posts are especially pertinent for public folder migrations.

Cleaning Up Microsoft Exchange System Objects (MESO)

Cleaning up Microsoft Exchange System Objects - part 2

As Bill describes in the part 2 post, the misaligned entries between what is present in MESO compared to what Exchange things should be there will likely be a remediation activity in order to move public folders to a newer version of Exchange or to Exchange Online.  He also notes an important nuance:

However, there is one other caveat to be aware of. Sometimes, public folders can have directory objects when the public folder is not flagged as mail-enabled. This is described in KB 977921. If the folder is in this state, email sent to the folder will succeed, even though the management shell says the folder is not mail-enabled. You should be sure your folders are not in this state before you start making decisions about what to delete based on what Exchange Management Shell says, or else you might delete a directory object for a folder that is actually functioning as a mail-enabled folder.

KB 977921 is no longer available.  The link will display:
KB 977921 No longer Published

Bummer.  But we can use the Way Back When machine to do some time travel.

KB 977921 Available On the Way Back When Machine

The relevant excerpts are:

You use Public Folder Management Console to view the public folders on a Microsoft Exchange Server 2007 server. When you view the public folders, some mail-enabled folders are not listed as mail-enabled folders. Additionally, if you view the properties of these public folders, the Properties dialog box does not have Mail tabs.
If you try to make these public folders mail-enabled, a new directory object is created within the Microsoft Exchange System Objects container. The SMTP address of this new directory object differs from the original one used by that public folder.


This behavior is by design. This issue occurs if the public folder is missing the MAPI ID of 0x671F000B in the PR_PF_PROXY_REQUIRED MAPI property. In earlier versions of Exchange server, this MAPI property was not required in order to check whether a public folder is mail-enabled or not. Additionally, a PR_PF_PROXY_REQUIRED MAPI property was not created. Exchange Server 2007 requires this property to check whether the public folder is mail-enabled or not, even if there is an existing directory object in the Microsoft Exchange System Objects container.



Method 1: Multiple Active Directory Domains

If your environment consists of multiple Active Directory Domains, and there are Exchange servers or there used to be Exchange servers in these different domains, you may have a Microsoft Exchange System Object container in each domain. Each directory object is created in the domain of the Exchange server where it was mail-enabled. For each affected public folder, you have to delete those directory objects that do not reside on the domain where the Exchange 2007 server resides.
After you have deleted the directory objects, you can mail-enable the affected public folder by using the Exchange 2007 Public Folder Management Console. After you mail-enable the public folder, the public folder as well as a new directory object are stamped with the correct MAPI properties.
For more information about how to mail-enable public folders, visit the following TechNet Web site:

How to Mail-Enable Public Folders

Note Before deleting the old directory object, make sure that you save any SMTP addresses that were assigned to the public folder. To view the SMTP addresses, use the Public Folder Management console. For more information about how to do this, visit the following TechNet Web site:

How to View or Configure the Settings of Mail-Enabled Public Folders

If there is lots of folders, this action can be performed by using Exchange Management Shell. For more information about how to use the Exchange Management Shell, visit the following TechNet Web site:

Using the Exchange Management Shell

Back to the top

Method 2: Single Active Directory Domain

When the directory object is in the Microsoft Exchange System Objects container within the same domain as the Exchange 2007 server, you can re-mail-enable the public folder. This creates the appropriate MAPI properties in the public folder. For more information about how to mail-enable public folders, visit the following TechNet Web site:

How to Mail-Enable Public Folders

Note We recommend that you note any special SMTP addresses assigned to the public folder before you re-mail-enable it again. For more information about how to do this, visit the following TechNet Web site:





Source Validation Script called SourceSideValidations.ps1 is available for download and its usage is documented on the Exchange Team Blog.  This script can help verify that Mail Enabled public folders MEPF have the corresponding object in AD.  This is in addition to the permissions validation.

Documented Migration Process

Docs contains the official and supported public folder migration process.  The current and supported approach is the batch migration process.  Please note that the older and now unsupported serial migration process should not be used.

Use batch migration to migrate public folders to Exchange 2013 from previous versions

Migration Process – Notes From the Field

The following Exchange Team blog post written by my colleague Butch Waller who is a senior PFE in the US adds a lot of detail and guidance to the documented process process.

Use batch migration to migrate public folders to Exchange 2013 from previous versions

Use batch migration to migrate legacy public folders to Office 365 and Exchange Online

Legacy Data Loss Issue

Data Loss May Occur During Public Folder Migration to Exchange online

The below is an old issue that dates back to Exchange 2013 CU1 and Exchange 2016 RTM timeframe.

Data loss may occur during public folder migration to Exchange 2013, Exchange 2016, or Exchange Online





Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *