We sort of shot ourselves in the foot at a client site with regards to the Microsoft Sync Framework when troubleshooting a particular production issue...

We have a central server as the data system of record which exposes a WCF service over which we use Sync Framework 2.0 to synchronize data with disconnected client instances. (Many of the details of the implementation are unknown, it's an inherited codebase.) When troubleshooting a problem on a user's machine at some point in the past, a decision was made to wipe out a particular client's local database and replace it with a known good copy from another client.

Everything *seemed* to work for a while. But there was a detail in the implementation that was unknown to us at the time. Sync internally tracks client database identity. What this meant was that the server couldn't distinguish between the two clients. So one would sync their data and then the other would be left in an unknown state.

We've identified affected users, we're identifying affected data, and we're brainstorming potential solutions. For that latter part, I'm wondering if anybody here has any experience with the Sync Framework and can suggest a potential course of action?

One potential approach we're considering is to identify where and how Sync internally tracks that identity (perhaps a GUID somewhere?) and to change it. This sounds like the quickest fix, though it would at least still leave us with a necessity to touch the affected records again to trigger them to synchronize again.

We don't want to risk losing data, so we're hesitant to drop the client databases and re-provision. But more to the point that process of provisioning a fresh database is a significant hit to resources and user downtime in the current setup, so it's something to avoid if possible.

Does anybody here have experience with the Sync Framework? Has anybody faced this problem before? What avenues of approach would you suggest?