A Fistful of Exchange 2010 Errors and How to Fix Them

Warning: Please be extremely careful deleting keys from ADSI Edit – if it goes badly wrong, you’re looking at an Active Directory restore!

Scenario

An Exchange 2003 to Exchange 2010 upgrade. Alas, the Microsoft Exchange 2003 Best Practice Analyzer Permission Check has not been run in which case a critical issue regards ‘Permissions inheritance block on Administrative Group object’ would have been noticed.

Image: Permissions inheritance block on Administrative object

Exchange 2010 is installed for coexistence with Exchange 2003 using the tried and tested script:

setup.com /mode:Install /roles:CA,HT,MB /EnableLegacyOutlook /LegacyRoutingServer:exch03.ad.priv /ExternalCASServerDomain:mail.ad.com

The install completes all okay and the server is rebooted.

First Error

The Public Folder Database created by the Exchange 2010 coexistence install is dismounted, trying to mount the Public Folder Database results in the error:

The database action failed. Operation failed with message: MapiExceptionNotFound: Unable to mount database

Second Error

Never mind, there’s nothing on the database, so we try to delete it from the Exchange Management Console (EMC), and this results in the error:

Unexpected error … while executing command ‘remove-PublicFolderDatabase’. Additional information: at Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult) …

Still never mind – using ADSI Edit connected to the Configuration Naming Context we delete the key:

CN=Public Folder Database XXXXXXXXXX

From:

CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative Group (XXXXXXXXXXXXXXX)

Image: Deleting CN=Public Folder Database XXXXXXXXXX

Then we create a New Public Folder Database using the EMC (leave unchecked the ‘Mount this Database’) which completes all okay. And mount it manually without any error.

Third Error

Assuming the public folders are now okay, we start testing the email delivery from Exchange 2003 to Exchange 2010 and vice versa. Email delivery to Exchange 2010 is fine from Exchange 2003, but we cannot send from Exchange 2010 to Exchange 2003. So we check the queue viewer and discover the error:

Last Error: There is currently no route to the mailbox database

Very odd because the install had correctly created both connectors (from Exchange 2003 to 2010 and 2010 to 2003) as seen in Exchange Server Manager (can also use Get-RoutingGroupConnector from the EMS).

Image: Connectors from Exchange 2003 to 2010 and vice versa

Fourth Error

Never mind, we’ll just delete the connectors and then recreate them using the command (for a bidirectional connector):

New-RoutingGroupConnector -Name "Interop RGC" -SourceTransportServers "exch10.ad.priv" –TargetTransportServers "exch03.ad.priv" -Cost 1 -Bidirectional $true -PublicFolderReferralsEnabled $true

And this result in the error:

Active Directory operation failed on ... This error is not retriable. Additional information: Directory object not found.

Active directory response: … problem 2001 (NO_OBJECT), data 0, best match of: …

When we check in Exchange System Manager, the ‘Interop RGC’ connector has been created in the Exchange 2010 administrative group, but delivery still does not work from Exchange 2010 to 2003.

Image: Interop RGC in Exchange 2010 Administrative Group

Fifth Error

We delete the Interop RGC connector and run the commands below without the Bidirectional parameter:

New-RoutingGroupConnector -Name "Exch 2010 to 2003" -SourceTransportServers "exch10.ad.priv" -TargetTransportServers "exch03.ad.priv" -Cost 1 -PublicFolderReferralsEnabled $true

New-RoutingGroupConnector -Name "Exch 2003 to 2010" -SourceTransportServers "exch03.ad.priv" -TargetTransportServers "exch10.ad.priv" -Cost 1 -PublicFolderReferralsEnabled $true

The first commend completes without any error, but the second fails with:

Setup couldn't read the legacy administrative group 'First Administrative Group' from Active Directory, and now Setup can't continue. Check Active Directory to verify that the administrative group exists and that the user account that is running has permissions to access this administrative group.

This hints at what will be the solution!

