Those of you who read my “other” blog (at WindowsITPro.com) are probably aware of my views on Outlook’s continuing failure to be able to suppress or otherwise deal with the generous number of synchronization logs that the client generates. Last May, I wrote about the fact that it is impossible to use Exchange retention policies to eliminate the pesky logs and that the suggested registry settings prove to be as ineffective.
Now I see that the nice people who work in Microsoft Support have given up the ghost too and issued KB2686541 that explains that you might “notice that messages are being created in the Sync Issues folder” but that “MRM does not process or delete the items” because “the folder is a client-side folder only. In this context, MRM means “Messaging Records Management”, the Exchange subsystem devoted to controlling content in user mailboxes. It really means MFA, the Managed Folder Assistant, because that’s the Exchange 2010 server component that does the processing of retention policies and would very much like to get its hands on Outlook’s synchronization logs, if only they weren’t hidden away in that client-side folder.
All of this is eminently understandable and logical from an Exchange perspective. You cannot expect a server-side assistant to be able to reach down to fetch items stored in the Sync Items folder if Outlook has never synchronized those items to the server. The error from Exchange’s perspective is that it lulls administrators into a false sense of retention security by allowing them to create a retention policy tag for the Sync Issues folder and include that tag into a retention policy that’s then applied to user mailboxes. All happiness and light in the eyes of the administrator; but frustration and inability to execute on the part of MFA.
What gets me is that this issue has been in existence for a very long time. I imagine that the Outlook developers have even noticed it themselves, that is assuming that synchronization conditions occur within the sacred halls of Microsoft’s datacenters to force Outlook to spit out the offending items. But perhaps Outlook’s developers don’t notice these small and irritating issues that occur for administrators in production environments, if only because users tend to notice the presence of synchronization logs (well, inquisitive users anyway) and then ask questions or even expect administrators to do something to rid Outlook of the synchronization log plague. The high standing that administrators find themselves in the eyes of users is the somewhat corrupted when users realize that the all-powerful administrators can do nothing to eradicate the logs. Even MFA’s application of retention policies, the most invasive process that an administrator can apply to a user mailbox, is powerless.
Clearly something has to be done about this problem. Outlook 2013 insists that what was good enough for its predecessors is good enough for it and continues in the long line of clients that churn out synchronization logs ad nausem. Maybe we should have a write-in campaign to ask Microsoft to provide some method to suppress the logs. After all, few people ever want to know the details of why some transient network condition caused Exchange and Outlook to argue about the exact condition of an item. In fact, I can’t think of a single situation when I found something useful in a synchronization log. This might just be me, but I suspect that others find themselves in the same state.
Even though those of us who attend the Microsoft Exchange Conference (MEC) in Orlando next month might let off some steam by complaining to the many members of the Exchange development group who will be gathered at MEC, I think that a write-in campaign sounds like the right thing to do and could be more effective. The appropriate destination seems to be PJ Hough, an old colleague of mine from Digital Equipment Corporation’s Dublin, Ireland office who has risen to the Olympian heights of Vice President of Program Management in Microsoft’s Office division. PJ seems like a good recipient for multiple copies of Outlook synchronization logs that you can find in your Sync Issues folder, if you only care to look. But don’t tell PJ that I told you to send him your logs. He might not like to receive the volume of logs that you might send. On second thoughts, this is probably a bad idea and you should send your logs to your ever-friendly local Microsoft representative instead, who can then transmit the logs to an appropriate location within the Outlook chain of command.
Let’s make 2012 the year that Outlook synchronization logs are finally eliminated!
Follow Tony @12Knocksinna