Hi: We have custom Outlook forms which synch information from popular accounting systems to a Contact folder which has the form applied as part of the installation. Exchange users have been using this for years, with minor problems. In the past, the synch has not completed and an error message is thrown: One or more items in the folder you synchronized do not match. To resolve the conflicts, open the items, and then try this operation again. We have had this intermittently over the years, and only ever with MS Exchange installs but not always. I have been able to resolve this in the past by telling users to open the conflict items, and Keep the latest edit. They have only had this issue once or twice, and then no more issues. However in the past 3 months or so, this issue has got WAY out of hand, and I have not been able to resolve. It seems to point to settings in Exchange which control how changes in a shared folder are handled. I'm not sure if this MSDN article provides a possible solution. It seems that some changes need to be made within the registry to instruct Exchange on handling changes to prevent the conflicts being thrown. Only a handful of our users are having this issue, and working with different versions of Exchange and Outlook - no consistency we can see. And conflicts have been thrown not only when our synch happens, but even if a user adds a note, so not necessarily related to our forms and software. My question specifically is three-fold: 1. Have there been some changes over the past few months with how Exchange handles changes made by users? 2. Is there a setting within Exchange which can be changed to "allow all changes" to the folder by any of the owners? (All users have full owner permission) 3. Has anyone come across this before? Cathy Allington You Grow Pty Ltd

1. I don't know. 2. I don't think so, and I don't think you'd like the results as some users' changes would be overwritten by others with no notice. 3. Of course. There are two simple ways to get around this. The first is to remove all but one replica of the public folder so that there are no multiple versions causing conflicts. Of course, you can still have revision race conditions where the first of two people editing the same document who stores the document back has his revisions wiped out by the second. The second way is to move the content to a mailbox, and that has the same limitations. Your problems and these weak workarounds just point out how Exchange is a lousy document management system. It's probably the best thing out there for messaging and threaded conversations and the like, but it's always stunk as a document management system. No surprise--it was never designed to be. The real answer is to install a SharePoint server, create a document library and require check-in-check-out and version control for documents. That way, even if you have conflicts, they should be rare, and you'll still have the old versions stored in the database.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

1. I don't know. 2. I don't think so, and I don't think you'd like the results as some users' changes would be overwritten by others with no notice. 3. Of course. There are two simple ways to get around this. The first is to remove all but one replica of the public folder so that there are no multiple versions causing conflicts. Of course, you can still have revision race conditions where the first of two people editing the same document who stores the document back has his revisions wiped out by the second. The second way is to move the content to a mailbox, and that has the same limitations. Your problems and these weak workarounds just point out how Exchange is a lousy document management system. It's probably the best thing out there for messaging and threaded conversations and the like, but it's always stunk as a document management system. No surprise--it was never designed to be. The real answer is to install a SharePoint server, create a document library and require check-in-check-out and version control for documents. That way, even if you have conflicts, they should be rare, and you'll still have the old versions stored in the database.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hello, Is there any update on this thread? Thanks, Simon

Hi Simon: Weird - I had responded, but my reply was lost! SharePoint is not a viable solution for us - the conflicts are related to contacts in a contact folder. I am desperately keen to find an answer on this - not sure about the replicas and how to do this. If you have any ideas or suggestions, would be very much appreciated thank you Best Regards CathyCathy Allington You Grow Pty Ltd

http://technet.microsoft.com/en-us/library/bb124322(v=EXCHG.65).aspxEd Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed: Thanks for that. Don't think the replica issue would have worked, as the 2 clients who had this issue were not using public folders. In both instances, each user had created a new OL user profile, and the default contact folder was shared out with Owner permissions to each user. We have changed one client over to a Public Folder, and that seems to have resolved the issue. We also tried the http://msdn.microsoft.com/en-us/library/ff960288.aspx for the other client, but that didn't resolve the issue. Any other thoughts/suggestions would be much appreciated thank you!Cathy Allington You Grow Pty Ltd

If one or more of the users use offline or cached mode with this folder, you can have the same problem. Seriously, you can have this problem with any client-server system that doesn't lock the data before editing and unlock it afterward (like SharePoint's check-out-check-in does). The problem becomes worse when the data in question is multimaster as with public folders, or cached mode where each user has his own copy of data that is synchronized with the host. As I said before, Exchange is a lousy document management system and you have to accept that race conditions will occur because of the nature of the product.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks Ed Appreciate your comments, but we HAD to make this work and resolve it. Interestingly enough, and for others who may have experienced the same issues. When our client followed this MSDN article, they had a couple of issues with conflicts for the first 2 synchs - since then, no more. So it really did seem to come down to an issue or settings within Exchange. Which is what seemed logical to me. Conflicts were being thrown up, because Exchange "did not know" how to handle changes made to a contact record. Has anyone else had this issue???Cathy Allington You Grow Pty Ltd