[Index]

Model: data/DataSync

Data Sync

Full HTML Help

Overview

Data syncs can be performed from within Automate or directly on a device. For this reason, cached Automate data should be periodically synced with data on devices.

Examples:

• When an instance of a CUCM is added to the system, its data is imported and cached.

• When instances are added, updated, or deleted from the CUCM, the cached data in Automate becomes out of sync with data on the device.

• When deleting data from CUCM before deleting it from Automate, the system displays the following error: "The specified resource could not be found"

  This means the resource is out of sync, and Automate may need to re-sync with CUCM in order to delete it or update it.

Automate data syncs allow you to dynamically synchronize cached Automate data with data on devices. The data sync instance is associated with the connection parameters of a device type in Automate.

Supported devices include:

• HCM-F (if installed)
• Cisco Unified CM (CUCM)
• Cisco Unity Connection (CUC)
• LDAP
• WebEx
• MSTeamsOnline (Microsoft Teams)
• MSGraph

Individual add, update, and delete operations carried out by a data sync instance can be disabled on the user interface. If no operation is selected, the default behavior is maintained.

Related Topics

Sync Overview in the Best Practices Guide

Data Sync Types in the Core Feature Guide

Model Instance Filter in the Core Feature Guide

Data Sync Settings

To view the summary list of configured data syncs in Automate, go to (default menus) Administration Tools > Data Sync. The list view displays basic details for each available data sync, including a number of summary attributes that provide additional details about the data sync.

To view data sync settings, click on a data sync in the list to open the configuration page.

The table describes a number of key settings that are available for data syncs:

+--------------------------+-------------------------------------------------------------------------------------+
| Quick Import             | Uses the list API responses to update the Automate cache, and won't perform         |
|                          | individual GET calls for each entity for the update.                                |
|                          |                                                                                     |
|                          | Recommended when the list response contains all values for the entity, or where     |
|                          | only the key settings must be updated.                                              |
|                          |                                                                                     |
|                          | Removing individual GETs speeds up the sync, since Automate is not waiting for the  |
|                          | API responses when there are a many entities to update. This is useful if the list  |
|                          | and GET responses are required, or if you only need the summary data from the list  |
|                          | view.                                                                               |
|                          |                                                                                     |
|                          | This setting is disabled by default for syncs related to `device/spark/user` syncs  |
|                          | (`SyncSparkUsers` and `SyncSpark`).                                                 |
+==========================+=====================================================================================+

Synchronous and Asynchronous Data Sync

By default, a data sync is asynchronous; that is, other tasks can be carried out while the sync is in progress.

However, a data sync can be set to be synchronous so that a workflow step can, for example, wait for the sync process to complete.

Asynchronous imports initiated by a data sync are standalone transactions; that is, they aren't child transactions of the data sync execute transaction. Synchronous imports initiated by a data sync are children of the data sync execute transaction.

Key Settings for Data Sync

A number of key settings that are available for data sync:

• Model Type lists - define which entities to pull in a given sync (for example, only pull in device/cucm/User records from Cisco Unified CM).
• Model Instance filters - limit a sync to a subset of entities in a sync (for example, pull in users with a primary extension starting with 1). This setting requires a system level administrator to expose it on the GUI.
• Actions - select which actions (Add/Update/Delete) are active for a sync. Update tends to be the most effort to run, because for most systems this involves a GET API call for each record and comparing to our data. Add/Del can be determined from the initial list API calls. If you are really only need the Add and/or Del action, then disabling the Update action will likely save considerable time on the sync.
• Quick Import - use the list API responses to update the VOSS-4-UC cache and will not do individual GET calls for each entity for the update. This works well where the list response contains all the values for the entity or only key settings need to be updated. The removal of all the individual GETs means the sync occurs much faster, because VOSS-4-UC is not waiting for the API responses when there are a many entities to update. This is useful if the list and GET responses are needed or if you only need the summary data from the list view.

Data Sync Types

Full HTML Help

VOSS Automate provides the following data sync types:

Generally, for all sync types, VOSS Automate builds up the lists of entities from both VOSS Automate and the device, and compares them, using the key for the device entity. The key is typically the unique identifier (ID) for the record in the device we're syncing with. For example, for Unified CM, the ID is the pkid, which is the internal Unified CM database ID.

