Unsupported content 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.

Recommended steps to migrate a service model to BMC Atrium CMDB

Use the following process to ensure a smooth migrate to service impact management implementation with the BMC Atrium CMDB:

  1. Review and understand how the sim2cmdb upgrade works.
  2. Ensure you have quality data in the BMC Atrium CMDB.
  3. Analyze and understand the data in the cell so you know how it will be identified and reconciled in the BMC Atrium CMDB.
  4. Modify the sim2cmdb.conf file as needed.
  5. Run sim2cmdb without any command to verify the data.
     Running sim2cmdb without any command verifies whether the data is qualified for the BMC Atrium CMDB, generating a detailed output file which lists all the data to be imported and detects any dropped or skipped instances. The dropped or skipped instances are those that could cause potential issues when running the sim2cmdb with the commit option. The output file is explained in the, Reviewing the output files for sim2cmdb section.
  6. Repair the offending data in the cell.
  7. Repeat steps 5 and 6 until no more data is excluded.
  8. Run the sim2cmdb command with the commit option.
     When commit is requested, you want as much data as possible to be migrated. Consequently, set the ContinueOnSkip parameter to T (default is F). For more information about commitment, see Upgrade commitment.

  9. Verify that the output file contains no excluded data.

    Note

    If more excluded data is found in the output file, continue through step 12.

  10. Verify that publication was successful.
     You can verify whether the publication was successful by using CMDB tools or SIM tools. If the data is not automatically published to SIM, you need to diagnose the failure, and, if necessary, repair the data in BMC.ASSET and republish the data by using the publishing server client.
  11. Check the output file for unidentified CIs. Identify them manually, and reconcile. For more information, see CI identification
  12. Verify that publication was successful.
     If publication was not successful, diagnose failure and, if necessary, repair data in BMC.ASSET and publish again.
  13. If in step 9 data you discovered excluded data, repair the offending data in the cell and restart this procedure from step 5.
     Verify that all expected data (especially impact relationships) are exported. You might need to migrate DirectFeed data, too.
  14. When all data from the publish environment is migrated, close the migrate.
  15. When DirectPublish cell data is migrated to BMC Atrium CMDB, close the publish environment.

The following sections explain some of these steps in greater detail.

  Understanding how the migration works

To migrate service model data to BMC Atrium CMDB, you can run the sim2cmdb CLI command. sim2cmdb takes the service model data and the management data in the cell of a specific publish environment and copies the data to a BMC Atrium CMDB dataset, BMC.SIM, where it is reconciled into the BMC.ASSET (production) dataset. When reconciliation terminates, the data is automatically (or manually) published back to the cell. In other words, the CI that was originally created directly in the cell is replaced with a CI from BMC Atrium CMDB.

Replacement in the cell is based on the following information:

  • For CIs--the ComponentAliases attribute
     Even CIs without a value in the ComponentAliases attribute are replaced by sim2cmdb, because if ComponentAliases for a CI is empty, it is assigned the mc_udid as a default.
  • For impact relationships--the consumer_id and provider_id attributes
  • For management data--key attributes of the class

 

Note

The final set of data in BMC.ASSET (after reconciliation and publication) is not necessarily the same as it was in the cell, because this depends on existing data in BMC.ASSET and the precedence of the reconciliation.

Recommendation for service models with CIs in multiple cells is to upgrade all the involved cells at the same time.

If the service model data you want to import into the BMC Atrium CMDB is from a secure publish environment, you must provide authentication information in the sim2cmdb CLI command string.

  Ensuring quality data in BMC Atrium CMDB

Before you can migrate to BMC Atrium CMDB, component data that was created directly in the cell must be qualified. Qualified data means that the data complies with the normalization rules required by the BMC Atrium CMDB so that duplicate CIs can be prevented. Normalization is achieved when a CI from multiple sources is identified by the Reconciliation Engine as the same CI.

To ensure quality data in the BMC Atrium CMDB, you must consider the following factors:

  • Consider the classes under which component instances were created in the cell. Are they valid classes for BMC Atrium CMDB?
  • Consider the attributes for each class under which you have created components in the cell
     To guarantee qualified data, data imported to BMC Atrium CMDB has to follow the normalization rules. The BMC Atrium Common Data Model Normalization Guidelines white paper provides general guidelines for data normalization on major IT component classes. A CI created directly in the cell needs to have the required slot values assigned, and the values must follow the normalization formula addressed in BMC Atrium Common Data Model Normalization Guidelines.

  Identifying components and data reconciliation

