This documentation supports the 11.1 version of BMC Discovery.

To view an earlier version of the product, select the version from the Product version menu.

CMDB synchronization

CMDB synchronization provides a configurable mechanism to keep data in the BMC Atrium CMDB (CMDB) synchronized with information discovered by BMC Discovery. You set up connections to CMDBs are individually, enabling you to configure specific filters and blackout windows for each. You can also enable or disable and pause or resume synchronization on individual connections, or globally.

In releases prior to 10.2, the CMDB had to be queried to determine which updates BMC Discovery should make when syncing, and this step represented a large proportion of the overall time taken. BMC Discovery now maintains an authoritative model of the dataset of each configured CMDB connection, in its datastore. When a CMDB sync connection is created, BMC Discovery creates a shadow copy of the data that the corresponding CMDB dataset should hold and sends that to the CMDB. When data is modified as the result of discoveries, deletions or manual syncs, these changes are updated in the shadow copy and propagated to the CMDB, without the need to first check the contents of the actual CMDB.

Occasionally the model stored in the CMDB dataset becomes out of step with the shadow copy for a CMDB connection and requires resynchronization. For example, if CMDB tools have been used to modify the dataset. In this case, when updates are written to non-existent nodes, instance errors are raised. When BMC Discovery registers these instance errors, a resynchronization is recommended. In other cases such as after upgrade from a 10.1 appliance or the creation of a new CMDB sync connection to a non-empty dataset, a resynchronization is mandatory, and CMDB sync is disabled until the resynchronization is complete.


Do not change the CMDB synchronization configuration at the same time as changing the cluster configuration.

  • Changing the CMDB sync configuration means, adding connections, removing connections, and starting or stopping a resync. 
  • Changing the cluster configuration means adding members, removing members, moving the coordinator, or changing fault tolerance.

Starting from Technology Knowledge Update 2014-Jul-1, the CMDB sync mappings have been enhanced with two new capabilities:

Support for HasImpact population

Relationships in Atrium CMDB can be marked as being “impactful”, by setting the HasImpact attribute to Yes and the ImpactDirection attribute to a suitable value. A new CMDB sync data model means that BMC Discovery can now set these impact attributes directly, rather than relying on Atrium CMDB’s impact normalization rules. To enable the new data model:

  1. In the Atrium Core Normalization application, use the Configuration Editor to disable the setting labelled Impact Normalization for the ADDM dataset
  2. When adding or editing a connection in BMC Discovery, ensure the Data Model setting labelled "CMDB 7.6.03 and later (with impact attributes)" is selected (this is the default).

Simple static application models

BMC Discovery allows you define dynamic automatically-updating application models, using Collaborative Application Mapping and related features. That leads to robust comprehensive application models, but it does require time to investigate the application and define a suitable set of patterns. In some circumstances it is useful simply to manually group some hosts or software instances together to create a “static” application model. Such models are of course not automatically updated, but they are extremely quick and easy to define.

To define a static application model, add Hosts, SoftwareInstances or LoadBalancerServices to a group in BMC Discovery, and give the group a name that starts with “StaticApp:”, in exactly that form. Do not use sub-groups. That causes the creation of a BMC_Application CI in Atrium CMDB, named after the group. For example, a group named “StaticApp: Example Application” results in a BMC_Application CI with name “Example Application”. As with all groups, the StaticApp group may contain any node kind, but only Host, SoftwareInstance and LoadBalancerService nodes will actually be related to the BMC_Application CI in the CMDB.

Data model mapping

The BMC Discovery data model (Discovery model) is different from the Common Data Model (CDM) used in the CMDB, so the synchronization mechanism is responsible for transforming the required information from one data model to the other. The Discovery model is known as the source model, and the CDM is referred to as the target model.

Both models are graph models, meaning that they represent data as nodes connected to each other with relationships. Synchronization operates on portions of the full graph known as subgraphs. A subgraph contains a root node (such as a host computer), plus all the related nodes that belong to it (such as interface information, software information, and so on), referred to as its components. Some nodes can be shared, meaning that they belong to more than one subgraph. For example, the node representing a subnet is shared by all the host computers on that subnet.

The mapping between the Discovery model and the CDM is defined in syncmapping definitions within TPL files.

The Default CDM Mapping provides a comprehensive mapping from the Discovery model to a best-practices CDM model. If you have added custom nodes to Discovery they are not exported automatically by the default CDM mapping, instead, you will have to create additional mapping definitions within TPL files.

Supported CMDB versions

At the time of its release, integration of the current version of BMC Discovery was supported with the following versions of BMC Atrium CMDB:

  • 9.1
  • 9.0
  • 8.1.02
  • 8.1.01
  • 8.1.00
  • 8.0.00
  • 7.6.04

For more information, check the BMC Solution and Product Availability and Compatibility utility (SPAC) (support login required).

Deprecated versions of CMDB synchronization

BMC Discovery version 8.1 introduced the first automatic integration using CMDB synchronization. At that time the previously used method (the Atrium CMDB adapter) was deprecated. In BMC Discovery 9.0, the Atrium CMDB adapter was removed.

Synchronization stages

Synchronization occurs in the following stages:

  1. root source node is chosen for synchronization. The root node kinds are Host, MFPart, NetworkDevice, Printer, SNMPManagedDevice, and Storage System corresponding to the main kinds of device that can be discovered. The list of possible root nodes is fixed and cannot be altered in the Syncmappings.
  2. The source subgraph is populated by retrieving all the relevant data from the Discovery datastore.
    • The ADDM filter sub page for a CMDB connection can be used to specify which source nodes will be synced.

  3. The source subgraph is transformed into a target subgraph, centered around a target root node.
    • The CMDB filter sub page for a CMDB connection can be used to specify which CIs will be synced, that correspond to the nodes allowed through by the ADDM filter.
  4. The target subgraph is compared with the corresponding subgraph stored in the Discovery datastore for the CMDB connection.
  5. The updates identified are made in batches to the CMDB. Once an update has been made to the CMDB (by creating, updating and (soft) deleting CIs and relationships), it is also made to the local shadow copy for the connection. The next batch is then processed in the same way until no more updates are required.