For subscribers, a sync builds up the list of device/cucm/Users in VOSS Automate and then requests from the Unified CM the lists of users it currently has for the comparison. Differences in the lists are handled according to each sync type.

Related Topics

Data Sync Overview in the Core Feature Guide

Change Notification Feature Overview in the Core Feature Guide

Pull from Device

For sync type Pull from Device, the VOSS Automate resource is updated where the same key is present in both lists. In this case, the device data is the master and the VOSS Automate system model data is updated with the device data.

For example, let's say new data is added to the Unified CM, so that the VOSS Automate system data state for a Unified CM device/cucm/User does not show instances that are shown on the Unified CM.

In this case, a pull data sync synchronizes the system data with the Unified CM data. For example, a user's Department may be updated on the Unified CM, but the update only shows on the system after a Pull from Device sync. If a user resource is created in Unified CM but not in VOSS Automate, this adds the device/cucm/User instance into VOSS Automate at the level the pull sync was run from, for example, at the customer level.

When deleting a VOSS Automate resource from the device, so that the key is in the VOSS Automate list but not in the device list, a pull sync removes the resource in VOSS Automate. For example, if the resource is a user in VOSS Automate but not in Unified CM, the pull sync removes the device/cucm/User record in VOSS Automate.

To restrict the number of records removed in VOSS Automate, ensure you have the following named macro at the hierarchy where the sync takes place:

PULL_SYNC_DELETE_THRESHOLD_<device_type>

For details, see Pull Sync Delete Threshold topic in the Advanced Configuration Guide.

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.

For Microsoft 365 syncs, a Max page size (default 1000) setting can be adjusted if the error "Template output exceeded memory limit" is shown.

For details, see the Configure Microsoft Tenant Connection Parameters topic in the Core Guide.

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.

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.

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}}

Full Sync

Full HTML Help

A full pull sync, when it runs, empties the changes from the data collection as they don't need to be processed by the Change Notification Sync. Use the disabled operations and the model type list of the full sync to filter the changes to remove. If a model instance filter is included, no changes are removed.

Synchronous and Asynchronous Data Sync

A Data Sync is by default set to be asynchronous, in other words other tasks can be carried out while the sync is in progress. However, it can be set to be synchronous so that a workflow step can for example wait for the sync process to complete.

Asynchronous imports initiated by a Data Sync are standalone transactions, in other words they aren't child transactions of the Data Sync execute transaction. Synchronous imports initiated by a Data Sync are children of the Data Sync execute transaction.

Enable a Scheduled Data Sync

Full HTML Help

This procedure enables the scheduled data sync so that it executes regularly.

Enable the scheduled data sync

1. Log in as provider administrator.

2. Go to (default menus) Administration Tools > Scheduling.

3. On the Scheduling page, choose the schedule instance that matches this naming convention:

   HcsSync-<ip_address>-<device_name>-SCHED. For example:

   HcsSync-192.0.2.24-CUCM01-SCHED

4. Select the Active check box.

5. Select the Multiple Executions tab, and update the interval, as required.

6. Click Save.

   The full data sync executes immediately, and executes again according to the schedule.

Manually Run the Default Data Sync

Full HTML Help

You can always manually run the default data sync when there have been updates to Cisco Unified Communications Manager (CUCM) or Cisco Unity Connection (CUC) devices that need to be synced into VOSS Automate.

Perform these steps:

1. Log in as provider or reseller administrator.
2. Go to (default menus) Apps Management > Advanced > Perform Publisher Actions.
3. From the Action drop-down, choose Import.
4. From the App Type drop-down, choose CUCM Device or CUC Device.
5. From the Clusters Available box, choose the device, move it to the Selected box, and click Save.

Controlling a Data Sync with a Model Type List

Full HTML Help

Using a Model Type List (MTL), you can control the types of data that are synced into VOSS Automate from devices from vendors, such as:

• Cisco (Unified CM, Unity Connection)
• Microsoft
• Pexip
• Webex

and so on.

