This week, we were on a service call to support an Outlook client connectivity issue with Exchange Server 2007. The error message was basically telling us that this Earlier Outlook client cannot connect to Exchange 2007 Server.
Search queries offered the following:
- Earlier Outlook clients cant connect to Exchange 2007 Server
- When you use Outlook with an Exchange 2007 mailbox, you cannot connect to Exchange 2007, and you receive an error message
The second linked KB article above offered these potential causes:
- You do not have an existing public folder tree.
- MAPI is disabled for your mailbox.
- Cached Exchange Mode is required for your mailbox.
- RPC/HTTP mode is disabled for your mailbox.
- Your version of Outlook is specifically blocked by Exchange 2007.
Our issue appeared behind door number ONE. Exchange could not properly enumerate the Public Folder Tree because elements and attributes were missing in Active Directory Services Integration. This missing data caused Exchange 2007 to return errors relating to the (1.) Public Folder Database AND (2.) Public Folder Tree as we worked through Troubleshooting the issue.
At first, because the PublicFolderDatabase.edb “was indeed present” in the following path:
E:\Program Files\Microsoft\Exchange Server\Mailbox\Second Storage Group
we thought we’d access the Properties and review the state and settings of the database, confirm it was properly mounted, etc…. When we attempted to access the properties, we received the first error intimating that the PublicFolderDatabase.edb was corrupted (an error which was itself “in error” as later, when we were able to re-mount it, the PublicFolderDatabase.edb performed as healthy).
Exchange Public Folder Error 1
-------------------------------------------------------- Microsoft Exchange Warning -------------------------------------------------------- The following warning(s) were reported while loading topology information: get-PublicFolderDatabase Completed Warning: Object YOUR-SERVER\Second Storage Group\Public Folder Database has been corrupted and it is in an inconsistent state. The following validation errors have occurred: Warning: PublicFolderHierarchy is mandatory. Warning: PublicFolderHierarchy is mandatory. -------------------------------------------------------- OK --------------------------------------------------------
Since we knew this particular client did not actually use Public Folders in any capacity, we elected to DELETE the Public Folder Database (since there was no data in it) and re-create it.
NOT SO FAST EXCHANGE SERVER SAID ! After making the attempt to delete the PublicFolderDatabase.edb, we got a second error stating that a critical property ‘PublicFolderHierarchy’ is missing in the PublicFolderDatabase. This error essentially would not allow us to delete.
Exchange Public Folder Error 2
-------------------------------------------------------- Microsoft Exchange Error -------------------------------------------------------- The public folder database 'Public Folder Database' cannot be deleted. Public Folder Database Failed Error: The critical property 'PublicFolderHierarchy' is missing in the PublicFolderDatabase object 'YOUR-SERVER\Second Storage Group\Public Folder Database'. -------------------------------------------------------- OK --------------------------------------------------------
In the end, after a lot of Question and Answer…. what turned out to be true for this client was a historical event: “a migration from Exchange Server 2003 to Exchange Server 2007″ that had gone a little wrong. Since the client did not use Public Folders, they had elected not to Migrate them, thinking it was not necessary since they were not actually used.
What resulted from this, and the attempted later clean up effort using ADSI Edit, were missing elements and attributes in Active Directory Services Integration.
This post on Social.Microsoft.com enabled us to provide a solution. The solution (as quoted from SONNY1 at Social.Microsoft) follows:
Restoring Public Folder Hierarchies to Exchange Administrative Group using ADSI Edit
Open adsiedit.msc.
Select Configuration-Configuration-Services-Microsoft Exchange-Orgname-Administrative Groups-Exchange Administrative Group.
Now we were missing the ‘Folder Hierarchies’ folder – how I still am unsure of. All we had to do was recreate it as follows:
Create the “Folder Hierarchies” under the Exchange Administrative Group
- Right click on Exchange Administrative Group
- Select New Object
- Select msExchPublicFolderTreeContainer for the class and click Next
- Enter the following for the value: Folder Hierarchies, click Next
- Click Finish
Create Public Folder Tree Object
- Right click CN=Folder Hierarchies -> New Object
- Selected msExchPFTree for the class
- For the value we entered, “Public Folders” and clicked next
- Clicked on the “More Attributes” button, selected msExchPFTreeType and set the value to 1. Note: This is very important that this value is set to a value of 1 as this tells Exchange that this is a MAPI Tree
- Click Ok and then finish
Populate msExchOwningPFTreeBL attribute object of the PF Stores in the organization
(Since this attribute is not directly editable, you have to follow the below steps to do this for each PF store)
- Get properties of the newly created “Public Folders” Tree object in ADSIEdit.
- Copy the distinguishedname value to the clipboard and then click cancel.
- Navigate to the Storage group that contains the Public Folder Store for this server and get properties of the server.
- Locate the msExchOwningPFTree attribute and paste in the value that was copied to the clipboard in step 2. Click OK.
- Restart the Information Store Service
- Now try to mount the PF store and see if we can access it fine now.
As soon as the Information Store starts, remount the PublicFolderDatabase.EDB using the Exchange Management Console.
WIGITAL would like to thank Sonny1 for the valuable insights.
Sonny1′s original reply is posted at – - Public Folder database wont mount on a CCR cluster
Thank You
Hope this helps you as well.