This documentation applies to the 8.1 version of BMC Atrium Core, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Identifying duplicated records

The upgrade of BMC Atrium CMDB can result in duplicate records of the same virtual system. To identify those duplicated records, the upgrade installer launches a post-upgrade utility called vzUtil. For this version, the utility is called vzUtil75.

The following topics are provide:

Post-upgrade utility

The post-upgrade utility operates in two phases: Identification and Merge.

Phases used in post-upgrade utility




In the Identification phase, which occurs automatically immediately after an upgrade, the utility scans your data and, by default, identifies duplicate virtual system records in BMC_ComputerSystem and BMC_VirtualSystemEnabler. After the upgrade is complete, if duplicate records are found, a message informs you that you should run the vzUtil utility again to manage the duplicates. The subsequent manual launching of the utility by the user and other steps occur in the Merge phase.


The Merge phase occurs after all upgrade processes are complete. Perform these steps if the vzUtil utility gave you a message indicating that duplicate virtual system records were detected. This utility is not intended to remove duplicate CIs from within the original records of ComputerSystem and VirtualSystemEnabler classes, nor is it intended to remove duplicates from within the migrated instances. The utility removes duplicates that form a pair of duplicates found only between the original and migrated instances.

When to use the post-upgrade utility

You can use the post-upgrade utility any time after the initial upgrading of your data is complete to find duplicate records of virtual systems.

If the utility is run manually at some point after it is called automatically during an upgrade, you can modify the parameters the utility uses for identification by changing the file.

You can specify maximum of seven rules for each class. The rules are similar to reconciliation identification rules. The utility matches the fields specified in each rule in the order they are listed and identifies duplicates that match any of the specified rules. You can specify the rules, along with key attributes, to uniquely identify the duplicate records.

Removing duplicate virtual system records with the post-upgrade utility

This procedure explains how to merge records with the vzUtil utility.

To run the vzUtil utility again for any reconciliation stage, you must clean up for each activity. You should not to re-run the second Merge stage because it is the final stage of vzUtil.


Changes that result from the following procedure affect the production dataset.

Before you begin

If you need to delete files to run the vzUtil utility again, make a copy of the production dataset.

To perform records merge with vzUtil

  1. Launch the vzUtil utility (vzUtil75.cmd on Windows or on UNIX).
  2. Manually run the appropriate reconciliation jobs to help regenerate reconciliation IDs and merge the CIs in production datasets.
  3. Launch the vzUtil utility again.
    The utility populates the CMDB:VzDuplicates form with new reconciliation IDs and instance IDs.
  4. (optional) View log files.
    Logs for vzUtil are generated by default in the Logs folder of the default BMC Atrium Core installation directory (one level below the BMC Atrium CMDB installed path: installationDirectory/../Logs/vzutil.log.
    Two options are available for logging of vzutil:
    • Console type loggingffile type logging (default)

      You can change the default logging type in the log4j_vzutil.xml file.

To perform clean up before reusing the vzUtil utility

  1. For the Identify stage, manually delete entries from the CMDB:VzIdentify form.
    If the entries are not removed, then the first merge stage detects those entries and deletes the CIs in the production dataset.
  2. For the first Merge stage, complete the following steps.
    1. Create a backup of the production dataset.
    2. Reset the reconciliation IDs of the matching CIs in the import datasets and also their weak objects and relationships.
    3. In the production dataset, delete the CI that is identified as a duplicate in the CMDB:VzIdentify form.
    4. Delete the entry from CMDB:VzIdentify form.
    5. Restore the production dataset from the backup taken before running this stage.
    6. Run the reconciliation jobs that generates the reconciliation IDs for the import datasets with the help of reconciliation IDs in the production dataset.
    7. Remove all the entries from the CMDB:VzDuplicates form.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.