Controlling the types of data that are synced can greatly improve sync performance. The MTL is a list of device models associated with the device type, for example, Phone and Line device models that are associated with the Unified CM device.

These are the possible types of Model Type Lists:

• Include Selected Model Types - This list represents the device models to explicitly include in the data sync.
• Exclude Selected Model Types - This list represents the device models to explicitly exclude from the data sync.
• Ordered List - This list represents the device models to explicitly include in the data sync in the order they must be synced.

A data sync created with an empty Model Type List attribute results in the subsequent import(s) synchronizing all device models for the corresponding device.

Here is an example of an include MTL:

A data sync using this MTL will sync all Media Resource Group, Media Resource Lists, Music on Hold servers and audio sources, and Media Termination Points. No other data will be synced from Unified CM.

It is recommended to define MTLs for sets of data that are being modified on the device directly. An example is Unified CM because this is where the bulk of the configuration data for each customer resides.

By defining MTLs that target specific data sets rather than doing a full sync, the performance of VOSS Automate can be maintained with better response times and quicker transaction execution.

Data sync overhead can be further reduced if you want to sync only new and deleted instances of the device model and not updates to existing instances. This can be done by unchecking the Refresh Existing (Changed) Data check box on the Data Sync configuration page. This check box controls whether existing device model instances are updated in VOSS Automate in addition to importing new instances and removing deleted instances. If checked, all device model instances must be synced and examined. If unchecked, only new and deleted instances need to be imported and the data sync will run considerably faster.

Perform Publisher Actions

You can always manually run the default data sync when there have been updates to Cisco Unified Communications Manager or Cisco Unity Connection devices that need to be synced into VOSS-4-UC.

Procedure

1. Log in as provider or reseller administrator.
2. Choose Device Management > Advanced > Perform Publisher Actions.
3. From the Action drop-down, choose Import.
4. From the App Type drop-down, choose CUCM Device or CUC Device.
5. From the Available Clusters list, choose the device and click Select.
6. Click Save.

Create a Custom Data Sync

Full HTML Help

Create a custom data sync to use a targeted Model Type List.

Perform these steps:

1. Log in as provider admin or higher.

2. Choose Administration Tools > Data Sync.

3. Click Add.

4. Enter the name of the Data Sync in the Name field.

   It is recommend to use a naming convention that makes it easy to identify the data syncs in the list view, such as C1Pull-CUCM01-DS where C1 is the customer name, Pull is the data sync type, CUCM01 is the name of the Cisco Unified Communications Manager, and DS stands for Data Sync. You could also include the type of data included in the sync, such as C1Pull-CUCM01-MediaResources-DS.

5. From the Device Type drop-down, choose the Device Type you are syncing from.

6. From the Sync Type drop-down, choose Pull from Device.

7. From the Dependency Resolution drop-down, choose Default.

8. Select the Execute Asynchronously and Refresh Existing (Changed) Data check boxes.

   Execute Asynchronously means that the sync request will return a reply before its complete when executed from the API. Refresh Existing (Changed) Data means that all instances of the device models specified in the Model Type List will be updated.

9. Select the Force Refresh of Data check box if a data update is required regardless of whether data has changed on the device. This option would for example be used if it is required that update workflows be run upon a data sync.

10. From the Model Type List drop-down, choose the targeted Model Type List you defined earlier.

11. Leave Synchronization Order and Model Instance Filter blank.

12. Click + next to Device Filters to add an entry to the list.

    1. From the Attribute Name drop-down, choose host.
    2. From the Condition drop-down, choose Equals.
    3. From the Value drop-down, choose the hostname/IP address of the device.

    Note

    Workflows can be added to, and executed by a custom data sync to perform specific data sync operations.

13. In the Workflows section, include workflows in the custom data sync if you want to perform specific data sync operations, otherwise leave the Workflows section empty. For example, if you want to move remote destinations from the Customer hierarchy level to the Site level, choose the RD_Overbuild_PWF_wrapper workflow from the Workflow drop-down.

    If the Synchronous check box is enabled, the workflows will execute in sync with Data Sync transaction, so that the parent pre- and post workflow steps are honoured. If disabled, the workflows will not be child transactions of the Data Sync execute transaction.

