[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:

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:

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:

Settings Description
Model Type lists

Define the entities to pull in a given sync. For example:

  • Only pull in device/cucm/User records from CUCM.
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.

A system-level administrator will need to expose this setting in the Admin Portal.

Disabled Operations

Choose which operations are enabled for a sync (Add/Update/Remove).

  • Update requires more effort to run because this typically involves a GET API call for each record, which must then be compared to Automate data.
  • Add/Remove can be determined from the initial list API calls.

To save time on the sync, you may wish to disable Update if you only require Add/Delete.

Important

Remove is disabled by default if you've selected a model instance filter for the sync. You'll need to enable Remove if you intend for the sync to purge (remove) cache records that are excluded in the model instance filter.

If you're upgrading to 21.4-PB4 from an earlier version of Automate, a migration script disables Remove for any syncs that have a model instance filter applied. This is to prevent the sync from unexpectedly removing a large number of records after the upgrade.

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).

Note

Quick Imports can improve sync performance but must be used with extreme caution to avoid unintended changes. Typically, Quick Import is recommended only for Microsoft-related data syncs (MSOperatorConnect, MSGraph, MSTeamsOnline, MSExchangeOnline) and for Webex App/Teams-related syncs that do not include the Webex App/Teams user (device/Spark/user).

The default Full Sync instance provided for CUC also does not have Quick Import enabled.

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.

Data Sync

Data of the various devices can be updated on VOSS-4-UC, or also directly on the device. Therefore, it is necessary to periodically synchronize cached VOSS-4-UC data with the data on devices.

Consider an example: when an instance of a Unified CM is added to the system, its data is imported and cached. However, when instances are added, updated or removed from the Unified CM, the cached data in VOSS-4-UC becomes out of sync with data on the device.

If data is deleted from Unified CM before it is deleted from VOSS-4-UC, the error "The specified resource could not be found" is displayed. This means the resource is out of sync and VOSS-4-UC may need to re-sync with Unified CM to delete or update it.

The Data Sync feature provides a means to dynamically synchronize cached VOSS-4-UC data with data on devices. The data sync instance is associated with the connection parameters of a device type in VOSS-4-UC.

Supported devices include:

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.

Key Settings for Data Sync

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

Note

The Quick Import option is not recommended in most cases, but should only be used for the sync of device/cuc/ImportUser. However, initially there is an exception to the performance improvement of a quick import sync with device/cuc/User:

When quick import is turned on on a sync which has previously run without it, dependent, non-Import User model types use the LIST response data to compare with the resource data which was originally saved using the GET response data. The data sync detects a change and a resource save is initiated for each instance. In the case of device/cuc/User, this means that dependent import API calls are made, which result in a long sync time.

Once it has completed, however, subsequent quick import syncs should show an improvement over non-quick import syncs, but when changing back to a non-quick import sync, the same effect would likely be observed.

Data Sync Types

Full HTML Help

VOSS Automate provides the following data sync types:

Data sync type Description
Pull from Device

Available to all device types.

  • Pull all data from the device
  • Pull only the schema from the device (used for LDAP)
  • Pull data from the Change Notification Feature local data collection
Purge Local Resources

Available to all device types.

  • Purge data from the cache
Push to Device

Available only to Cisco Unified CM devices

  • Push data in the cache to the device
Change Notification Sync Available only to Cisco Unified CM devices

Note

A quick import option is available to fetch only summary data that is contained in a list operation response and not the data for all instances/fields. See Data Sync Overview in the Core Guide for details.

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.

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.

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:

Data Sync Types

Data synchronization is available with the following functionality:

A quick import option is available to fetch only summary data that is contained in a list operation response and not the data for all instances/fields.

Details of the sync types that are available, are listed below:

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 (MTL) of the full sync to filter the changes to remove. If a model instance filter is included, no changes are removed.

It is recommended to use the CUCXN Exclude ImportUser MTL on Cisco Unity Connection Data Syncs in order to avoid unneeded data and slowing the sync time.

Device and Instance Data Sync Filters and Lists

The Data Sync can include only specific device objects. This allows the sync to be focused on the items where the work policy or process is to manage the objects directly in the UC applications.

A filter can be set up to indicate which instances of device objects should be synchronized (for example certain phones where the protocol is in a list of protocols). The filter attribute operations include Equals, Not Equals, Greater Than, Less than, In, Not in.

Synchronization can be focused on specific devices by filtering on various attributes, for example all devices with a certain version or with a description containing a certain string, and so on.

Particular models to be synchronized can be configured in a Model Type List instance, for example a list called "CUCM Users & Phones" may only include device/cucm/phone and device/cucm/user from device/cucm.

