Replicating a Public Folder

The contents of public folders are not replicated to other public folder stores in your organization automatically. If you want replication to occur, you must set it up manually, on a per-folder basis. You can configure each public folder individually to have replicas on multiple public folder stores. When you set up replication for a parent folder, its child folders are also replicated by default, although you can change this for individual child folders.

Public folder replication follows the multimaster replication model, in which every replica of a public folder is considered a master copy. In fact, there is no easy way to distinguish a replica from the original after replication occurs.

Creating a Replica

After you’ve decided which folders you want to replicate, you manually create and configure the replicas. The method for doing this involves pushing replicas from one public folder store to other public folder stores, using the property sheet of the public folder that you want to replicate. To set up replication for a public folder, open its property sheet in Exchange System and then switch to the Replication tab (Figure 10-16).

Figure 10-16: Configuring replication for an individual public folder.

This tab lists any public stores that already contain a replica of the public folder. Click the Add button to open a dialog box that lists the available public stores in your organization that do not have replicas of the folder. Select the store to which you want to replicate the folder and click OK. The public store is added to the list of stores that contain replicas.

Below the list of public folder stores, you’ll find a drop-down menu named Public Folder Replication Interval. Use this menu to schedule the replication of the public folder to the other public folder stores. You have several options here:

• Never Run Essentially turns off replication of the public folder, which is handy if you want to stop the replication temporarily to do something like troubleshoot a bad connector.

• Always Run Essentially keeps replication going all the time. Because this option would cause excessive traffic, it is generally a poor choice. However, it can be useful when you first configure a new replica and you want it to be created as soon as possible. In this situation, turning on the Always Run option ensures that the content will be replicated quickly. Be sure to set the schedule to something more reasonable afterward, however.

• Run Every 1, 2, or 4 Hours Causes replication to occur at the defined interval.

• Use Custom Schedule Allows you to define a custom schedule for replication. Click the Customize button to bring up a dialog box with a calendar of hours you can use to set up the replication schedule.

• Use Public Store Schedule Causes the folder to replicate according to the default replication schedule set for the public folder store to which the public folder belongs. This option is the default.

Other options on the Replication tab let you see the last replication message Exchange Server generated regarding the current public folder (the Details button) and set the priority that replication messages concerning this folder should have in your Exchange system.

You can quickly check the replication status of any folder by selecting it in the System Manager snap-in and viewing the Replication tab in the right-hand pane. You’ll find the name of the servers the information was replicated to along with the replication status and last received time. You can also use the Status tab to check the current status of the public store. This information includes statistics on each public information store configured in the administrative group, including the size of the folder, the number of items it contains, when it was last accessed, and when the last replication information was received.

Configuring Replication at the Public Folder Store

Once you have created replicas of a public folder and configured how replication should behave at the folder level, you can also configure how replication should behave at the public folder store level. To do this, open the property sheet for the Public Folder Store object and switch to the Replication tab (Figure 10-17).

Figure 10-17: Configuring replication for an entire public folder store.

You can take two actions on this tab. The first is to configure a default interval for replication that applies to all of the folders in that store. You do this with a drop-down menu like the one used to configure a schedule for an individual folder, as described in the previous section. The value you specify here will apply to all the folders in the store, unless you specify something other than the Use Public Store Schedule setting on an individual folder’s property sheet. In other words, if you set a schedule for an individual folder, that schedule overrides the setting on this tab.

The second action you can take on the Replication tab of a public folder store’s property sheet is to define limits for replication. By default, no limits are defined. If bandwidth between servers is a consideration, you can specify the maximum time, in minutes, that replication is allowed to go on when it occurs. You can also define the maximum size, in kilobytes, of a single replication message.

Note

When folders are replicated, conflicts are possible if users work with different replicas. Exchange has a way to handle replica conflicts intelligently and automatically. The Exchange server allocates revision numbers to all messages posted in a public folder. Using the assigned revision number, the server identifies conflicts as they occur. A conflict might occur when two revisions of the same message are sent from two separate servers to a single server during replication. The server places the conflicting revisions in the replica so that you can resolve the conflict yourself by integrating the revisions or, better yet, by having the authors of the messages work it out themselves. The server then replicates these revisions throughout the organization.

