Public folders are an afterthought in many Exchange implementations. Administrators tend to concentrate on getting their email infrastructure working properly without giving much thought to deploying public folders. However, public folders offer great functionality. You can use them to host electronic discussions, accept incoming Network News Transport Protocol (NNTP) newsfeeds, and provide outgoing information to newsfeeds. You can associate public folders with electronic forms and use public folders as the basis for applications. You can also use them as most companies do today, as convenient repositories for shared information. You can create public folders to hold documents, spreadsheets, and presentations, and your users can view and manage the data through Exchange clients and the Exchange administration program. (For more information about Exchange, see "Related Articles in Windows NT Magazine," page 190).
Public Folder Basics
Each public folder is a directory object in the Exchange directory. Public folders' properties include access control lists (ACLs), replication schedules, and email addresses. (You can specify email addresses for a public folder to subscribe the folder to Internet mailing lists.) You maintain public folders' properties as you would maintain any other object in the Exchange directory.
Exchange stores the public folder hierarchy and the contents of each public folder in pub.edb, Exchange's public information store. Exchange automatically replicates the public folder hierarchy among all the servers in an organization. When you create a new folder, Exchange enters the folder's details into the directory and sends that information to every other server.
When you add content to a public folder or a server executes a backfill request, Exchange replicates the folder's content to specific servers across an organization. When Exchange needs to replicate an item, it generates a replication message for that item and sends the message to all the other servers in the organization that contain replicas of that item's public folder. You must have directory and messaging connectors in place before public folder replication can work.
Accessing Public Folders
Exchange associates every user mailbox with a home public information store. In many smaller installations, the public information store is on the same server as the user's mailbox. In larger installations, dedicated public folder servers simplify administration and minimize replication traffic.
Messaging API (MAPI) clients such as Outlook establish remote procedure call (RPC) sessions to the home public information store at logon. The clients fetch information about the public folder hierarchy and use this information to build the public folder tree users see. Users might see folders in the hierarchy that they cannot access because either Exchange has not replicated the folder to a server they can access, or an ACL prohibits them from accessing the folder.
When users access public folder content, Exchange attempts to fetch the content from their home server. If a user's home server does not contain a replica of the public folder, Exchange attempts to locate a replica on other servers.
Exchange 5.0 and 5.5 support the concept of subsites. Many companies use sites to represent broad geographical areas, such as North America; subsites let you associate servers with specific locations, such as New York or London. (You specify a server's subsite--its location--as a property of the server, as Screen 1 shows.) If you use subsites, when users request a public folder their home server doesn't have, Exchange attempts to fetch the contents from another server in the same subsite.
If you don't use subsites, or if no server within the subsite contains a replica of the public folder's content, Exchange queries servers at random within the user's site. If Exchange doesn't find a replica within the site, it looks to remote sites using affinity (a mechanism that lets you assign different costs to different remote sites) to decide which site to query next. For example, if a New York site has affinity costs of 10 for San Francisco and 20 for London, an Exchange server in New York attempts to access public folders in San Francisco before attempting to access public folders in London.
Administering Public Folders
Only MAPI clients can create public folders. MAPI clients can also administer folder security, but they can't perform other management operations, such as creating replicas, establishing a replication schedule, or defining which server is a public folder's home server. You must perform most management operations through the Exchange administration program. You can view folder properties from any server, but you can alter properties only on the folder's home server. To view a specific public folder's properties, expand the set of public folders in the Exchange administration program's organizational hierarchy and select the folder, then select Properties from the File menu.
You can use the Exchange administration program to manage all of a particular server's public folders at once. Select the server in the Exchange administration program's hierarchy pane and expand the Public Information Store entry. From there, select the public information store property you want to administer. For example, you can select Folder Replication Status to view the replication status of every public folder and public folder replica on a server, as Screen 2 shows. The Display Name column lists the public folders' names. The Last Received Time column lists the date and time the Exchange administration program last received an update to each folder. The Number column lists each folder's number of replicas within the organization. The Replication Status column shows each folder's current replication status: Local Modified means that a user modified the local folder's content and Exchange has not yet replicated that change to the other servers that host replicas of the folder. In Sync means that all the replicas through- out the organization contain the same data. Remote Modified (which Screen 2 doesn't show) means that a remote server has updates for the local server's replica, but Exchange has not yet replicated that data.
You can also use the Exchange administration program to administer the system folders that the public information store creates on the first server in a site. Exchange hides system folders from users' view. These folders include the Offline Address Book; a folder that publishes Schedule+ free and busy information; a folder that holds permissions for the Event Service; and the electronic forms registry, which is a repository for the electronic forms that all your users access. Screen 3 shows the system folders for a server named Platinum. Exchange can create replicas of system folders on other servers; many organizations replicate Schedule+ free and busy information to save clients from making extended network connections to set up meetings.
Replicating Public Folders
A part of the public information store service called the Public Folder Replication Agent (PFRA) manages public folder replication. Underlying the PFRA are background threads that Exchange activates when the store starts. The PFRA performs several tasks. It maintains folder replica lists, monitors replication schedules, dispatches replication messages at times that the schedules dictate, sends status messages to other servers to ensure that they receive all replicated data, generates backfill requests if a server misses a piece of data, and responds to other servers' backfill requests.
Creating a new replica.
When you create a new replica, Exchange adds an entry for the replica to the public folder's replica list, which is a folder property in the Exchange directory. Exchange automatically replicates the change to other sites through its standard public folder hierarchy replication. Then, clients can see the new replica when they browse the public folder hierarchy. After Exchange replicates a new replica's addition to the hierarchy, it replicates the folder's content.
Pulling and pushing replicas.
Exchange replicates public folder content by either pulling or pushing the content. To replicate folders through the pull method, open the Instances tab in the public information store's Properties box on the server that you want to hold the new replicas. Browse the names of folders on other sites, and select the folders you want to replicate; click Add to add a new instance to the replica list. You can use folder pulling to establish replicas of several folders on a new server.
To replicate a folder using the push method, select the folder on its home server. Open the Replicas tab in the folder's Properties box. Select the sites you want to replicate the folder to, select a server within each site to hold the folder, and click Add. The push method lets you set up replicas of a folder on several servers in one operation.
By default, Exchange 5.5 restricts administrative access for public folders to administrators connected to a folder's home server, as Screen 4 shows. Unless you clear the Limit administrative access to home site check box, Exchange does not accept remote requests to create new replicas, which limits replica creation to the push method. However, the local administrative access property is not an option in Exchange 4.0 or 5.0, and a server with a version of Exchange earlier than 5.5 can pull replicas of folders that you restrict to local administrative access.
To set a new replica's ACL, open its Properties box. Select the General tab and click Client Permissions. You can set specific permissions for individual mailboxes, or you can save time by assigning permissions to distribution lists. You can hide a public folder from user view in the hierarchy by clearing the Folder Visible check box.
Backfilling replicas.
A mechanism called Change Number Sets (CNS) identifies changes to replicated folders. Each folder has a unique set of change numbers based on a globally unique ID (GUID). For example, suppose Exchange increments a folder's CNS by 1 for every addition, modification, or deletion users make to the folder. The folder's first changed item becomes change number 1, the second changed item number 2, and so on. When users have changed two items, the folder's CNS is 1-2. If you create a replica of the folder at that point, Exchange sends the CNS in a status message to the information store on the new replica's server to inform the information store that it must backfill its replica with the content that CNS 1-2 represents. (Actual CNS values are much more complex than 1-2, but they perform the same function.)
The replica's server then creates a backfill request. It keeps the request in a queue for up to 2 hours, waiting to receive messages with the replica's missing content. If the replica's server does not receive the content within the 2-hour waiting period, it sends a message containing the backfill request to the information store on the public folder's home server. When the home server receives the backfill request, it uses the CNS to determine what content the replica needs and sends the replica's server a message containing the missing data. The home server also sends the replica's server a status message containing the folder's current CNS. The two servers continue to generate and respond to backfill requests until the replica's CNS is the same as the home server folder's CNS.
Every day, each replicated folder sends a status message containing its current CNS to all other servers that contain replicas of the folder. These messages ensure that servers check their folder replication status daily and request backfills for missing data. Every message that contains replicated content also includes the folder's CNS, so recipient servers can create backfill requests even if they miss status messages.
Optimizing Public Folder Replication
Every Exchange public folder installation has advantages and disadvantages. Public folder replication benefits an organization in several ways. First, Exchange's replication process provides local replicas users can connect to, which lets users access data quickly. Second, replication increases data's availability because Exchange stores multiple copies of the same data across an organization. Third, replication prevents the excessive network traffic that users would create if they pulled information from one point on the network. Exchange's replication process has two major disadvantages: Maintaining several copies of information increases a system's data storage requirements, and replication traffic can swamp a network.
The key to successful system design is to maximize replication's advantages and minimize its disadvantages. To achieve this balance, you need to restrict the number of replicas in your organization to prevent replication message traffic from weighing down the network. You must make sure you configure each server that hosts a public information store with the appropriate amount of storage space. You must make sure that replication occurs at the right intervals, and you need to limit the size of replication messages.
Replication frequency.
Among the most important public information store properties that the Exchange directory manages is a global replication schedule. However, you don't want all your public folders to use the global replication schedule. You need to replicate folders that hold time-critical information, such as folders that host interactive discussions or track projects, at short intervals. You don't need to replicate folders that hold reference information, such as design documents, more than once or twice a week.
To change an individual folder's replication frequency, open the Replication Schedule tab in the folder's Properties box, as Screen 5 shows. When you set up a customized replication schedule, you can specify three intervals: Always, Never, or Selected times.
If you choose the Always interval, Exchange will create and send replication messages according to the public information store's Replicate Always Interval property. The default Replicate Always Interval is 15 minutes, so by default Exchange replicates changes to public folder content every 15 minutes. This period is too short for most folders. Set the Replicate Always Interval to 60 or 120 minutes to restrict the amount of traffic on your network. To change the Replicate Always Interval, open the Advanced tab in the public information store's Properties box. The Replicate Always Interval is a server-specific property, so you must change it separately on every server on your network.
If you choose the Never interval, Exchange will never send any replication messages. If you know that network links will be unavailable for a period, set the interval to Never to prevent the public information store from producing messages for the Message Transfer Agent (MTA) to queue.
If you choose the Selected times interval, Exchange will produce messages according to the schedule you define in the folder's Replication Schedule time grid (which Screen 5 shows). The time grid measures hourly intervals; replication activities scheduled for a particular hour begin at the start of the hour. You can set the grid to 15-minute intervals. Use the Selected times grid to restrict replication operations that aren't time-sensitive to hours when interpersonal mail volume is low to prevent replication messages from interfering with mail flow between users.
When you establish a new organization, set a global replication schedule that restricts activity to off-peak hours. As you assemble your public folder hierarchy, review each folder's purpose and decide on its appropriate replication frequency. Always make sure that interpersonal messages have priority over replication messages.
Replication message size.
A size limit for replication messages is another global property that the Exchange directory maintains for the public information store. Exchange replicates public folder changes at the item level. If you update a 2MB document in a public folder, Exchange replicates the whole document.
To prevent public folder replication traffic from creating a bottleneck on your network, you need to limit the size of replication messages. You can limit the size of public folder replication messages that contain changes to more than one item by adjusting the Replication Message Size Limit on the Advanced tab of the public information store's Properties box. For example, if you set the Replication Message Size Limit to 100KB and Exchange places six 30KB items into a queue for replication, the store will create two 90KB replication messages, each of which contains replication data for three items. If the replication of one item exceeds your size limit, the MTA lets the large message pass.
Troubleshooting Replication
Replication flows smoothly as long as messages flow between Exchange sites. Most problems with replicated folders stem from problems with user access. Most user access problems arise from one or more of the following conditions: the user's site does not contain a replica of the folder, you haven't defined affinity, affinity can't work because necessary servers lie in untrusted NT domains, or the user doesn't have permission to access a folder.
If you have a problem with public folder replication that you can't attribute to user access problems, replication might not be working on your system. Check to see whether you can send a message to a mailbox on the problematic folder's home server. Set a delivery and read receipt on the message so Exchange notifies you when the message reaches the server and when the recipient reads it. You can use the Exchange administration program's Message Tracking Center (under Tools, Track Message) to follow the message's path, provided that all the servers along the message's path have message tracking logs enabled.
The NT Application Event Log logs replication events, so another way to check your system's replication process is to turn up diagnostics for the public information store and examine the collected data. Open the Diagnostics Logging tab in the public information store's Properties box, which Screen 6 shows. The default Logging level is None, which means that the Application Event Log records only errors. Use Medium or Maximum to have the Application Event Log record a server's replication activities. (Be aware that a large volume of events accumulates quickly on servers that host busy public folders or replicate at short intervals.)
You can monitor replication events on any server that holds a replica, but replication problems are most evident on a folder's home server. Select a folder that has a replica on the site you are having difficulty replicating to. Set the folder's replication interval to Always. Add content to the folder: Create a new item or drag a small file into the folder. If replication is working, replication events will appear in the Application Event Log on the server that you added content to and on every other server that maintains a replica. Check the Application Event Log on the server that holds the problematic replica for events indicating that the server received the content change.
Screen 7 illustrates the type of information the Application Event Log captures for outgoing replication messages. The message in Screen 7 replicates information from a subfolder called Premier Support Newsletter within a folder called Exchange Server Information. The CNS appears below the folder and subfolder names. This replication message has a message type of 4, which means that it contains new content that one server is replicating to another. A type 2 message adds a new folder to the hierarchy or deletes a folder from the hierarchy. A type 8 message is a backfill request. A type 10 message contains a report of one or more folders' CNS. A type 20 message is either a server's request for a folder replica the server can retrieve information from, or a message that a replica is still active.
Public folders are a very useful feature of Exchange. With a little care and maintenance you can deploy public folders as the basis for information-sharing applications, such as document management and distribution. Public folders make Exchange more than just an email server.
