I’ll be writing these Break/Fix features to give an idea of some problems I’ve faced that I think are worth sharing.
I had a another resource call for help on a Public Folder issue. The client (thus referred to as client X) had an issue with their Exchange CCR setup. They had lost a node, and unfortunately on that node lived their public folders. The nodes’ failure was so severe, it was removed from the cluster. Before I go any further, let me give me give a sense on the Exchange setup. Their environment had been migrated from an Exchange 2003 environment, yet no decommission process had taken place. Foreshadowing! This will be important later.
First, the resource restored the public folders from the backup, and restored it to the working node. After being online with Microsoft Support, some minor changes to the metadata were needed to re-mount the Public Folders. Bada-bing, everything mounted and the users could access the public folders.
Here’s where I come in. I received a called that the mail-enabled public folders are not working. Mail is getting “stuck” in the queue and cannot internally route mail to the public folders. When I launch Queue Viewer, here’s what I see:
I noted is that it’s pulling a distinguishedName that doesn’t match the Exchange 2007 version, nor the Public Folder context. As many know “First Administrative Group” is not a term that is found in Exchange 2007 at all, so I knew that there must best either some potential cleanup during the decommission process that did not take place or there is an active Exchange 2003 environment. Time for research!
Public Folders work very differently from E3 to E7. The use of “Folder Hierarchies” are used in order for replicas to exist across different nodes, and multiple Public Folder databases. The Folder Hierarchies live within the metadata, and without certain properties point to certain Public Folder databases, it won’t see the specific database.
Two sources lead me in the correct direction, and are worth being in this post:
- Troubleshooting Mail Flow from Exchange 2007 to Exchange 2003 When E-Mail Messages are Stuck in the Queue
- Fixing Public Folder Directory Objects That Aren’t Linked To The Hierarchy
Let’s talk about number one first. Go back to the issue, it seems that when the Public Folder database went down on the Exchange 2007 node, it tried to revert back to its old replica partner, the Exchange 2003 version. That’s where the metadata went crazy. Not only did it change the properties of the restore Public folder database, but it also change each publicFolder object within Microsoft Exchange System Object (MESO) (Another reason why to always follow through with a project and remove your old systems). So here’s the order on the process:
- Look for the “Folder Hierarchies”. It should be in the Exchange Administrative Group (XXXXXXXXX). If not, you’ll need to recreate it, see Link #1 for the setup process.
- Find property object MSExchOwningPFTree on each public folder store and see if the attribute is point to the Folder Hierarchy.
- If not, copy the distinguishedName from the cn=Public Folders object within “Folder Hierarchies” and paste it into the public folder store property MSExchOwningPFTree.
- Once the public folder store is linked with the “Folder Hierarchies”, you will need to check each MESO (one per public folder) in the cn=Domain metadata.
- Bill Long (see Link #2) wrote an awesome PowerShell script that is copied below which will set the HomeMDB property for each MESO.
- After completing all steps, restart the Information Store and Transport services.
Here’s a copy of that PowerShell script:
# Change these two values to match your environment.
# $container should point to the MESO container you want to run against.
# $pfTreeDN should contain the distinguishedName of the public folder hierarchy object.
$container = [ADSI](“LDAP://CN=Microsoft Exchange System Objects,DC=contoso,DC=com”)
$pfTreeDN = “CN=Public Folders,CN=Folder Hierarchies,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com”
$filter = “(!(homemdB=*))”
$propertyList = @(“distinguishedName”)
$scope = [System.DirectoryServices.SearchScope]::OneLevel
$finder = new-object System.DirectoryServices.DirectorySearcher($container, $filter, $propertyList, $scope)
$finder.PageSize = 100
$results = $finder.FindAll()
(“Found ” + $results.Count + ” folder proxies with no homeMDB…”)
foreach ($result in $results)
(“Fixing object: ” + $result.Path)
$entry = $result.GetDirectoryEntry()
After restarting the services, the queued mail will start flowing into the mail enabled public folders.