Public Folder Referrals

Users don’t really care which replica of a public folder they connect to. However, we administrators do care for a variety of reasons. When a client requests a public folder, the request is processed in a certain order:

1. The client checks the default public store configured for its Mailbox store to which it belongs.

2. If no replica of the folder is found in the client’s default public folder, the client next checks any Exchange server to which it has an existing connection.

3. The client then checks every other server that is in the same routing group as the client’s home public folder server.

4. The client then checks servers in other routing groups, starting with the lowest cost connections.

As administrator, you can use two strategies to modify the way in which public folder referrals are handled. First, you can configure connectors between routing groups to refuse public folder referrals. The following connectors have the ability to refuse public folder referrals: Routing Group, SMTP, X.400, and X.25. Connectors are discussed in further detail in Chapter 13, “Connecting Routing Groups.”

The second strategy you have for modifying referrals is to customize the list of servers that any particular server can refer a client to. Just open the Property sheet for the server in the Exchange System snap-in, switch to the Public Folder Referrals tab, and configure a custom list of servers.

Synchronizing Public Folder Replicas

Public folder replication follows the multimaster replication model, in which every replica of a public folder is considered a master copy. When you decide which folders you want to replicate, you manually create and configure those replicas. Any change made to a public folder is automatically replicated to other copies of that folder by the Exchange Public Folder Replication Agent (PFRA) service. These copies are based on settings you configure. Replication is an e- mail-based process that uses SMTP as its transport mechanism.

The PFRA uses three primary constructs to keep track of replication throughout an organization and to determine whether a public folder is synchronized. These constructs include the following:

• Change Number The change number is made up of a globally unique identifier for the Information Store and a change counter that is specific to the server on which a public folder resides. When a user modifies (or creates) a message in a public folder, the PFRA for that Information Store assigns a new change number to the message.

• Time Stamp The PFRA stamps messages with the time and date as soon as they arrive in a public folder and applies a new time stamp whenever a message is modified.

• Predecessor Change List This is a list of all of the Information Stores that have made changes to a message and the most recent change number assigned by each Information Store on the list.

Together, these constructs are referred to as message state information and play a role in message creation, deletion, and modification.

Message Creation

When a new message is created in a folder, the Information Store receiving the message assigns a change number to the message and deposits it in the folder. The message is replicated to other replicas of the folder during the normal replication schedule.

Message Deletion

When a message is deleted from a folder, the Information Store running the replica in which the message is deleted sends a replication message to all other Information Stores that host a replica of the folder. When each Information Store receives the replication message, it removes the deleted message from its own replica.

Message Expiration

When a message expires (reaches the configured age limit for messages in the folder), the Information Store deletes the message from the folder but does not send a replication message to other Information Stores. Each Information Store removes expired messages from its own folders based on settings made for that particular store and for the folder. Thus, it is possible for different stores to expire a message at different times.

Message Modification

When a change is made to a message in one replica of a public folder, the PFRA for that Information Store updates the message state information for that message and sends a replication message to other Information Stores on which replicas of the folder exist. This replication message contains the modified message and all its attachments.

When another Information Store receives such a replication message, the modified message inside is used to replace the original message in that store if the message state information determines that the message is indeed newer than the original.

Even though the PFRA sends out replication messages, there is no mechanism in place for ensuring that replication messages reach their destination. The logic behind this is that generating an extra confirmation message for each replication message would unnecessarily double the amount of traffic involved in replication. Thus, it is possible for a message in different replicas of a public folder to become out of sync. A process known as backfill is used to remedy this situation. During regular maintenance, status messages are sent between servers, and change numbers for messages on different replicas are compared. If a server is found to be out of sync, it then generates a backfill request for any changes that have not yet been received.