14. From the Transaction Log Level drop-down, choose the log level for the data sync. For a description of the list of log levels, see Transaction Log Levels. The default log level is Warning.

    You can for example reduce the log level for PULL device syncs in order to reduce the size of transaction logs. This is useful where large numbers of transactions are archived regularly.

15. Click Save.

Next Steps

To run the custom data sync, click the data sync from the Data Sync list and click Execute.

CUCM Change Notification Alerts

Full HTML Help

Overview

The Cisco Unified Communications Manager (CUCM) change notification (CNF) feature is enabled to display alerts. There is no need to configure CNF alerts manually in Automate - admin users receive alerts when the collector process is in an error state.

Administrators can view and delete alerts at the hierarchy they log in at, and at lower hierarchies. For example, Provider, Reseller, and Customer administrators can view alerts raised at the Customer level (sys.hcs.provider.reseller.customer), but a Site admin cannot view such alerts.

When a CNF alert is raised, you're notified of the alert via the toolbar Messages icon in the Admin Portal. Click the Messages or Notifications toolbar button to view the alerts, or go to (default menus) Administration Tools > Alerts.

Properties of CNF Alerts

Change notification (CNF) alerts have the following properties:

CNF Error Scenarios

VOSS Automate displays change notification (CNF) alerts for the following error scenarios:

• Warning:

  45000: Unprocessed changes at 75% of limit for device {}. Please configure and run the necessary data syncs.

• Error:

  • 40000: Device change notifications are not supported for device {}.
  • 40001: Device change notification data for device {} has been lost. Tracking data has been repaired and collector process will continue. Some changes may have been lost, please run a full sync on the device.
  • 40002: Device change notification tracking data for device {} has become corrupted. Tracking data has been repaired and collector process will continue. Some changes may have been lost, please run a full sync on the device.
  • 40003: Device change notification tracking DB write for device {} failed. The collector process will continue to attempt DB writes. Please investigate the database write failure.
  • 40004: Device change notification data DB write for device {} failed. The collector process will continue to attempt DB writes. Please investigate the database write failure.
  • 40005: Unable to repair device change notification tracking data for device {}.
  • 40006: Too many unprocessed changes recorded for device {}. No new changes will be recorded until at least {} changes are processed. Please configure and run the necessary data syncs.
  • 40008: Could not update pending changes data for device {}. {}.

The administrator reads, inspects, acts on (for example, run a full sync on the device), and then manages alerts of the CNF collection service. The administrator can delete the alert from the list only when the issue that raised the alert has been resolved.

Create a Targeted Model Type List

If you manage data on Cisco Unified Communications Manager (Unified CM) or Cisco Unity Connection directly on a regular basis, perhaps for configuration that is not orchestrated from VOSS-4-UC, such as media resources, it is recommended to create a Model Type List and Data Sync specifically targeting the data items you are managing. This ensures each data sync is highly optimized for the data being changed on Unified CM directly and minimizing the load on VOSS-4-UC. To create a targeted Model Type List:

Procedure

1. Log in as Provider level admin or higher.

2. Select Administration Tools > Model Type List.

3. Click Add.

4. Specify the name of the Model Type List.

   It is recommended to use a naming convention that makes it easy to identity the MTL in a list view, such as Unified CM Media Resources.

5. From the List Type drop-down, choose the list type:

   • Choose Include Selected Model Types if the list of device models you want to sync is relatively short.
   • Choose Exclude Selected Model Types if the list of device models you want to sync is relatively long. Exclude device models that tend to have lots of instances, like users, phones, and lines.
   • Choose Ordered List if the list of device models you want to sync is relatively short and the order in which they are synced matters.

6. Add Model Types to the list of device models that are to be included or excluded according to the List Type selected.

   See "View List of Device Models" below for information on how to see a list of available Unified CM and Cisco Unity Connection device models.

7. Click Save.

Data Sync Allow list and Deny list

Full HTML Help

Administrators with permissions to access the Global instance of the settings in the data/Settings model (sysadmin), can create lists of device attributes affected by data sync under the Data Sync Workflow Execution Control section:

