Public Folder Replication Problems: "Multiple Edits Have Been Made"

If you use public folders, at some point you're likely to see replication conflict messages, including the infamous "Multiple edits have been made. The conflicting edits have been attached to the conflict message." What causes this message, and how do you fix it?

The short answer is that this message appears when changes are made to the same item on different public folder databases during the replication window. Consider two users, Alice and Bob. Alice's mailbox is on server A, and Bob's is on server B. If Alice creates an item on server A, that item will be replicated to server B.

If Bob opens the item after it replicates and makes changes to it on server B, those changes will be replicated back to server A, and Alice will see them. This case is the simplest, and easiest, because there isn't a replication conflict.

Suppose that Alice opens and edits the item on her server, then saves it. Meanwhile, Bob has opened the item on his server and worked on it while Alice's edits are being replicated. When Bob tries to save the edited item, he'll get a message indicating that the item has been edited and saved since he opened it; he'll have to reopen the item to get the most up-to-date version. This is a simple case too: The client detects the conflict and warns Bob that it exists.

The fun starts if Alice and Bob edit the item more or less at the same time—but within a single replication period. If public folder replication happens every 15 minutes, for example, then they'd both have to edit their local copies of the item within the same 15-minute period. Alice edits the copy on A, Bob edits the copy on B, and when the public folder replication engine gets ready to send the changes, it detects a conflict and you get the warning message.

Of course, if you're not using public folders for direct collaboration, you might wonder whether this error is something you need to know about. The answer is a distinct yes! That's because the most common cause of this error is actually in free/busy replication, particularly when you're using delegates. Microsoft has long recommended that you keep delegates of a mailbox on the same mailbox and public folder store, but this recommendation is observed largely in the breach.

If you're seeing lots of these conflict messages, the simplest way to fix this is to keep all free/busy folders in the default public folder store for each mailbox databases so that Alice and Bob both access the same replica of the public folder. If you can't do that, you should ensure that each boss/delegate team has its mailboxes on the same mailbox database and that both are using the same public folder for free/busy data. You can also consider using Outlook 2007 and Exchange Server 2007, which have the ability to use the Availability service for free/busy data instead of public folders.