If any changes are made to the CDM (for example, adding attributes), you cannot synchronize to those attributes until the Tideway service has been restarted. After the tideway service starts, the CDM is read and all customized classes and attributes are available for CMDB synchronization.


Occasionally the model stored in the CMDB dataset becomes out of step with the shadow copy for a CMDB connection and require resynchronization. For example, if CMDB tools have been used to modify the dataset. In this case, when updates are written to non-existent nodes, instance errors are raised. When BMC Discovery registers these instance errors, a resynchronization is recommended. In other cases, such as after upgrading to version 10.2 or later, or the creation of a new CMDB sync connection to a non-empty dataset, a resynchronization is mandatory, and CMDB sync is disabled until the resynchronization is complete.

Resynchronization must assess the contents of the CMDB dataset against the authoritative version stored in the Discovery shadow copy for the CMDB connection and send the appropriate updates to the CMDB. The stages in a resynchronization are:

  1. Preparation – Prepare Resync performs the following actions, without changing any data in the CMDB:
    1. Reads identities of all CIs and relationships from the CMDB dataset.
    2. Transforms all BMC Discovery data into the local shadow copy.
    3. Compares the data read from the CMDB with the updated local shadow copy.
  2. Commit – Commit Resync performs the following actions in the CMDB:
    1. Creates CIs and relationships missing from the dataset.
    2. Marks deleted any CIs or relationships present in the dataset but not in the local shadow copy.
    3. Updates all CIs and relationships to ensure their attributes match those in the local shadow copy.

There are two types of resync:

  • Complete Resync – in which the Commit Phase runs to completion, and may take a long time.  
  • Incremental Resync – in which the Commit Phase is performed incrementally as root nodes are synchronized.

You can choose which type of resync to use on the Resync tab of the CMDB Sync page. You can also choose to prepare the resync only, in which case the resync is prepared on the BMC Discovery side; no updates are made to the CMDB. Using prepare only you can examine the changes that CMDB Sync will make to the CMDB before performing the commit.

Where a resynchronization is interrupted, you can resume resynchronization from the point at which it was interrupted.

In the following situations a resynchronization is mandatory, CMDB sync is disabled until the resynchronization is complete.

Upgrade from 10.1

When you upgrade a version 10.1 appliance which is configured for CMDB sync, its configuration is modified to the new format, but the shadow copy is not populated. However, the CMDB dataset corresponding to the connection may still be populated from a sync performed before the upgrade. If a sync were attempted immediately, BMC Discovery would not be aware of the existing contents of the dataset, and the result could be the creation of duplicate CIs. A resynchronization is therefore required, to query the entire contents of the dataset before updating it. Before the resynchronization can be performed though, it may be necessary to manually create filters corresponding to the ones that existed prior to the upgrade - see CMDB Synchronization Filters.

When you add a new sync connection, its shadow copy is created, but is empty. When the connection is created, the credentials and CMDB version are checked. The first check also determines whether the CMDB dataset is populated. If so, a resynchronization is required to populate the shadow copy with discovered information and sync that with the CMDB. If the dataset and shadow copy are both empty then no resynchronization is required.

Failed or cancelled resynchronization

If a resynchronization fails or was cancelled, a resynchronization is required before the connection can be resumed.

Initial configuration

The following steps are required to set up CMDB synchronization:

To perform synchronization

Synchronization can be configured to run in a continuous mode, meaning that as soon as BMC Discovery completes its scan of a device, the data corresponding to it is queued for synchronization with the CMDB. Alternatively, synchronization can be launched manually for one or more devices from within the browsing interface.

To prevent synchronization at certain times

Typically, synchronization can occur at any time. However, synchronization can place a substantial load on the CMDB, so it might be necessary to prevent synchronization from occurring at times the CMDB will be used heavily. This can be achieved by configuring Configuring CMDB Sync blackout windows.

To filter synchronization data

By default, all details about all devices are synchronized to the CMDB. In some situations. Usually CMDB administrators tend to import the data required to address users' needs. Filtering enables you to synchronize a subset of the BMC Discovery data. After each of the first three synchronization stages, the data can be filtered to affect the data that finally reaches the CMDB. See CMDB sync performance notes and Filtering nodes and CI types for CMDB Sync for more information.

Root node deletion synchronization failure

When a non-fatal error occurs during synchronization with the CMDB, the root node is re-queued so the synchronization is attempted again. A root node is re-queued up to three times if it fails repeatedly, then synchronization is not attempted again. When the outage is resolved, subsequent discovery runs trigger continuous synchronization and re-submit root node creations and updates. Deletions however are not automatically re-submitted, leading to orphaned graphs in CMDB dataset.

Manual Workaround

When the network outage is resolved, perform a resynchronization to ensure the CMDB contents match the data in BMC Discovery. Alternatively, to synchronize a selection of the missed deletions, run the report “Aged-out Hosts and other devices that failed last CMDB sync”, found in Explore > Reports > BMC Discovery Deployment. Select one or more nodes from the list, and choose Actions > Sync to CMDB.

CMDB class definition changes

If you change any of the CMDB class definitions, for example, using the CMDB Class Manager utility, you must perform a CMDB resynchronization.

Was this page helpful? Yes No Submitting... Thank you