In the previous blog entry, I explained how to safely recover accidentally deleted public folders from backup. I briefly mentioned some important public folder concepts in that article, and in this, the second part, I’m going to describe some of the inner workings of public folders themselves. Each organization maintains a list of all public folders in the environment, as well as the locations of all replicas. This list is called the hierarchy, and it’s common to all public folder stores in the environment. The hierarchy lists all public folders in the environment as well as which servers host replicas of each folder. Each public folder store has a copy of the hierarchy, and uses it to provide referrals to end users for public folder replicas on other servers (among other things). Each public folder store also maintains a table, called the replication state table, which keeps track of the status of each folder. This table is a critical yet little understood feature of public folders, and it has a huge impact on recovery.
As I said above, each public folder store maintains a replication state table, but unlike the hierarchy, it’s unique to each store. A public folder store maintains information about the public folders for which it has a replica, not just for itself but for all servers with that replica. It does this so that it knows which other stores have more up-to-date public folder content, or which ones might have items required for backfill replication (catching up on old or missing items).
Imagine the following scenario: we have three servers, each hosting a public folder database – PFS1, PFS2, and PFS3. We have a folder – Folder1 – which is replicated to each database. If I could peer into the replication state table for PFDB1, I would see an entry for Folder1, and that entry would contain information about Folder1’s status not on for PFS1, but also for PFS2 and PFS3. What kind of information does this table actually contain? To answer that, we need to dig yet further into public folder structure, and talk about CNs.
Read my favorites blogs: