Sync Recovery Procedure

If you are simply trying to force ALL Destination objects to update, we recommend the use of Forcemods first, before trying this Recovery Procedure.

IMPORTANT NOTE: If you are considering a Sync Recovery Procedure with a Google Workspace Destination (gcontacts), please note that this WILL result in duplicate objects! With a blank database, a new ID is generated in Google Workspace, so you will end up with orphans if you must perform a Sync Recovery Procedure. We urge you to contact Technical Support before proceeding.

In the event of database corruption, it may be necessary to perform a Recovery Procedure on the connection. One thing you risk losing when running the Recovery Procedure is any Deletes that have occurred on the Source since the last successful sync was run. Deletes are performed when an object that was once part of the scope of the sync is now absent from discovered data. Since UnitySync can only track needed deletes based on its data file, when you delete the data file UnitySync doesn’t know a delete is required.

To avoid leaving orphaned objects on the Destination when running the Recovery Procedure, if possible, you should run a regular Sync immediately prior to the Recovery Procedure. If this isn’t possible, you’ll need to manually delete the orphaned objects following the Recovery sync. This is easy to do! Simply refer to this article which explains orphans and deleting them from your Sync container.

There are two other potential problems with using the Recovery Procedure:

• Manager attribute - with the data file gone, if an object syncs before its manager’s object does, the manager object data will not be resolved, resulting in the removal of the manager data from the Destination temporarily. On the second sync run (as recommended below) this manager data will be re-added to the Destination object.

• Group membership - if you are syncing Groups as Groups, and group objects sync before all of their members have synced, it is possible that some members may be removed from the group on the Destination temporarily. On the second sync run (as recommended below) these group members will be re-added to the Destination group.

IMPORTANT NOTE: If any of your internal processes rely on either of these attributes (manager or group membership), you may want to schedule your Recovery Procedure for a time when it will have the least impact on end users. We can also help you with temporary configuration settings to mitigate the issues (i.e., temporarily comment out member or manager). If you would like advice on proceeding please contact us at support@dirwiz.com for assistance.

Sync Recovery Procedure:

• As noted above, run a Discovery and Synchronization as normal to process any outstanding Deletes.

• Delete .db files for your connection.
  ...\UnitySync\Connections\YourConnectionName\*.db

• Run Discovery and Synchronization again. This will perform a full Sync to the Destination directory. Any pre-existing records will be linked in new data files and all linked records will be modified to ensure their attributes are populated with current information.

• Run the Sync a second time. Only the Sync phase need be enabled here. This is just to ensure updates to all objects, as described above.

• If you disabled Discovery, be sure to re-enable Discovery now to resume normal syncing.

If you have any errors on Sync after the second run, please contact support@dirwiz.com for further assistance.