Posted by Frederiek Goemaere on 11/01/2012.

Both during the TEC panel discussion and the Pro-Exchange “Meet the product team” event some questions were asked about Public Folder HA. (Hi “Dave”!). A nice occasion to combine some of the screenshots we had lying around in a blog post. 

If your company has an Exchange 2010 environment and it has to be highly available, you will most probably implement a DAG (Database Availability Group) and CAS Array (Client Access Array).

A DAG provides you with redundancy for mailbox databases. While Public Folders could rely on CCR clustering in Exchange 2007; they cannot make use of Exchange 2010 availability groups. Instead, you have to fall back to Public Folder replication to maintain multiple copies of your data.

Additionally, public folder connectivity also does not respect the “MAPI on the Middle Tier” (MOMT) principle. When your Outlook client connects to the Exchange environment, it will make a connection with the CAS Array as you can see below. For the connection to the Public Folder database, it will make a direct connection to the server that hosts the Public Folder database. That means that Outlook bypasses the CAS Array for Public Folders and connects to one of the mailbox servers in a direct way.

If that mailbox server becomes unavailable, you will still have access to your mailbox because you will be redirected by the CAS array to another mailbox server hosting an available copy of your mailbox. If you want to access a Public Folder, you will have a problem. The connection will fail because of the direct connection.

Microsoft has included a fix into Update Rollup 2 for Exchange 2010 SP1. However, installing this update alone will not fix the problem. We also need to enable “Public Folder Referrals” as they are disabled by default. (PF referrals allow you define exceptions on the normal routing cost calculations, specifically for Public Folders).

You can enable Public Folder referrals with the following command:

"get-publicfolderdatabase | set-publicfolderdatabase -UseCustomReferralServerList:$True"

Can you spot the difference when running the command above again?

As you can see, Public Folder Referrals are now enabled but still empty. We will use server 3 as first referral because it is a sort of hot standby in our demo environment. As second referral we will use server 2. You will have to do this for every Public Folder database.

If you analyze the setup closely you can see we used some sort of cyclic permutation in the configuration above.
Now let’s take a look on how our client will use these referrals. If you start your Outlook client, it will try to connect to the default Public Folder database (notice the status which says “connecting”):

Exchange will return the referrals and your Outlook client will try to connect to the referrals (notice they have both an “established” status):

Note that in the background, Outlook will still try to connect to the default Public Folder database.

It may be possible that if you want to access some folder, Outlook will use the default Public Folder database and you will get an error.

After you restart your Outlook client, he will correctly connect to another Public Folder database.

Conclusion: Availability for Public Folders has been improved, however it’s not as transparent and granular as one might expect. There’s only a failover when there’s no connection to the server possible (mapi_e_network_error), not when just the PF DB is dismounted. There is a certain degree of user impact (popup error messages and time outs). In other words you will need to properly inform your users or customers and “manage their expectations”.

Alternatively, or in parallel, an administrator can change the Default Public Folder database configured for a mailbox database to ensure users a directed to a fully functional PF DB.

Note : post co-authored by Frederiek Goemaere, Michael Van Horenbeeck and Koen Vermoesen.