Microsoft Exchange offers more than a place to get your mail. Exchange's public folders are a vehicle that lets users in an Exchange organization share information. You can use public folders for electronic bulletin boards, discussion forums, reference materials, newsgroup messages, and other applications. Unlike mailboxes, which only a mailbox owner can open, everyone in an Exchange organization can access a public folder. In this article, I'll explain how the email client interacts with public folders and how the mail administrator can configure public folder options within the organization for optimal performance.
Public Folder Components
A public folder has two parts: the container (or hierarchy) and its contents. Public folder contents can consist of messages (with optional attachments), postings, or electronic forms. You create folders in a hierarchical format on the client; you can't create public folders on the server. The hierarchy is usually in the left pane of the client's window, and the contents are in the right pane.
From the Exchange client, the user can view the folder hierarchy under the All Public Folders object. When a client creates a public folder, the Message Transfer Agent (MTA) on the Public Information Store replicates the hierarchy throughout the organization to all servers that have a Public Information Store and configured connectors. This action ensures that all clients within the organization can see the newly created folder. Public folder replication occurs every 60 seconds and usually doesn't negatively affect bandwidth because the amount of replicated data is rather small. Exchange replicates the public folder hierarchy automatically; the administrator doesn't have to manage it.
Exchange handles public folder contents differently than it handles the hierarchy. By default, if a public folder has contents, only clients in the public folder's site can view the contents. The mail administrator can let all clients in remote sites have access to contents either by replicating public folder contents on other servers or by setting up public folder site affinity.
Public Folder Replication
Replication of public folder contents is the process of copying the contents from one public folder to other public folders on other servers. Folder replication is messaging based; that is, the MTA transfers the public folder hierarchy and contents, within a site or to other sites. If you are replicating contents outside your site, you must configure connectors. You must configure both a messaging connector, which the MTA uses, and a directory replication connector, which you need because public folders are directory objects. (For more information about connectors, see Mark Ott, "Intrasite and Intersite Directory Replication," May 1998.)
You can configure replication at the server as either a pull operation or a push operation, depending on which server initiates replication. A server that wants the content from another server replicated to its Public Information Store initiates a pull. A server that has contents and wants to copy them to a server that has no public folder contents configures a push. Pulling is more convenient, because you can pull several public folders at once; you can push only one folder at a time.
If you want to pull the public folder contents from another server to your server, open the Public Information Store Properties sheet on your server. On the Instances tab, shown in Screen 1, choose the site where the public folders reside, select the public folder (or folders) whose contents you want, and click Add. Screen 1 shows that you can pull the contents of six public folders from the DAYTONOH site.
To push a folder's contents to another server, from Exchange Administrator, go to Folders, Public Folders, and select the property sheet of the public folder you want to replicate to a remote server. On the Replicas tab, select the server you want to populate with contents from that public folder and click Add.
Public Folder Site Affinity
Public folder affinity lets users in one Exchange site view the contents of public folders on Exchange servers in other sites. Affinity is a pointer to where the information resides. You can use affinity only between sites, not servers.
For example, suppose you create a public folder hierarchy called Cars in Site X and populate it with several postings. Clients throughout the organization can view the Cars folder within about a minute, but clients in remote sites can't view the contents until you set up affinity. After you have configured site affinity, a client in Site A can double-click on the folder and establish a network connection to Site X. If Windows NT validates the client, Exchange passes the contents over the network and displays the contents at the client desktop. If the client decides to open a 2MB attachment in one of the postings, that traffic, too, will pass over the network link.
To configure site affinity, from Exchange Administrator, go to the Information Store Site Configuration object from the site that contains the folder's contents, as Screen 2 shows. In Screen 2, the Set Value option lets you assign an affinity value of 1 to the DOMAIN1 site. Exchange uses this value (i.e., the site cost) to decide which of several public folder instances (if they exist) to choose. ("Intrasite and Intersite Directory Replication" describes assigning cost values in Exchange.) After you establish affinity, a client in the DOMAIN1 site can view contents from the remote site.
Public Folder Planning and Strategies
Public folder content replication and site affinity are optional; you must decide when and how to replicate public folders. If you want to maintain only one instance of public folder contents, you can configure public folder site affinity so all the other sites in the organization can view the postings in the public folder. Other times, you might prefer to replicate the contents to other servers so each site has an instance (or multiple instances) of contents. Or you can use a hybrid method: Create instances in busy public folder sites, and configure site affinity to let users remotely access the contents from low-volume public folder sites.
Replicating contents has advantages and disadvantages. When you replicate content, you no longer have one point of failure. Fault tolerance is built in because you still have a replica if you lose the original (e.g., because of hardware failure). Also, by having multiple copies of a folder throughout the organization, you can balance the workload and minimize WAN bandwidth because users can access a local replica instead of a remote replica. However, you might prefer to have only one instance of contents when you don't want the overhead associated with content replication or if users simultaneously update content on two instances of a posting and cause conflicts.
Some administrators base their decision about public folder replication on the amount of network traffic generated by public folder replication compared with public folder site affinity. Other criteria to consider are the size of the folder's contents, frequency of client access, frequency of content updates, link bandwidth and integrity, and replication schedule. A crucial aspect of replication is deciding how many replicas to have and where to put them. Bandwidth is a constant concern, so make sure you have good links that can handle the load before you arbitrarily set up multiple instances throughout your organization.
Public folders that have many postings that don't change often might be candidates for replication if clients access the folders often. You probably will choose public folder affinity for public folders that contain only a limited number of small messages, are updated frequently, and have light traffic. Site affinity is a good choice in the latter situation, because a client accessing one instance generates less network traffic than replicating folders every 15 minutes (the default replication interval) generates.
Monitoring Public Folder Contents
If you have configured multiple instances of public folders, you need to keep the contents of these replicas current across all servers. The Public Folder Replication Agent in the Information Store is responsible for synchronizing folders. As soon as multiple replicas exist, the Public Folder Replication Agent begins monitoring the replicas, and when a user modifies a folder (e.g., makes a new posting or edits or deletes a posting), the Public Folder Replication Agent notifies the other public folder replicas. By default, every 15 minutes the Public Folder Replication Agent bundles all the public folder's modifications, up to the maximum replication size limit (which you set under the Advanced tab of the Public Information Store), and sends them to the MTA for delivery to all other replicas. You can make replication global for all public folders or configure replication folder by folder.
When users add, modify, or delete messages in public folder contents, the Public Folder Replication Agent marks the changed message to synchronize it properly across all replicas. The Public Folder Replication Agent assigns three attributes to the modified contents: a change number (an identification number based on the message's Information Store and server), a time/date stamp, and a predecessor change list (a list of change numbers of edited messages from all information stores' instances). During replication, the Public Folder Replication Agent compares these attributes to ensure that all replicas are mirror images of one another.
When a new message arrives at the remote folder, the Public Folder Replication Agent records the change number from the originating message on all the replicas. The agent sends deleted message notifications to all replicas and purges that message on all the replicas.
Expired postings are folder contents configured to age out after a specific amount of time. You can set the interval for each Information Store, for all replicas, or for each folder. Expired messages are not MTA-enabled; that is, they won't be replicated to other public folder instances, as new or deleted postings are.
Public Folder Replication Tips
You must guard against several potential problems in replication. These problems include backfill, age limits, and conflicting messages.
Backfill. After the Public Information Store sends a replication message, its job is complete. Exchange makes no provisions for the receiving store to send back an acknowledgment. Therefore, public folders might not be mirror images of one another if, for example, servers temporarily lose connectivity or if you use a backup tape to restore a post office. Exchange counters this possibility with a mechanism called backfill.
Backfill is a method of restoring out-of-sync public folder contents. Each Information Store periodically sends out a change message that compares change numbers between stores. If the change numbers match, everything is OK. If the numbers don't match, the Information Store with the lower number sends a backfill request to two other servers. The request pinpoints the missing messages, and the servers send back those messages. Fortunately, this process is automatic; the administrator doesn't have to manage it.
Age limits. You can manage folder contents by having postings expire after a certain interval. This function is important because Exchange has no provisions for automatically preventing a public folder from exceeding a predefined size limit. You can only issue warnings to the public folder contact (usually the folder's creator), but such warnings don't guarantee that the contact will delete postings from a public folder.
Because you can set different age limits for each Information Store, an expired message in a store that has a 1-month age limit can magically reappear if someone edits it in another replica that has a 2-month age limit. For ease of administration, set the same age limits across all replicas in the organization.
Conflicting messages. Conflicting messages occur when users edit the same message on two instances before the message can replicate. In this case, when replication occurs, the change number of the message that was edited first is not present in the predecessor change list of the new posting. This omission triggers a conflict warning, as Screen 3 shows, which is sent to the public folder contact and the users whose edits created the conflict. The contact can choose one posting over the other or let both messages be posted to the folder. However, the contact can't merge changes between the postings.
Tuning and Troubleshooting
By default, any user can create public folders. However, if you don't want your hierarchy growing out of control, you can limit permission to create public folders. Go to the Information Store Site Configuration container property sheet to configure the Top Level Folder Creation tab. From here, you can determine who has permission to create public folders on the client.
A common error message, shown in Screen 4, states that the contents of a public folder aren't available. This message usually means that either the administrator hasn't replicated the contents to the client's site (i.e., the client can see the public folder hierarchy but doesn't have access to the contents) or the administrator hasn't enabled site affinity.
NT must validate a user who is using site affinity to connect to a remote server. If users attempt to connect to a public folder server not within their domain, the connection attempt fails. To fix this problem, the public folder server must trust the domain where the user's account exists. An easy way to solve this problem is to use a Web-based email client, because NT will use the Internet guest account to validate the user.
From the server end, you can get a snapshot of the current status of public folders from the Public Information Store Properties sheet. As you can see in Screen 5, this sheet shows you what is happening in each folder. The Replication Status column can help you determine whether the replicas are synchronized. When troubleshooting public folders, don't forget to turn on Diagnostics Logging on the Public Information Store Properties sheet and view the log in the application log in Event Viewer.
If you have set up multiple instances of contents, the best way to manage bandwidth is to configure the scheduled replication interval. You can set the interval globally for all public folder contents (under the Advanced tab of the Public Information Store) or for each folder (under the Replication schedule tab of that public folder). I strongly suggest that you increase the replication interval from the 15-minute default if the postings don't contain mission-critical data or aren't time sensitive. Throttling back this time interval conserves bandwidth.
If server performance deteriorates to an unacceptable level, you can configure a dedicated public folder server. A dedicated public folder server has a Public Information Store but no Private Information Store. If your organization uses mailboxes and public folders heavily, the volume of traffic generated may dictate splitting the two information stores (private and public) for load balancing. If you create dedicated private and public servers, all clients must obtain the hierarchy and contents exclusively from the dedicated public folder server. This requirement inherently creates more network traffic because a client potentially must connect to two servers to get both mail and public folders. In these cases, make sure you have large network pipes to handle both mail and public folders. A hybrid solution is to maintain private and public information stores on each server so clients can retrieve the public folder hierarchy from their home server and connect to the dedicated public server only when they request contents.
Microsoft has written two utilities that focus exclusively on public folder problems (you can find these utilities in the Microsoft BackOffice Resource Kit, Part 2). The Replication Verification Tool (Replver.exe) is a Windows utility that compares public folder hierarchy and contents across replicas and reports any discrepancies. You define a master server, and Replver.exe compares the public folder instances on that server to the other instances defined on the target servers.
The PFTreeInfo tool is another Windows utility that counts messages in a target folder and all its subfolders. You can use the program to verify that folder replication is complete across all replicas; the utility is particularly useful for checking on the largest folder contents (such as the Internet News Service folder).
Important Choices
Administrators have crucial choices to make when deciding how (or even whether) to implement public folders. This article points out a few decisions you need to make. When you use public folders, your administrative duties of managing multiple replicas will increase. Cost-benefit analysis is the only way to ensure that you're using your resources wisely.