A default reconciliation job "BMC SIM to CMDB Migration - Identification and Merge" is provided for the sim2cmdb tool. It is installed on the BMC Atrium CMDB when CMDB Extensions are installed. The reconciliation job defines the data identification rules and identification activities for both component instances and management data instances.

  • For IT component classes, the identification is "best match" rule. Attributes that participate in the identification rules are defined by the requirements in BMC Atrium CMDB data normalization. If the Auto Identify flag for identification activity is set to NO, it means that the ReconciliationId value will not be assigned to the CI during the reconciliation process; therefore, the instance (CI) will not get pushed to the master dataset (BMC.ASSET by default).
  • For logical business classes (for example, BusinessProcess and BusinessService), SIM is the authoritative source, so the Auto Identify flag is set to Yes and the reconciliation ID is assigned automatically.
  • BMC_BusinessProcess.SourceLocation is set to SIM in BMC Atrium CMDB by sim2cmdb.
  • For management data, sim2cmdb uses identification rules that are based on the cell's key slots. The reconciliation ID is automatically assigned.
  • If you do not use any discovery tools to push data into the BMC Atrium CMDB, you can enable auto identify on all identification rules (before you run sim2cmdb) so that no manual identification is necessary. Keeping unique CIs in the BMC Atrium CMDB Master Dataset is a very important BMC Atrium CMDB concept. You must enable auto identification on all rules only if you are certain that the action will not create duplicate CIs in the BMC Atrium CMDB.
    • If a CI is not auto identified, then you must manually identify the CI. See  the three options as explained in the section CI identification.

 

Note

If ITSM is installed, then certain attributes (Category, Type, Item, Model, ManufacturerName) of a CI have to correspond with the attributes of existing products (Tier1, Tier2, Tier3, Product Name, Manufacturer) in the catalog before performing a sim2cmdb commit. If these attributes fail to correspond, the commit will fail when it is run. For more information about how to create entries in the product catalog, how to create product catalog alias mappings, and how to work with trusted datasets for the product catalog, see the supplied ITSM documentation.

sim2cmdb has a default set of identification groups for identifying the components in the BMC Atrium CMDB. The following table lists the following identifying components:

  • Base class that the identification is defined on
  • Classes that inherit the identification group
  • Best match attributes that are used in the rule
  • Value of the auto identification flag

 Identifying components in the BMC Atrium CMDB 

Base class of the identification group

Classes that inherit the rule

Best match attributes

Auto dentify

BMC_Activity

 

Name

Yes

BMC_Application

 

Name 
ApplicationType

No

BMC_ApplicationInfrastructure

 

Name 
ApplicationInfrastructureType

No

BMC_ApplicationService

 

Name 
SystemName 
SystemClassId

No

BMC_BaseElement

BMC_DataBase 
BMC_ApplicationSystem 
BMC_Cluster 
BMC_ConnectivityCollection
BMC_ConnectivitySegment 
BMC_IPConnectivitySubnet 
BMC_LNsCollection 
BMC_LAN 
BMC_WAN

Name

No

BMC_BusinessProcess

 

Name 
SourceLocation

Yes

BMC_BusinessService

 

Name

Yes

BMC_ComputerSystem

BMC_Mainframe 
BMC_VirtualSystem

HostName 
Domain 
SerialNumber

No

BMC_HardwareSystemComponent

BMC_Media 
BMC_CDROMDrive 
BMC_DiskDrive 
BMC_FloppyDrive 
BMC_TapeDrive 
BMC_UPS

Name 
SystemName 
SystemClassId 
SerialNumber

No

BMC_IPXConnectivityNetwork

 

Name 
NetworkNumber

No

BMC_LogicalSystemComponent

BMC_FileSystem 
BMC_DataBaseStorage 
BMC_LocalFileSystem 
BMC_RemoteFileSystem 
BMC_DiskPartition 
BMC_SystemResource

Name 
SystemName 
SystemClassId

No

BMC_Organization

 

Name

Yes

BMC_SoftwareServer

 

Name 
SoftwareServerType

No

BMC_SystemSoftware

BMC_OperatingSystem

Name 
SerialNumber 
VersionNumber

No

BMC_UserCommunity

 

Name

Yes

BMC_VirtualSystemEnabler

 

Name 
SystemName 
SsytemClassId

No

BMC_VMWare

 

Name 
SystemName 
SystemClassId 
VMImageName

No

The reconciliation rules for management data are based on the key slots of the classes. 

 Key slots in reconciliation rules for management data

Class

Keys

Auto-identify

BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING

name 
self_priority

Yes

BMC_DOWNTIME_STATUS_CONFIG

 

Yes

BMC_PROPAGATION_MAP

name 
relationship_state
provider_status

Yes

BMC_SELF_PRIORITY_MAPPING

priority 
status

Yes

BMC_SERVICE_SCHEDULE_CONFIG

 

Yes

BMC_SEVERITY_TO_STATUS

severity 
status

Yes

BMC_SIM_MATCH_TABLE

tag 
input_match

Yes

BMC_SLOT_FORMULAS

event_class

Yes

BMC_STATUS_COMPUTATION

model_name

Yes

BMC_STATUS_PROPAGATION

name 
provider_type 
consumer_type

Yes

BMC_STATUS_TO_SEVERITY

status 
severity

Yes

BMC_TIME_FRAME_TO_SCHEDULE

Timeframe 
Schedule

Yes

BMC_TIME_SCHEDULE

 

Yes

BMC_WORST_SLA_STATE_PRIORITY_MAPPING

name 
sla_state

Yes

SIM_TIME_FRAME

 

Yes

You can modify the reconciliation rules and identification activities according to the nature of your data, but do not change the name of reconciliation job.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*