Sixth Error

In the Exchange 2010 Public Folder Management Console we are getting the following error when we try to open up the Default Public Folders and a similar one for ‘\NON_IPM_SUBTREE’ when we click on System Public Folders.

No existing ‘PublicFolder’ matches the following Identity: ‘\’. Make sure that you specified the correct ‘PublicFolder’ Identity and that you have the necessary permissions to view ‘PublicFolder’. It was running the command ‘get-publicfolder –getchildren –identity ‘\’ –server ‘EXCH10.ad.priv’’.

Image: System Public Folders error – No existing ‘PublicFolder’

Seventh Error

In Exchange System Manager, if we try to add a replica to a public folder, we get:

There are no Public Stores which do not have a replica of this folder.

The Solution Part One

In Exchange System Manager, right-click the ‘First Administrative Group’, select properties, select the Security tab, click on Advanced and check the box to ‘Allow inheritable permissions for the parent to propagate…’, click OK to the ‘The inherited items will not show up until you close and re-open the property sheet’, and click OK again.

Image: Ticking the ‘Allow inheritable permissions’ checkbox (Exchange 2003 default setting!)

Note: The Security tab only appears after the REG_DWORD with a value of 1 is added to the HKCU\Software\Microsoft\Exchange\EXAdmin key in the registry on the computer running Exchange System Manager.

After making this change, the connectors will now create without error and mail flow from Exchange 2010 to Exchange 2003 will work!

Eighth Error

After applying the solution above, public folders will still not work. In Public Folder Management Console, if we try opening the Default Public Folders, we get a different error:

Multiple MAPI public folder trees were found. It was running the command ‘get-publicfolder –getchildren –identity ‘\’ –server ‘exch10.ad.priv’

And there is a similar error for \NON_IPM_SUBREE when clicking on System Public Folders.

The Solution Part Two

1) Dismount what was the newly created public folder in Exchange 2010.

2) Use ADSI Edit connected to the Configuration Naming Context to delete the public folder:

CN=Public Folder Database

From:

CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative Group (XXXXXXXXXXXXXXX)

Note: You would not be able to delete the Public Folder via the EMC – it would error (Ninth Error!) with “Exchange can’t remove the public folder database … because it is the last public folder database in an organization that has pre-Exchange 2007 servers…”

3) Use ADSI Edit to delete the second CN=Folder Hierarchies key which is found in the new Exchange 2010 Administrative Group.

Image: Exchange 2010 and Exchange 2003 Administrative Groups in ADSI Edit, with two CN=Folder Hierarchies

4) Now simply recreate the Exchange 2010 Public Folder.

Problems solved!

The Theory

The theory behind what happened with the Public Folders, is that – due to the permissions issue – when the Exchange 2010 install failed to properly create a public folder, by re-creating the public folder (from ‘Third Error’ above) this caused a second CN=Folder Hierarchies key to be created. To solve all the problems, the permissions had to be fixed, and the erroneous second CN=Folder Hierarchies key had to be deleted from the new Exchange 2010 Administrative Group.

More specifically, regards the ‘Multiple MAPI public folder trees’ error; this is caused by the presence of two keys with the msExchPFTreeType value of 1.

The following extract (courtesy of Bryon) shows fixing this in another way:

1. In ADSIEDIT, right-click on the CN=Configuration,DC=,DC=com container, choose Properties.

2. Copy the value of DistinguishedName

3. Drop to DOS and run: LDIFDE -f c:\Config.txt -d "distinguishedName of CN=Configuration,DC=domain,DC=com"

4. Search c:\config.txt for all instances of "msExchPFTreeType"  with a value of "1"

5. In ADSIEDIT delete the one that doesn't belong (or set it to zero if you're scared)

In this scenario, the msExchPFTreeType existed within the second erroneously created CN=Folder Hierarchies.

The Motto of the Story

And all because an Exchange 2003 BPA Permissions check was not run before installing Exchange 2010!