Any data/DataSync instances that are created with an empty Model Type List attribute will result in the subsequent import(s) synchronizing all device models for the corresponding devices.

A Model Type List instance with selected List Type as Ordered List is created to order the items in a created Model Type List if ordering is required during the synchronization.

Specific instances of Model types that belong to a Device Type can be included or excluded from the synchronization using a Model Instance Filter model that contains a specification of particular Device Filters with values to test against attributes.

For example, if the Model Type was selected to be data/Countries and the attribute is country_name, then a test that matches "In" with a list containing say Spain, Italy and Germany will only apply data synchronization against these particular instances. Where the attribute is a numeric value, the test can match by comparison (for example greater than, less than).

The synchronization order of models can be specified if it is necessary for models to be synchronized in a particular order, for example if dependencies exist in the data of the models.

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.

Note

Setting up a CUCM or CUC device in VOSS Automate:

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.

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 will be standalone transactions, in other words they will not be child transactions of the Data Sync execute transaction. Synchronous imports initiated by a Data Sync will be children of the Data Sync execute transaction.

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.

Note

Manually running the change notification sync is not supported.

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.

Data Sync Workflows

As part of a Data Sync, workflows can be set up to take place either before or after synchronization. The workflows will be triggered to run following a specified type of operation on a selected model type. In this way, the results of a data sync can add to the transaction log. The workflow can also for example trigger an SMTP event so that a message is sent following the type of operation on the model, for example when a Unified CM user is added.

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:

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:

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.

Note

Some Unified CM device models to avoid unless needed are Users, Phones, and Lines, as there may be large numbers of these in the Unified CM and result in a lengthy data sync operation.

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.

Note

Manual run of the change notification sync is not supported.

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.

Data Sync Schedules

A Data Sync instance can also be selected to be scheduled, in other words a Schedule can be created where the Action is to execute a DataSync.

As with any schedule, the action can be once-off or it can recur at a specified date and time. Care should be taken when data sync transactions are scheduled - this should prefereably be outside of peak times. The size and scope of the transactions that run determine the length of the time that they need to run. This also impacts on the schedule start time. The number of clusters on the system and their size need to be considered as part of a Data Sync approach.

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.

Data Sync Errors

Only one data sync transaction at a time can be run on the same device. Attempting to run a data sync transaction on a device while another one is already running on the same device will result in one of the following error messages:

The transaction ID referred to is the same as the one displayed in the transaction log view page.

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:

ID A generated unique identifier of the target device of the collector. For CUCM, the ID displays the host name, port, and hierarchy.
Code An error or warning code associated with the alert.
Category The alert category - Device Change Notification Collector
Severity

VOSS Automate displays severity codes and messages as follows (“{}” indicate device or number placeholders in the messages).

Each alert has some properties, for example, severity (Error, Warning or Info), the number of times that the same alert has been raised, and the time stamp of the last alert instance.

Message Displays error message description and the statement to fix the error.
Count Displays the number of times the alert has occurred for a specific device.
Latest Alert The last time this alert occurred.

Note

Administrators can filter alerts by any of the alert fields.

CNF Error Scenarios

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

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.

Note

If the Administrators forget to remove the CNF alert after resolving it, the alert will still be shown when they log in to VOSS Automate. We strongly recommend removing the alert after resolving it.

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:

  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 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 of the device/ldap/user model have been added to these settings by default:

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."

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:

From release 24.1, the following allowlist model attributes have been added and the previous denylist has been removed:

Allowlist ``device/cucm/Phone``

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

Allowlist ``device/msteamsonline/CsOnlineUser``

Allowlist ``device/msgraph/MsolUser``

A number of denylist attributes have been added by default:

Denylist ``device/ldap/user``

Denylist ``device/cucm/User``

Denylist ``device/ldap/userProxy``

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 Data Sync

  1. Log in as hcsadmin.

  2. Select Administration Tools > Data Sync.

  3. Click Add.

  4. Specify the name of the Data Sync.

    It is recommend to use a naming convention that is easy to identify in the list view, for example a name that combines the device, type of data, sync type and customer name.

  5. Select a Sync Type:

    Refer to the general topics on data sync types for more details.

  6. For Dependency Resolution, it is recommended to select Default. The Best Effort option indicates that failed imports are continuously synchronized until there are no errors.

  7. Select the options to Check Execute Asynchronously and Refresh Existing Data as required.

    Execute Asynchronously means that the sync request will return a response before its complete when executed from the API. Refresh Existing Data means that all instances of the device models specified in the Model Type List will be updated. Refer to the general topics on data sync for more details.

  8. Select the required targeted Model Type List - refer to the topics on Model Type Lists for more details.

  9. Select a Synchronization Order model type list if a sequence needs to apply to the target Model Type List. The ordered list should therefore be related to the selected Model Type List. Refer to the topics on data sync lists and filters for more details.

  10. Leave the Model Instance Filter blank.

  11. Select the Device Type you are syncing from. Refer to the general topic on data sync for more details.

  12. Click + on Device Filters to add an entry to the list. Typically, the following condition is specified:

    1. For Attribute Name, select host.
    2. For Condition, select Equals.
    3. For Value, select the hostname or IP address of the device.
  13. Click + on Workflows to add an entry to the list, if a workflow should be run at any stage of the sync for a particular operation on a model type. Refer to the topics on data sync workflows for more details.

  14. Click Save.

