Microsoft Sync Framework
People do synchronization for a number of reasons. Perhaps you have to operate in a disconnected environment. Outlook is a good example of this. Peer-to-peer is another sync model.
SQL Server comes bundled with some powerful sync functionality. Merge setup is tough and not so flexible, but custom code is not really required. You do need administrator and DBA intervention, though. Sync Framework is very flexible but requires custom code. Sync Services for ADO.NET, what Nino covered tonight, sits nicely between these two extremes. It puts more control in the hands of the developer. Essentially, if you can write a provider for it, you can sync it.
Sync Framework ships with File System, ADO.NET, and FeedSync providers. Mesh runs off the FeedSync protocol, it's not using the provider but the protocol. The point is that the same protocol used in LiveMesh ships with the Sync Framework. You can write a custom provider, but it's not recommended. It's a lot of work.
The data store can be any data source in Sync. It is that simple. Configure a client provider, a server provider, and a sync agent and that's it. Instruct the Sync Agent to sync and you're done.
The Wizard Click, Drag, and You're Done
When using the synch-ing wizard, it creates a file with a .sync extension to hold configuration information. A Wizard starts up and allows you to configure data sources. You'll see a "Use SQL Server change tracking" which is a useful option. This presents a number of aditional configuration options. After running the Wizard a number of SQL files get created that setup change tracking within SQL Server.
Not all data stores are created equally. A full participant will store metadata and you'll need a storage location. A partial participant will not store metadata. You'll need to make some decisions about the tradeoffs.
For additional information on the Sync Framework take a look at these Sync resources
Sync Developer Center
MSDN Code Gallery
This Sync Framework Blog and The Synchronizer Blog