Abstract: Extending hierarchical synchronization (sync) scopes to non-hierarchical scenarios may involve a method for synchronizing differently organized data stores comprising mapping different physical organizations to similar logical organizations and utilizing an organization-based synchronization algorithm to synchronize the differently organized stores. Also, the uniqueness constraints of the organizations may be preserved as well as the parent-child ordering constraints of the organizations.

Abstract: Tombstones can be removed from a data store without data corruption. Tombstones placed into a forgotten knowledge list can be compared against each other and/or items in a tombstone table, and deleted when tombstones representing subsequently deleted items are extant. Also, creation database version information can be kept along with database items, and databases can record database version information when they synchronize. If a synchronizing database discovers an item that it does not have, but the creation database version information associated with the item reflects that the synchronizing database “should” have the item, then it can be inferred that the item was subsequently deleted, and item resurrection can be prevented.

Abstract: Update-delete conflicts detected during synchronization can be resolved in favor of the update or the deletion. Resolving the conflict in favor of the deletion results in the entity deleted on one replica being deleted on all selected replicas. Resolving the conflict in favor of the update results in the updated entity, which includes an entity moved from one hierarchy to another, being replicated on all selected replicas. To resolve the conflict in favor of the update, the deletion is treated as though it were reported erroneously. The deleted entity is resurrected in the form of the updated entity. Change version information is maintained in all replicas. Update-delete conflicts are resolvable in accordance with various resolution policies such as the update wins, deletion wins, changes occurring on a particular device wins, and most recent event wins, for example.

Abstract: Systems, methods, and computer program products for synchronizing items at replicas within a topology is disclosed. Items are stored in physical tables at the replicas. The physical table layouts at each replica can differ but are mapped to a common logical view. When a replica receives an indication that synchronization should be performed, the replica determines if changes have been made at the replica that should be mapped to the logical views. Replicas can facilitate this by comparing local change enumerations for changes made in physical tables to synchronization local change enumerations for changes in the logical views. Any changes that need to be synchronized are sent through the logical views to other replicas in the topology.

Abstract: The subject invention relates to systems and/or methods that perform an authoritative and/or a non-authoritative restore of items in a data store. Backups are provided that include data associated with items and metadata related to the items that can include a history of operations and previous synchronizations to enable replications to converge after restoration. The operations that can be performed on the items include, for example, create, delete, update, move, etc. The items in the backups can be restored along with the metadata, which can be utilized to enable synchronization partners to converge based on a desired type of restoration.

Abstract: Caching mechanisms in which when a request to operate on particular identified network data is detected, the mechanism refers to a set of rules to determine whether to operate on a local copy of the identified network data, and whether to operate on the actual network data over the network. The set of rules are at least partially set by a human such as a user or network administrator, or perhaps by an application. The caching mechanism may optionally even block local read operations until the network data is synchronized with the remote copy of the network data. The mechanism may also block local write operations until synchronization is performed and/or the write operation is performed on the remote copy of the network data.

Abstract: Disclosed are systems and methods pertaining to data synchronization and move handling support. In particular, a move log is maintained that identifies data that has moved in, out, and within a synchronization scope. Furthermore, the log comprises times associated with when data moves in and out of the synchronization scope. Systems and methods can interact easily with the generated and updated move log to facilitate determining data versions and identifying new data that may need to be synchronized.

Abstract: Methods for enabling multi-master synchronization of particular sets of data using filters. In a synchronization request, data including knowledge and filters may be supplied. A response may comprise data including changes that are identified by the filter and that have versions that are not known by the requestor.

Abstract: A system and method for synchronizing a database having metadata and raw data. Metadata may be fully synchronized between two systems, with copies stored on both systems. Raw data may be selectively synchronized, so that a client system need not store all of the raw data locally. When disconnected, the client system may identify certain portions of the raw data to store locally, and such data may be synchronized when reconnected to a server system.

Abstract: Various embodiments of the present invention are directed to synchronization utilizing one or more optimizations through the utilization of metadata. For several embodiments of the present invention, one method for optimizing synchronization is to reduce the overhead required for said synchronization by having each peer only tracking changes for itself and other peers within its change community (or communities) (a.k.a., “Intra-Community-Only Change Tracking Optimization”). For certain embodiments of the present invention, another method for optimizing synchronization is to not create synchronization overhead until required. For numerous embodiments of the present invention, yet another method for optimizing synchronization is to minimize redundant use of a partner's unique global ID—a large and cumbersome number—and to instead maintain a table that cross-references each partner (and its unique global ID) with a smaller and much less cumbersome partner key.

Abstract: Systems and methods for replicating replicas in a sync community. Each replica in the sync community stores knowledge that represents changes the replica is aware of. Because each replica has its own knowledge, each replica does not need to know how many replicas are in the sync community or the topology of the sync community. By sending the knowledge with a request for changes, a replicating replica can enumerate the changes to replicate by comparing its knowledge with the received knowledge. After replication, the knowledge is updated. Knowledge may also include made-with-knowledge change IDs that permit each resolution to identify what a replica was aware of when a particular change was made. The made-with-knowledge values are used to detect conflicts during replication.

Abstract: Systems and methods for synchronizing data stores. A framework including a sync runtime enables consistent and manageable synchronization between a data store and multiple, diverse back end data stores. The sync runtime provides services such as change enumeration, conflict detection, metadata management, item ID matching, sync interruptability, and the like that are accessible to configurable adapters over an application programming interface. Each synchronizing data store can uses a sync controller to initialize an adapter that can access the services provided by the sync runtime. The sync controller can use a profile to configure each adapter. The profile can identify conflict resolution policies, synchronization filters, source and destination folders, sync direction, and the like.

Abstract: Systems, methods, and computer program products for synchronizing items at replicas within a topology is disclosed. Items are stored in physical tables at the replicas. The physical table layouts at each replica can differ but are mapped to a common logical view. When a replica receives an indication that synchronization should be performed, the replica determines if changes have been made at the replica that should be mapped to the logical views. Replicas can facilitate this by comparing local change enumerations for changes made in physical tables to synchronization local change enumerations for changes in the logical views. Any changes that need to be synchronized are sent through the logical views to other replicas in the topology.