• Allowlist Attributes

  When this list contains a field, then only a change in that field and not any other field will trigger data sync workflows, regardless of the list of the Denylist Attributes. In other words, this list takes precedence over the existing list of Denylist Attributes.

  Refer to the allow lists below.

• Denylist Attributes

  Items in this list will not trigger any update workflows that may have been defined to execute during the data sync. These attributes are therefore excluded from data sync considerations.

  The reason for this list of attributes is that while data sync operations can have a performance impact, some data sync attribute changes do not require data sync workflows to be carried out.

  Note however that the local device cache will still be updated with the updated attribute data. No update workflows will be run, though. The transaction logs will indicate the updated device cache, but the transactions for these attributes instances will show as:

  "Device changes on denylisted attributes only. Updating cache, skipping workflows."

  Note

  After release 20.1.1 or applying patch EKB-4362-19.2.1_patch, the previously denylisted LDAP attributes are no longer imported during LDAP synchronization:

  For device/ldap/user:

  • logonCount
  • adminCount
  • lastLogonTimestamp
  • whenCreated
  • uSNCreated
  • badPasswordTime
  • pwdLastSet
  • lastLogon
  • whenChanged
  • badPwdCount
  • accountExpires
  • uSNChanged
  • lastLogofflastLogoff

  Refer to the deny lists below.

From release 21.4-PB2, the following allowlist model attributes have been added:

Allowlist ``device/msteamsonline/CsOnlineUser``

• For device/msteamsonline/CsOnlineUser:
  • UserPrincipalName
  • DisplayName
  • Department
  • City
  • FeatureType
  • EnterpriseVoiceEnabled
  • LineURI

Allowlist ``device/msgraph/MsolUser``

• For device/msgraph/MsolUser:
  • UserPrincipalName
  • FirstName
  • LastName
  • Department
  • Office
  • City

A number of denylist attributes have been added by default:

Denylist ``device/ldap/user``

• For device/ldap/user:
  • logonCount
  • adminCount
  • lastLogonTimestamp
  • whenCreated
  • uSNCreated
  • badPasswordTime
  • pwdLastSet
  • lastLogon
  • whenChanged
  • badPwdCount
  • accountExpires
  • uSNChanged
  • lastLogoff
  • userPassword

Denylist ``device/cucm/User``

• For device/cucm/User:
  • status
  • primaryDevice
  • attendeesAccessCode
  • displayName
  • enableUserToHostConferenceNow
  • pinCredentials
  • passwordCredentials
  • associatedRemoteDestinationProfiles

Denylist ``device/cucm/Phone``

• For device/cucm/Phone:
  • keyOrder
  • elinGroup
  • ecKeySize

Denylist ``device/ldap/userProxy``

• For device/ldap/userProxy:
  • accountExpires
  • adminCount
  • badPasswordTime
  • badPwdCount
  • bind_dn
  • dSCorePropagationData
  • distinguishedName
  • employeeID
  • homeMDB
  • instanceType
  • lastLogon
  • lastLogoff
  • lastLogonTimestamp
  • legacyExchangeDN
  • logonCount
  • mDBUseDefaults
  • mailNickname
  • manager
  • msExchArchiveQuota
  • msExchArchiveWarnQuota
  • msExchBlockedSendersHash
  • msExchCalendarLoggingQuota
  • msExchDumpsterQuota
  • msExchDumpsterWarningQuota
  • msExchELCMailboxFlags
  • msExchHomeServerName
  • msExchMailboxGuid
  • msExchMailboxSecurityDescriptor
  • msExchMobileAllowedDeviceIDs
  • msExchMobileBlockedDeviceIDs
  • msExchMobileMailboxFlags
  • msExchPoliciesIncluded
  • msExchRBACPolicyLink
  • msExchRecipientDisplayType
  • msExchRecipientTypeDetails
  • msExchSafeSendersHash
  • msExchTextMessagingState
  • msExchUMDtmfMap
  • msExchUserAccountControl
  • msExchVersion
  • msExchWhenMailboxCreated
  • objectCategory
  • objectClass
  • objectGUID
  • objectSid
  • physicalDeliveryOfficeName
  • primaryGroupID
  • protocolSettings
  • proxyAddresses
  • pwdLastSet
  • sAMAccountType
  • showInAddressBook
  • textEncodedORAddress
  • uSNChanged
  • uSNCreated
  • userAccountControl
  • whenChanged
  • whenCreated
  • userPassword

