For details, see Pull Sync Delete Threshold.
When pulling device data, for example LDAP users from an LDAP device, the results returned to VOSS Automate depend on the LDAP server configuration. For example, if the returned results exceed the LDAP server configured maximum, and if the server does not support paging, an appropriate error message is returned. Push to Device ............... Sync type *Push to Device* is available only to Cisco Unified CM device types. In a *Push to Device* sync type, devices are synchronized with the VOSS Automate system data state, which is the primary data state. * When deleting device data from VOSS Automate so that the key is in the *device* list but not in the VOSS Automate list (for example, delete user in VOSS Automate), the user is removed from |Unified CM|. The user will not exist on the device or on VOSS Automate. * When adding new device data to VOSS Automate so that the resource shows instances that are not shown on the device, a *push* data sync synchronizes the device data with the VOSS Automate data. For example, adding a ``device/cucm/User`` instance to VOSS Automate and running a *Push to Device* sync adds the user record to |Unified CM|. Keys found in both lists are ignored. Existing records are not updated in either direction. In the ``device/cucm/User`` example, if the same user exists on both VOSS Automate and on |Unified CM|, no update occurs in either direction. Detailed settings may still not match after a *Push to Device* sync. .. important:: When performing a *push* sync, it is important to consider data dependencies between different models. For example, data dependencies may exist between users and phones in the Cisco Unified CM. In this case, if a user is associated to a phone (via the associated devices on the user), you can't add the user if the phone does not yet exist in in Cisco Unified CM. On the other hand, for ownerID on the phone, pushing the phone first will fail since the user isn't in place. This might mean running the *push* sync multiple times so it loads in the required order, or you may need to modify data (such as removing device association) to allow the *push* sync to succeed. .. note:: The keys list sync logic described in this topic implies that in case of a reversion of the |Unified CM| to restores/inactive partitions, the end-state of the relevant pkids may differ to their state the last time VOSS Automate was in sync with |Unified CM| (before a restore), particularly if testing occurred in between. This means you may, for example, have a user with the same username in both VOSS Automate and |Unified CM|, but if that user's pkid in |Unified CM| now differs to the one in VOSS Automate from previous syncs or interactions, they will be seen as different users even though they have the same usernames. .. * Merge with Device - This is a combination of pull and push data synchronization and takes place in both directions. .. Merge data synchronization synchronizes data between the system and the |Unified CM| data without overwriting or deleting any data. .. * If you create a resource where the key is in the 'device' list but not in the VOSS Automate list (for example, the entity is in |Unified CM| but not in VOSS Automate), then the VOSS Automate resource is created. For example, adding a user in |Unified CM| will create the ``device/cucm/User`` record in VOSS Automate after the merge sync. .. * If you add to a device so that the key is in the VOSS Automate list but not the 'device' list (for example, the entity is in VOSS Automate but not in |Unified CM|), then the device resource is created. For example, creating a ``device/cucm/User`` record in VOSS Automate will create the user in |Unified CM|. .. Keys found in both lists are ignored, for example no updates will be made for existing records in either direction. So in the ``device/cucm/User`` example, if the same user exists in both the VOSS Automate and |Unified CM| system, then no update occurs in either direction. In other words, detailed settings may still not match after a Merge with Device sync. Change Notification Sync ......................... Sync type *Change Notification Sync* is available only to Cisco Unified CM device types. A *Change Notification Sync* is a pull sync of changes stored in the local collection that is updated by the Change Notification Collector service. For more details on Change Notification Sync, see the related topics in Data Sync section of the Core Feature Guide. Purge Local Resources ...................... In a *Purge Local Resources* sync type, all resources or instances of device information that exists in the system are deleted. Entities in the device are not deleted. .. note:: The default *purge* syncs created when adding a CUCM, CUC, LDAP or CCX server type are disabled by default. To use the *purge* sync, the "Remove" check box must first be cleared on the "Disabled Operations" tab of the relevant sync. This sync type is typically used when cleaning up the system. The system displays a warning before executing an enabled *purge* sync. See the following sample device type syncs: * HcsPurge-{{CUCMHostname}}--{{CUCMClusterName}}-DS * HcsUserPurgeDS-{{CUCMHostname}}--{{CUCMClusterName}} * HcsPhonePurgeDS-{{CUCMHostname}}--{{CUCMClusterName}} * HcsPurge-{{CUCXHostname}}--{{CUCXClusterName}}-DS * PurgeUccx-{{UCCXHostName}} * HcsLdapUserPurge--{{UniqueID}} * PurgeSpark{{CustomerName}} .. |VOSS Automate| replace:: VOSS Automate .. |Unified CM| replace:: Unified CM