If required, this data sync instance can be scheduled by administrators with the necessary privileges.

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

Field Description
ID * The unique ID of the alert.
Code * The code of the alert.
Category * The category of the alert.
Severity The severity of the alert.
Message The message describing the alert.
Count The number of times this alert has occurred.
Latest Alert The last time this alert occurred.

Data Sync and LDAP Referrals

When performing a data sync of an LDAP server and the OU that is synchronized contains any LDAP referrals (continuation references), then VOSS-4-UC skips the referrals.

A warning message is added to the transaction log and will be visible if the log level is set to "Warning" or "Info". In particular, the data sync transaction log, the warning message has:

Data Sync of Product Specific Data

If changes to product specific information are made on Unified CM, such as vendor configuration information on device/cucm/PhoneType and device/cucm/GatewayType, then a data sync that includes these model types should be created and run before the changes will be available on VOSS-4-UC.

The product specific information for these models are:

Also refer to the topic on Phones in the End-to-End Guide.

Enable the Refresh Existing Data check box to re-create the model instance for all products and in the case of PhoneType, include any new phone button templates in the model for the products to which may have been added on Unified CM.

For Phone Button Templates, the steps to follow would be:

  1. Configure the phone button template on Unified CM directly.
  2. Import CallManager to make the newly added phone button template available.
  3. Create and execute a data sync for device/cucm/PhoneType.
  4. Use the newly added phone button template to add a new phone on VOSS-4-UC.

However, note that when Configuration Templates are used with Phones that have added product specific information, such as models of for example device/cucm/PhoneType, these names need to be typed into the Product field of the Phone Configuration Template.

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:

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

Title Description Details
Name * The name that is given to the Data Sync instance.
  • Field Name: name
  • Type: String
Description A description for the Data Sync instance.
  • Field Name: description
  • Type: String
Device Type * The type of devices to be synchronized. Choices are based on connection parameter data models of the devices supported by the current system.
  • Field Name: device_type
  • Type: String
  • Choices: ["Active Directory", "Active Directory Hybrid", "Assurance Arbitrator", "AudioCodes", "AzureADOnline", "BroadsoftOCIP", "Call Manager AXL Generic Driver", "Call Manager Control Center Services", "Cisco HCM-F", "Cisco Unified CM", "Cisco Unified Contact Center Express", "Cisco Unity Connection", "Cisco WebEx", "Exchange", "Exchange Hybrid", "Exchange Online", "IMP GUI", "LDAP", "MSExchangeOnline", "MSGraph", "MSOperatorConnect", "MSTeamsOnline", "Microsoft Online", "OracleECB", "OracleSBC", "PRSCallControl", "Pexip Infinity Conferencing Platform", "PowerShell", "Roomos", "Service Now", "SkypeForBusiness", "SkypeForBusiness Hybrid", "SkypeForBusiness Online", "Spark", "Unity Connection GUI", "Zoom", "sfb2015"]
Sync Type The selected Sync Type. The Type can be Pull from Device, Push to Device, Merge with Device, or Purge Local. For Push, the system data state is the master state and the model types of the connection parameter are synchronized with it. For Pull, the model type states of the connection parameter is the master and the system model data is synchronized with these. For Merge, data synchronization takes place in both directions without overwrite of either data. For Purge Local, resources all resources that exist in the system will be deleted, although the entities in the device are not deleted - this is useful when cleaning up the system.
  • Field Name: sync_type
  • Type: String
  • Choices: ["Pull from Device", "Push to Device", "Merge with Device", "Purge Local Resources", "Change Notification Sync"]
Dependency Resolution The strategy for handling failures due to missing dependencies. Only 'Best Effort' resolution is supported. 'Best Effort' resolution attempts to brute force the synchronization as much as possible by re-iterating over failed imports until there are no errors.
  • Field Name: dependency_resolution
  • Type: String
  • Choices: ["Best Effort", "Default"]
Quick Import (Warning: Summary Data Only) Enable with caution: Indicates whether import operations will fetch full data for all instances or just use the summary data. Only use with Model types where all of the required data is in the summary data eg: device/cuc/ImportUser model.
  • Field Name: quick_import
  • Type: Boolean
