\[Editor's Note: Share your Exchange and Outlook discoveries, comments, problems, solutions, and experiences with products. Email your contributions (500 words or less) to [email protected]. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
I recently added several new Exchange Server 5.5 servers to my company's Exchange 5.5 organization and created replicas of existing public folders. Thirty minutes later, the public folders began replicating, even though I had set the replication schedule to begin after work hours. Unfortunately, the public-folder replication messages blocked the company's WAN link during work hours. (During replication, the Public Folder Replication Agent—PFRA—creates a message containing any folder changes, then sends the replication message to the Message Transfer Agent—MTA—which passes the message to the replica public folders.)
After some investigation, I discovered the cause of this problem. The unscheduled replication occurred because of a process called backfilling. To prevent replica public folders from getting out of synch with one another, each Exchange Information Store (IS) periodically sends a message about the status of its replica public folders to two other ISs that have the same folders. (An algorithm chooses which ISs.) If the first IS's replica folder status doesn't match the second IS's public-folder status, the two ISs determine which public folder needs updating by comparing their message-state information. The IS whose folder needs updating issues a backfill request. Any server in the Exchange 5.5 organization that holds a replica of that public folder can fill this request by sending updated data. This backfill process occurs, regardless of the replication schedule and Exchange topology organization, when a replication message is lost (e.g., because of a bad connection); a server's IS databases are restored from a backup; or a new replica public folder is added to an IS, but the folder doesn't have any replicated data when the IS receives a status message.
In my case, adding new replica public folders triggered the backfill process. To avoid this problem, you can use the Microsoft BackOffice Resource Kit (BORK) Pfadmin command-line utility to add replica public folders. If you put Pfadmin in a batch job and schedule that job to run during off-hours, the replication backfill activity won't bog down the network. You can also use the utility to remove replicas and to set public-folder properties.
