Finding Public Folders

Just as you must configure virtual directories for mailboxes, you must also configure virtual directories for each of the public folder trees that are to be accessible over HTTP through the front-end server.
When you install Exchange, a virtual directory called "public" is created under the default Exchange HTTP virtual server to allow access to the default (MAPI-accessible) public folder tree. When you create other public folder trees (for example, to host applications), you must also create virtual directories in Exchange System Manager to expose these trees over HTTP. Identical virtual directories must exist on each front-end server and on all back-end servers that host the public folder tree.
A request made to a URL in a public folder tree is handled differently when accessing the default (or MAPI-accessible) public folder tree than when accessing general-purpose public folders (also known as application Top-Level Hierarchies [TLH], or non-MAPI TLHs).
In both cases the goal for accessing public folders is twofold:
• For availability If data exists in an Exchange 2000 Server or Exchange Server 2003 public folder somewhere in the Exchange organization and is accessible over HTTP, it is available to the user.
• For consistency As long as the server is available and the user is authenticated, the same public folder server services every request from that user. For authenticated users, ensuring that they go to the same public folder server means that they see the same data every time that they access the public folder trees through the front-end server (including status of read and unread messages, which is stored on individual servers and is not replicated between public folder servers). The fact that users always reach the same back-end server is also important for server-based applications that maintain session state, such as some built with Active Server Pages (ASP).
Public Folder Referrals
In Exchange, you can configure public folder replication on a per-folder basis. The actual public folder tree hierarchy is available on all Exchange public folder servers in the organization, but the contents of each folder may not be. This information is not stored in Active Directory but is maintained as a property on each folder in the public folder store. Therefore, special handling is required when the back-end server selected by the front-end server does not contain the contents of the folder requested by the client.
The following figure illustrates how public folder referrals travel through a front-end server.

1. An HTTP client authenticates against the front-end server and requests /public/PublicFolder2.
2. The front-end server authenticates the user against Active Directory and requests the location of the user's default public folder store.
3. Active Directory indicates to the front-end server that the user's default public folder store is on Server1.
4. The front-end server sends the client request to Server1.
5. Server1 tells the front-end server that it does not have the contents of /public/PublicFolder2, but Server2 and Server3 do.
6. The front-end server performs a hashing algorithm against the list of servers with the content (in this case, Server2 and Server3). The results of the hash in this case turn out to be Server2, so the front-end server forwards the request to Server2.
Note:
A hashing algorithm applies a given number (in this case, the user's security token) and uses it to generate a position in a list so that the distribution of all possible inputs is even over the list.
7. Server2 returns the contents of /public/PublicFolder2 to the front-end server, which then sends the contents to the HTTP client.