Error accessing Public Folders Hierarchy in coexistence environment 2007-2013

This is a specific issue we have encountered in several deployments, for customers migrating from Exchange 2007 to Exchange 2013, or simply by having the two versions coexisting in their environments due to specific requirements.

When you attempt to manage your legacy Public Folders from the Public Folder Management console in this scenario, you can connect to the PF server, but the PF hierarchy might not be visible under Default Public Folders node.  If you use Exchange Management Shell instead, Get-Publicfolder or Get-Publicfolder \ -Recurse  would return the following error:

 Get-PublicFolder : There is no existing PublicFolder that matches the
 following Identity: '\'. Please make sure that you specified the correct
 PublicFolder Identity and that you have the necessary permissions to view
 PublicFolder.
 At line:1 char:1
 + Get-PublicFolder
 + ~~~~~~~~~~~~~~~~
 + CategoryInfo          : NotSpecified: (0:Int32) [Get-PublicFolder], Mapi
 OperationException
 + FullyQualifiedErrorId : C00ECE14,Microsoft.Exchange.Management.MapiTasks
 .GetPublicFolder

This issue does not prevent Outlook clients to access public folders.

When Exchange 2007 sets up the mapi session to access the public folder database and read the PF hierarchy, it builds the system attendant mailbox DN based on the server's DN that hosts the oldest (first created) private MDB object. Assuming that the oldest database in the organization was created in Exchange 2007, everything should work fine. However if Exchange 2013 joins to the organization and,  later, the Exchange 2007 databases are recreated, it is possible that an Exchange 2013 private MDB becomes the oldest database in the environment, causing the issue described above.

The problem is that due to architectural changes in Exchange 2013, the server's system attendant object is no longer populated with the homeMDB attribute used by Exchange 2007 to create the mapi session (remember Databases no longer belong to servers after Exchange 2010, but to Administrative Groups).

A quick workaround to this issue, is to set the homeMDB attribute of the Microsoft System Attendant object under the Exchange 2013 server hosting the oldest database in the environment. If this database is part of a DAG with copies in multiple servers, each system attendant object under each server should be modified. You will need to perform this change using a low level directory service tools like ADSIEdit, and as such, this change is unsupported in nature, please proceed at your own risk.

How do we know how old is a database object? just by inspecting its whenCreated attribute in AD. Get-MailboxServer | Get-MailboxDatabase | Sort-Object whencreated| fl name , server, whencreated, will give you a list of mailbox database objects in your environment ordered by creation date.

Which homeMDB name should we use for the property value? You can select the DN of one of the databases hosted on the server being modified. In the example below, assuming the oldest database is active on server EXHR-2006, you will be populating the homeMDB attribute of the "Microsoft System Attendant" object with its value equals to the distinguishedName property of the "Mailbox Database 1450518890".

 

Another, more difficult workaround, would be to re-create the conflicting Exchange 2013 databases so that their whenCreated attribute is greater than the whenCreated attribute of the oldest Exchange 2007 private database. Depending on the number of Exchange 2013 databases and how recent is your oldest 2007 database,  this workaround could be unfeasible.