Managing Outlook synchronization logs

Even in an era of massive quotas, it’s annoying to find that mailboxes are cluttered with extraneous logging messages that accumulate steadily and are never removed without manual intervention. So it is with Outlook synchronization logs, which you’ll find tucked away in the Sync Issues folder (to expose this folder, click on the Folders icon and expand the folder hierarchy).

Outlook 2007 and Outlook 2010 generate synchronization logs when errors occur when clients synchronize local replica copies (held in the OST file) of cached server folders. Logically, synchronization errors and log generation only happens when Outlook is configured in cached Exchange mode. (Learn more about Tracking Messages in Exchange 2007).

There are many reasons why a synchronization operation might experience some difficulties. Network glitches are the obvious example – something that is extremely likely to happen when connecting Outlook to Exchange Online in Office 365 when transient network errors are common between the network that the PC client runs on and Microsoft’s datacenters. After all, no one controls the Internet and no one guarantees the speed, latency, or reliability of an Internet connection. Figure 1 shows a synchronization log that reports some network problems between Outlook 2010 and my Exchange Online mailbox.

Figure 1: An Outlook 2010 synchronization log

Other synchronization problems occur when multiple clients attempt to operate on the same item over a short time period when changes made by the different clients can generate conflicts. For example, you might view an item using Outlook on your laptop and look at it through a mobile device. Because there’s a long track record of multi-client conflict generation in Exchange, especially when using BlackBerry clients to view calendar meeting requests, there’s lots of code in the server to eliminate or automatically resolve conflicts, but some still occur. And then there are instances when servers are just too busy to be able to elegantly handle all the incoming RPC threads generated by clients that want to update server folders. This can result in errors such as “synchronization of some deletions failed”, a transient error that is invariably cleaned up by subsequent synchronizations.

All of these problems have existed since Microsoft introduced cached Exchange mode in Outlook 2003. In other words, they’ve been around for the best part of a decade. So why get worried about Outlook synchronization logs now? The reason is that the combination of Outlook 2010 and Exchange 2010 seem to generate more logs than ever before and worse still, Microsoft doesn’t seem to know what’s causing some of the logs (see KB2602009), but they are “investigating”. The result is a fair amount of traffic in social forums to ask why these logs appear and how best to manage their proliferation.

One approach that’s often suggested by Microsoft support personnel is to configure a new DWORD value in the registry to control how Outlook generates synchronization logs. The value is EnableConflictLogging and for Outlook 2010 it is inserted at HKCUSoftwareMicrosoftOffice14.0OutlookOptions.  Use "15.0" for Outlook 2013. The value can be set as follows:

· 0 (zero): Never save modification resolution logs

· 1: always save modification resolution logs

· 2: only save critical modification resolution logs

If the value doesn’t exist in the registry, Outlook’s default setting is “2”.

I set the value to 0 in the registry on my PC and ran Outlook 2010 for a couple of days to observe what happened. It’s true that fewer synchronization logs were generated and the ones that are still created all appear to relate to failures to honor item deletions that have been done locally. However, although fewer logs were created, I regard the reduction (2-3 daily) to be well within the margin of error and could be due to other factors such as better server availability, fewer network glitches, or a heightened awareness on the part of the user. And as I found out a little while later when reading this TechNet article, the registry setting only controls conflict resolution messages generated during synchronization operations and has nothing to do with synchronization logs, so that theory went out the window! 

In any case, I dislike using registry settings to control client behaviour. It’s easy to update a single PC but much more difficult to apply the same update to multiple PCs. For this reason, my preference is to manage synchronization logs with retention policies. The value of this approach is that Exchange will do the work for you to clean out the Sync Issues folder each time the Managed Folder Assistant (MFA) runs to process mailboxes. Using a retention policy also works for both on-premise Exchange 2010 and Exchange Online in Office 365 and it has the added bonus that the policy will exert control over synchronization logs over the long term as new and different clients join the mix.

If you’re running Exchange 2010 or 2013, you might already have deployed retention policies to help keep mailboxes under control. If so, you might imagine that all you need to do to eliminate the pesky synchronization logs on a regular basis is to define a new retention policy tag for the Sync Issues folder and then include the new tag in the retention policies that are assigned to mailboxes. Remember that a single retention policy tag can feature in as many retention policies as you like. However, although retention policies and tags are super-useful in controlling mailbox content for Exchange 2010 servers, they don't help in this instance, even if Exchange 2010 seems to indicate that they might. Here's why.

On-premises Exchange administrators can create a new retention policy tag that seems if it might control synchronization logs and include it in retention policies using the Exchange Management Console (EMC). Office 365 administrators have to use the Exchange Management Shell (EMS). The same EMS commands work for on-premises Exchange .

First, after starting up EMS as an administrator using an account that holds at least the Recipient Management RBAC role, define the new retention policy tag with the New-RetentionPolicyTag cmdlet. The code is as follows:

New-RetentionPolicyTag –Name “Remove Sync Logs” -Type SyncIssues –RetentionEnabled $True –RetentionAction PermanentlyDelete –AgeLimitForRetention 2 –Comment “Retention tag to remove synchronization logs after 2 days”

This command creates a retention tag that MFA will apply to the Sync Issues folder (type = SyncIssues). Exchange 2010 supports three types of retention tags. If the type was “all”, it means that this is a “default” tag that MFA will stamp on all items that are not under the control of another, more explicit tag. A tag of type “personal” is available to the user to be applied to any item, folder, or conversation in a mailbox. A personal tag takes precedence over any other type of tag. Finally, we have a tag that is specific to one of the default folders known to Exchange such as the Inbox, Sent Items, or as in this case, the Sync Issues folder.

Passing $True as the value for the RetentionEnabled parameter instructs MFA that the tag is enabled. MFA will look for items that are older than 2 days (AgeLimitForRetention = 2). Two days is probably enough for logs of the type that we are cleaning up but it’s easy to set the limit to a longer period if you prefer. The action that MFA will take when the retention period expires is to remove items permanently (don’t allow them to be recovered).

All that’s left to do is to incorporate the new retention tag into the retention policies that are in use after which MFA will apply the tag to the Sync Issues folder and remove the offending items. At this point we should be able to relax and reflect on a job well done.

In this case the theory is just plain dead wrong. Even though Exchange defines “SyncIssues” as a valid type for a retention tag, includes this fact in TechNet documentation, and allows you to create a new retention tag of the type and incorporate the tag into retention policies, there’s absolutely no point in doing all this work. Why? The fact is that synchronization logs are not stored in user mailboxes. The logs are created and stored locally and Outlook does not synchronize them up to the Sync Issues folder on the Exchange server. Hence, although MFA will stamp the server copy of the Sync Issues folder with the new tag so that any items created in the folder inherit the tag to force removal after two days, because Outlook doesn’t copy the synchronization logs from the OST to the server folder MFA will never have any items to process.

Having a surplus of Outlook synchronization logs isn’t a huge problem for any Exchange deployment. I can’t imagine that any OST holds more than a couple of hundred logs, each of which occupies a few kilobytes. But there’s something pleasing about running a tight ship where everything is in the right place and nothing more than is necessary is used. Our choices to achieve such a situation are limited when it comes to Outlook synchronization logs. The preferred centralized solution just doesn’t work; the registry fix is hard to manage and isn’t particularly effective; and Microsoft support doesn’t have any other advice that can help. There’s just one solution if you want to clean up these logs and that’s to open the Sync Issues folder on a regular basis and delete the logs manually. Technology fails - sad but true.

Follow Tony’s ramblings via Twitter