Import Schema Only Indicates whether import operations will fetch schema only and no data.
  • Field Name: schema_only
  • Type: Boolean
Import Data Only Indicates whether import operations will fetch data only and no schema.
  • Field Name: no_schema
  • Type: Boolean
Execute Asynchronously Indicates whether the Data Sync must be executed Asynchronously or Synchronously. Default: True
  • Field Name: asynchronous
  • Type: Boolean
  • Default: True
Refresh Existing (Changed) Data Indicates whether the Data Sync refreshes existing data that has changed on the device.
  • Field Name: refresh_existing_data
  • Type: Boolean
Force Refresh Of Data Indicates whether a update action is executed regardless of whether the device has changed or not
  • Field Name: force_update_flag
  • Type: Boolean
Number of Changes To Process Specifies how many changes to process during a device notification.
  • Field Name: num_changes_to_process
  • Type: Integer
Disabled Operations Indicates which operations should be disabled for this Data Sync.
  • Field Name: disabled_operations
  • Type: Object
Add Disable the "add" operation.
  • Field Name: disabled_operations.add
  • Type: Boolean
Update Disable the "update" operation.
  • Field Name: disabled_operations.update
  • Type: Boolean
Remove Disable the "remove" operation.
  • Field Name: disabled_operations.remove
  • Type: Boolean
Model Type List The selected 'exclusion/inclusion' model type list that was created as a model instance of the Model Type List. See: Model Type List.
  • Field Name: model_type_list
  • Type: String
  • Target: data/ModelTypeList
  • Target attr: name
  • Format: uri
Synchronization Order The selected 'ordered' model type list that was created as a model instance of the Model Type List. This list dictates the order in which models will be synchronized. See: Model Type List.
  • Field Name: sync_order
  • Type: String
  • Target: data/ModelTypeList
  • Target attr: name
  • Format: uri
Model Instance Filter An instance of Model Instance Filter data model. This instance defines the rules for filtering out the models to be synchronized. See: Model Instance Filter.
  • Field Name: model_instance_filter
  • Type: String
  • Target: data/ModelInstanceFilter
  • Target attr: name
  • Format: uri
Device Filters A refinement on devices that the data sync applies to. These filters are optional. If they are not specified, data sync will be applied to all instances of the device type supported by this Data Sync instance. If specified, only the devices that match the given filters will be synchronized.
  • Field Name: device_filters.[n]
  • Type: Array
Attribute Name * The model attribute name to which the condition applies.
  • Field Name: device_filters.[n].attr_name
  • Type: String
  • Choices: [""]
Condition * If the Condition is Equals or Not Equals, then the Value to test the condition against. If the Condition is In or Not In, then Value is a list of values to test against.
  • Field Name: device_filters.[n].condition
  • Type: String
  • Choices: ["Equals", "Not Equals", "In", "Not In"]
Value The selected Attribute Name is tested against the Value that can also be a list of values, such as a list of host names. The Condition tests against the Value or list of values.
  • Field Name: device_filters.[n].value
  • Type: String
  • Choices: [""]
Values If the Condition is In or Not In, then the Values list the items to test the condition against.
  • Field Name: value_list.[n]
  • Type: Array
Workflows A list of workflows that is to be executed as part of data sync actions eg. when a resource is added, modified, or deleted
  • Field Name: workflows.[n]
  • Type: Array
Model Type The model type for which the workflow is to be executed.
  • Field Name: workflows.[n].model_type
  • Type: String
  • Format: uri
Operation * The operation for which the workflow is to be executed.
  • Field Name: workflows.[n].operation
  • Type: String
  • Choices: ["Add", "Update", "Delete"]
Phase * The operation phase at which the workflow is to be executed eg. Pre-Execution (before the operation is performed) or Post-Execution (after the operation is performed)
  • Field Name: workflows.[n].phase
  • Type: String
  • Choices: ["Pre Execution", "Post Execution"]
Workflow * The workflow instance that will be executed.
  • Field Name: workflows.[n].workflow
  • Type: String
  • Target: data/ProvisioningWorkflow
  • Target attr: name
  • Format: uri
Synchronous If selected the workflow will be executed synchronously, otherwise asynchronously (default).
  • Field Name: workflows.[n].synchronous
  • Type: Boolean
Transaction Log Level The transaction log level to be used for this Data Sync and its immediate sub-transactions. Default is Warning when this field is not set. Default: 30
  • Field Name: transaction_log_level
  • Type: Integer
  • Default: 30
  • Choices: ["Use System Settings", "Debug", "Verbose", "Info", "Warning", "Error", "Disabled"]