Related Topics

Allowlists and Denylists in the Core Feature Guide.

Microsoft Sync Overview in the Best Practices Guide.

View List of Device Models

Use this procedure to see the device models available to use in Model Type Lists for custom data syncs from Cisco Unified Communications Manager or Cisco Unity Connection.

Procedure

1. Log in as hcsadmin.
2. Click the ? on the menu bar to open Online Help.
3. Select Model API.
4. Select Device/Cuc or Device/Cucm. All the applicable device models are listed for the selected device.

What to Do Next

When including the device model in a Model Type List, use the format: device/<device_type>/<device_model>. For example, device/cucm/BillingServer.

Create a Custom Data Sync

Create a custom data sync to use a targeted Model Type List.

Procedure

1. Log in as hcsadmin.

2. Choose Administration Tools > Data Sync.

3. Click Add.

4. Enter the name of the Data Sync in the Name field.

   It is recommend to use a naming convention that makes it easy to identify the data syncs in the list view, such as C1Pull-CUCM01-DS where C1 is the customer name, Pull is the data sync type, CUCM01 is the name of the Cisco Unified Communications Manager, and DS stands for Data Sync. You could also include the type of data included in the sync, such as C1Pull-CUCM01-MediaResources-DS.

5. From the Device Type drop-down, choose the Device Type you are syncing from.

6. From the Sync Type drop-down, choose Pull from Device.

7. From the Dependency Resolution drop-down, choose Default.

8. Select the Execute Asynchronously and Refresh Existing (Changed) Data check boxes.

   Execute Asynchronously means that the sync request will return a reply before its complete when executed from the API. Refresh Existing (Changed) Data means that all instances of the device models specified in the Model Type List will be updated.

9. Select the Force Refresh of Data check box if a data update is required regardless of whether data has changed on the device. This option would for example be used if it is required that update workflows be run upon a data sync.

10. From the Model Type List drop-down, choose the targeted Model Type List you defined earlier.

11. Leave Synchronization Order and Model Instance Filter blank.

12. Click + next to Device Filters to add an entry to the list.

    1. From the Attribute Name drop-down, choose host.
    2. From the Condition drop-down, choose Equals.
    3. From the Value drop-down, choose the hostname/IP address of the device.

    Note

    Workflows can be added to, and executed by a custom data sync to perform specific data sync operations.

13. In the Workflows section, include workflows in the custom data sync if you want to perform specific data sync operations, otherwise leave the Workflows section empty. For example, if you want to move remote destinations from the Customer hierarchy level to the Site level, choose the RD_Overbuild_PWF_wrapper workflow from the Workflow drop-down.

14. Click Save.

What to Do Next

To run the custom data sync, click the data sync from the Data Sync list and click Execute.

Alert Field Descriptions

Full HTML Help

Data Sync Blacklisted Attributes

Administrators with permissions to access the Global instance of the settings in the data/Settings model, can create a list of device attributes that will not trigger any update workflows that may have been defined to execute during the data sync. These attributes are here called "blacklisted" attributes.

The reason for blacklisted attributes is that while data sync operations can have a performance impact, some data sync attribute changes do not require data sync workflows to be carried out.

A number of blacklisted attributes have been added by default:

• For device/cucm/User:
  • status
  • primaryDevice
  • attendeesAccessCode
  • displayName
  • enableUserToHostConferenceNow
  • pinCredentials
  • passwordCredentials
• For device/cucm/Phone:
  • keyOrder
  • elinGroup
  • ecKeySize

Note however that the local device cache will still be updated with the updated attribute data. No update workflows will be run, though. The transaction logs will indicate the updated device cache, but the transactions for blacklisted attributes instances will show as:

"Device changes on blacklisted attributes only. Updating cache, skipping workflows."

Provides data synchronization capabilities with devices (eg. CUCM, CUC, LDAP)

Model Details: data/DataSync