Update
The current “Best Practice” is to upgrade your Exchange Server to Service Pack 2 and apply Update Rollup 3 for Exchange Server 2010 Service Pack 2 (KB2685289), as this issue has been permanently solved.
See Synchronization of an organizational forms library fails when you use Outlook in Cache mode in an Exchange Server 2010 for additional information.
Hello Everyone,
Since the first migrations of Exchange 2003 to Exchange 2010 we’ve seen a really annoying error within Outlook 2003, 2007 and Outlook 2010 when trying to De-commission legacy servers, specifically when moving all public folders replicas including the EFORMS REGISTRY system folder and it’s children folders. once the organizational forms ( respectively you might see a different folder name within your organizatino ) is replicated only to the Exchange 2010 – a log / error message will be created in the Sync Issues upon an Outlook Send/Receive operation:
11:56:54 Synchronizing Forms
11:56:54 Downloading from server ‘public folder server‘
11:56:54 Error synchronizing folder
11:56:54 [80004005-501-4B9-560]
11:56:54 The client operation failed.
11:56:54 Microsoft Exchange Information Store
Notice: Use this method at your own risk ! This method is for organizations that do not use Forms !
Many posts and different resolutions were recommended, my original “fix” for this issue was to not replicate the organizational forms folder to the new Exchange 2010 public folder when starting to De-commission the Exchange 2003 server, practically “leaving it behind”.
I recently handled a situation where the Exchange 2003 server was already removed, and the forms folder was already replicated to Exchange 2010, and the error was already in place. I could not use Exchange 2003 System Manager to remove the replica, Exchange Management Shell or EXFolders. You cannot really leave an empty replica list within the tools.
MFCMapi to the rescue 🙂
- Open MFCMapi, click the session menu, select the logon and display store table option.
- Double click public folders, expend the public root tree, expend NON_IPM_SUBTREE, expand EFORMS REGISTRY.
- Locate and select the organizational forms folder.
- Scroll the property list to find the PR_REPLICA_LIST entry – double click it and clear the value inside – clear means delete the values inside the property. Setting PR_REPLICA_LIST to NULL actually leaves us with an empty replica list – which “solves” this issue.
- Note that when you click to apply the change of the PR_REPLICA_LIST the property list will immediately shrink, this is normal 🙂
- Exit Outlook, wait and see that indeed the Sync Issues folder does not include a new log with the 80004005-501-4B9-560 error.
Use this method at your own risk ! and again – this method is for organizations that do not use Forms !
Some references for you usage:
Troubleshooting: Error synchronizing folder Synchronizing Forms 80004005-501-4B9-560
Outlook synchronization error [80004005-501-4B9-560] with a Microsoft Exchange Server 2010 mailbox
This sounds exactly like my problem! I will try your suggestions this weekend (hopefully) and will report back. Thanks for the info — I have confidence this addresses my problem.
Grest! keep me updated, will be happy to hear this worked for you.
I followed the instructions to remove the non-existent replica, but I’m still getting sync errors whenever Outlook is opened. Can I use this tool (MFCMapi) to delete the Organizational Forms? I believe I added the Org Forms years ago while we were on 2003 because I was playing with Outlook form designs. We are not actually using any forms. Your thoughts are appreciated. 🙂
Oh — I answered my own question. Prior to using the MFCMapi tool, I was unable to delete the Org Forms using the EMC. Having removed the invalid replica I was then able to delete the forms. I suspect problem is solved! Thank you!
Happy to hear that Louise !
Would appreciate your confirmation that the issue was indeed solved.
ilantz
Is there any way to re-populate the information that was cleared? This resolved our issue with the sync issue errors, however it broke our forms. I was unaware that we used forms in our organization at the time, but someone had developed one over 10 years ago that is apparently still being used .. :-/ … help!
Hi Dan, you should try to add a replica to the current public folder, the content might still be there.
It is not the solution – it does only remove Replica from the EFORMS Folder and the FORMULARS for applications are not longer aviaible so it is not practicable to do this. My Faxserver doest work after this action so i place replicas back on folder
Thanks Marc,
I did wrote that this solution is for organizations that do not use Forms, i will make this statement more BOLD 🙂
Any suggestions for resolving this if you do use forms?
Well, my suggestion will be, replicate all public folders, and under system public folders, replicate only the free-busy and offline address book directories.
Leave the FORMS directory on the 2003 until you will decide to decommission it. that is when you will run the “move all replicas” command.
ilantz
Thanks for this post ilantz. I reproduced this sync issue in my lab and fixed it using your suggestion, and then proceeded to resolve this issue in our production environment.
Glad it worked for you Matt ! Thanks for your update.
Wonderful, this was the solution after a long lasting search and much of microsofts postings like “this is not a bug, please ignore the errors !!!!
And what is more: thousands of people are STILL searching a solution to this problem.
Isnt there a way to make Your solution public to a wide audience ?
Well, thank You a thousand times und regards,
Stefan
Thank you stefan,
I’ve posted my solution to the popular threads in the technet forums and my blog,
feel free to share it on 🙂
Glad it worked out for you.
ilantz