If you have upgraded to BMC Remedyforce 20.14.01, to use CMDB 2.0, you must perform the steps in this section. If your Application Settings menu contains the CMDB 2.0 Upgrade option, you are using CMDB 1.0.
The following topics are provided:
The following table compares how different features are implemented in CMDB 1.0 and 2.0:
Feature | CMDB 1.0 | CMDB 2.0 |
---|---|---|
Reporting | You cannot create a custom report that involves more than two classes (objects). For example, to generate a report in CMDB that gives data about which LAN endpoints are used by which computers, you must refer to three objects: | All classes are part of one object (as field sets), therefore, you can create reports that involve any number of classes. |
Field definition of a class | The CMDB_AttributeDefinition class is used to recognize attributes (fields) that belong to a class (object). | The field sets and field definition of the Base Element object provide the field definition of a class. |
Data import | Records are first imported in a flat table, called a staging table, and then saved in the individual objects. Therefore, the batch size is small. | Records are imported directly into the Base Element object; therefore, the time required to import data is less. Pentaho packages for importing data into BMC Remedyforce are available on BMC Communities. The folders for CMDB include 2.0 in the names. |
Data export | Exporting data is difficult because one configuration item record is saved in more than one object. | Exporting data is easy because all records are saved in the Base Element object. |
Custom fields | Custom fields are added in the required class. You can then access them in the class by navigating to the Remedyforce Administration > Application Settings > CMDB Custom Attributes page. Custom fields appear on the Custom tab on the Instance Editor. | Custom fields are added to the
|
Instance Editor | Custom fields appear on the Custom tab, and you cannot add or remove the fields on the General tab. | To add or remove a field from the General tab, add or remove the field from the Base Element field set. To add or remove a field from the Specifications tab, add or remove the field from the field set of the required class. |
Field tracking | You can track fields that belong to the Base Element object, shown on the General tab on the Instance Editor. You cannot track fields on the Specifications and Custom tabs. | Because fields of different classes are stored in the Base Element object, you can track any field. However, Salesforce allows you to track only 20 fields in one object. |
Search | You can search fields of the Base Element object only. Therefore, search is limited. | All fields (or attributes) are stored in the Base Element object, and the fields of the Base Element object are searched. Therefore, you can search data for all classes. |
Data storage | Different objects are created for different classes; attributes that are common in all classes are stored in the When a record is saved, data is saved in the | All information is stored in the When you save a record, the record is created only in the |
When you upgrade to CMDB 2.0, data from various CMDB classes (objects) is moved to the Base Element
object. Before you decide to upgrade to CMDB 2.0, you must consider the impact of this move.
The following topics are provided:
Consider the following points before you decide to upgrade to CMDB 2.0:
CMDB
object is a child object are not supported.CMDB class
and Base Element
objects that points to a record for another CMDB class are not supported.Base Element
object. If multiple fields with the same name are required in the Base Element
object, use field names as suggested in the scan report. For more information, see CMDB scanning process.Base Element
object. For more information, see Preparing for upgrade to CMDB 2.0.Base Element
object is reached, an error is displayed when custom fields are automatically added to the Base Element object. However, the Unique ID and External ID properties of these fields are not configured in the Base Element
object.In CMDB 1.0, different types of configuration items (CIs) are saved in different objects (classes), such as Computer Systems, LAN Endpoints, and so on. However, in CMDB 2.0, all the CIs are stored in a single object, Base Element
. Fields that store information about a CI type such as Mainframe are grouped together in a field set, Mainframe, that is added to the Base Element
object.
When you upgrade to 20.14.01, the out-of-the-box fields of all the CMDB classes and the field sets of all of the out-of-the-box classes are available in the Base Element
object. If fields with same name existed in different classes, the conflict is resolved, and one or all such fields are added in the Base Element
object. For more information, see How same-field-name conflicts are resolved for out-of-the-box fields. Also, some fields of the Business
Service
object are not added to the Base Element
object. For more information, see Business Service fields that are not added to Base Element.
Note
After migration, the object-level permissions that you set on the objects from which data is migrated are retained at the UI level.
This section provides an overview of the steps that you must perform to upgrade your CMDB. For a detailed procedure, see Upgrading to CMDB 2.0 by using the CMDB Upgrade option. BMC recommends that you read the information in this section before performing that procedure.
The following table provides an overview of the steps to upgrade to CMDB 2.0:
Step | Description | Reference topic |
---|---|---|
Prepare for the upgrade | Before upgrading to CMDB 2.0, you must perform a few tasks, such as backing up your data. Also, you must do preparations based on customizations in your CMDB. | Preparing for upgrade to CMDB 2.0 |
Run the CMDB scan | Before you upgrade to CMDB 2.0, you must scan your CMDB for custom fields that you have added to various CMDB classes. At Remedyforce Administration > Application Settings > CMDB 2.0 Upgrade > CMDB 2.0 Upgrade, click Scan CMDB. The scan report provides you with the following information:
| CMDB scanning process |
Add the identified custom attributes to the Base Element object | You can add the custom attributes automatically or manually. Refer to the scan report and add the custom attributes as fields in the Base Element object. Then, add these fields to the appropriate field sets. If you have custom classes, add field sets for the custom classes in the Base Element object. | Default values assigned to automatically added custom attributes |
Migrate data to CMDB 2.0 | To move all records to the Base Element object, click the Migrate Data button on the CMDB 2.0 Upgrade page. | Not applicable |
Verify migration of your data | You can verify your data in the Base Element object by referring to the logs or creating a tab for the Base Element object. The links to the logs are provided on the CMDB 2.0 Upgrade page. | Verifying data after migration |
Switch to CMDB 2.0 | After you successfully migrate your data, you can start using CMDB 2.0. After you switch to CMDB 2.0, your data is saved in the Base Element object. | Not applicable |
(Optional)Delete CMDB 1.0 data | After you are satisfied that all of your data has been migrated successfully, delete the CMDB 1.0 data to free up the storage space. | Not applicable |
Post upgrade | Based on your customizations in CMDB 1.0, you will need to perform a few more tasks after your CMDB is upgraded. | Performing CMDB 2.0 post-upgrade procedures |
To scan the CMDB, Salesforce queues an Apex job. This job runs based on the Apex jobs scheduled to run in Salesforce. When your CMDB scan is complete, the scan report is available in the comma-separated value (CSV) format.
The scan report lists the following customizations in your CMDB:
If no attribute exists in a custom class, the custom class is not reported in the scan report.
The following table describes the information in a scan report:
Column | Description |
---|---|
Class Label | Name of the custom or out-of-the box class as entered in the Label field. |
Class API Name | Name of the object as entered in the Object Name field. |
Is Custom Class |
|
Field Label | Name of the custom attribute as entered in the Field Label field. |
Field API Name | Name of the custom attribute that is used in internal references as entered in the Field Name field. |
Suggested API Name | Recommended name to be used when you add the custom attribute to the Base Element object. The benefit of using the suggested name is that you can identify the correct field when you generate reports. |
Field Type | The data type of the custom attribute. When you add a Picklist-type of attribute in the Base Element object, refer to the Picklist Values and Picklist Labels columns. |
Default Value | Default value set for a custom attribute. |
The following information about custom fields is not provided in the scan report:
Note
While going through the scan report, verify if multiple custom fields exist in different objects for the same purpose. If you find such fields, verify that you need all these fields and perform one of the following actions:
Computer System
and Mainframe
objects, delete the custom field in one of the objects.If you need all of the custom fields, while adding the fields, ensure that in the Field Name field, you use the value suggested in the Suggested API Name column of the scan report. The value in the Field Name field is an internal reference value and must therefore be unique.
For the first occurrence of a custom field, the suggested API name is the same as the custom field name. The following nomenclature is used to suggest names in the Suggested API Name column for the subsequent occurrences of the same custom field in different classes:
<Acronymoftheclasstowhichthecustomattributebelongs >_<existingvalueinthe Field Name field of the custom attribute>
For example, if the Docking Station field is available in the Laptops custom class (field type Number) and the Mainframe out-of-the-box class (field type Text), Docking_Station and MF_Docking_Station are the suggested API names in the scan report.
Note
If you run the CMDB scan after adding the custom fields, the custom fields that you have added to the Base Element
object are reported again in the scan report. Do not add these fields again.
If you have set a custom attribute as a required field in any of the CMDB classes (objects), prepare a list of such fields. After you upgrade to CMDB 2.0, data for all CMDB 1.0 classes (objects) is saved in the Base Element
object. After data is migrated to CMDB 2.0, this required field becomes required for all the CIs.
If you add custom attributes automatically, clear the Required check box of such fields in the Base Element
object before migrating data.
If you are add custom attributes manually, do not select the Required check box for the these fields in the Base Element
object.
After upgrading to CMDB 2.0, to continue using these fields as required fields for a specific CI class, use a validation rule such as the following example, on the Base Element
object.
UPPER(BMCSERVICEDESK_ClassNamec) == ' BMC<class in which the custom field is required>' && ISBLANK(BMCSERVICEDESK_<Required Field Name>c)
In this validation rule code, replace <class in which the custom field is required> with the name of the class for which the custom field is required (for example, BMC_COMPUTERSYSTEM). Also replace <Required Field Name> with the name of the required field.
When you upgrade to 20.14.01, fields and field sets for various CMDB classes are available in the Base Element
object. If you upgrade your CMDB to version 2.0, data for all CMDB classes is migrated to the Base Element
object. The following rules are used to resolve conflicts that arise when fields in different classes have the same name:
Base Element
object.Base Element
object as Country of field type Text and Country Code with field type Picklist.When you upgrade to CMDB 2.0, the following fields from the Business Service
object are not added to the Base Element
object. In CMDB 1.0, these fields are formula fields that reference the Base Element
object and are not used in CMDB 2.0.
Base Element
object)When custom attributes are added automatically, default values are assigned to some fields of some specific field types. The following table lists the fields that are assigned a default value, the type of field that is created, and the default value that is assigned to the field.
Field type | Field to which a default value is assigned | Assigned default value |
---|---|---|
Formula | Treat Blank As | BlankAsZero |
Geolocation | Display Location in Decimal | True |
Autonumber | Display Format | A-{0000} |
Rich Text Field | Visible Lines | 3 |
Long Text Area | Visible Lines | 10 |
Encrypted Text | Mask Characters | * |
Encrypted Text | Mask Type | All |
When a field of any type is added, the text in the Description field is not copied.
BMC recommends that you upgrade to CMDB 2.0 on a weekend or a holiday. The process takes a few hours, depending on the number of records in your CMDB.
Complete the following actions before beginning to upgrade to CMDB 2.0:
Base Element
object, see Fields in the CI classes. Do not configure field-level security for the fields of the Base Element
field set. For information about configuring field-level security, see the Salesforce Help.Inform your users about the planned schedule of your CMDB 2.0 upgrade so that your users do not create, update, or link a CI record or import records during the upgrade. After you start upgrading to CMDB 2.0, your CMDB is locked and all data added or updated during the upgrade is lost.
Also, if BMC FootPrints Asset Core integration is enabled, do not link or unlink a record.
The following table provides a list of customizations that might be present in your CMDB. If a customization is present in your CMDB, perform the action that is listed in the table.
Customization | Action | Details |
---|---|---|
You have marked custom fields as required in CMDB classes (objects). | Prepare a list of such fields. When you add these fields to the | How to handle required custom fields in CMDB 1.0 classes (objects) |
You have more than 500 custom fields. | Confirm that you want all these fields | You cannot add more than 500 custom fields to an object. If you have more than 500 custom fields in CMDB 1.0, refer to the scan report to confirm that you want all of them. For more information, see CMDB scanning process. |
You have added custom values to out-of-the-box Picklist-type fields. | Add the custom values to the Picklist-type fields manually. | Not applicable |
You have set default values to custom Picklist-type fields or updated the default value of out-of-the-box Picklist-type fields | Prepare a list of such fields and their default values | After your data is migrated, manually assign these default values. |
You have created a Master-Detail Relationship where a | Prepare a list of such fields. | Not applicable |
Before you begin upgrading CMDB, read Preparing for upgrade to CMDB 2.0.
To add the attributes reported in the scan report to the Base Element
object, click Step 2. Add the identified custom attributes to the Base Element object.
You can add the custom attributes automatically (step 6) or manually (step 7 ).
Note
If any custom attribute is required, clear the Required check box for the attribute before adding it to the Base Element
object. For more information, see How to handle required custom fields in CMDB 1.0 classes (objects).
Base Element
object.Click Add Selected Fields to Base Element.
Note
If you choose to have fields added automatically to the Base Element
object, do not click the Scan CMDB button.
The Status column shows the progress and status of adding the selected fields to the Base Element
object.
When fields are added automatically, a default value is assigned to some attributes of a few field types. For more information, see Default values assigned to automatically added custom attributes.
Base Element
object and assign the required fields to the field set:Base Element
object. To migrate data to the Base Element
object, click Step 3. Migrate data to CMDB 2.0, and then click Migrate Data.
Important
The CMDB is locked while migration of data is in progress. During data migration, BMC recommends that you do not perform any actions in the Remedyforce CMDB tab.
After the migration is complete, an email message is sent to you. The result is also shown on the CMDB 2.0 Upgrade page. If the result shows that errors occurred in the data migration, check the logs.
Base Element
object.To free the space occupied by CMDB 1.0 records, click Step 5. Delete the CMDB 1.0 data, and then click Delete CMDB 1.0 data.
The success or failure in deleting CMDB 1.0 data is shown on the screen, and an email message is sent to your email address.
Warning
If an error occurred during the migration to CMDB 2.0 and you selected to switch to CMDB 2.0, if you delete the CMDB 1.0 data, you will lose the data that was not migrated.
If there is no CMDB 1.0 data and you click Delete CMDB 1.0 data, a message appears on the window and the button is disabled.
After the CMDB data migration is complete, check the logs. One of the following logs is provided on the CMDB 2.0 Upgrade page:
Base Element
object for all migrated CIs. If the success log reaches the limit of 5 MB, no new logs are added.Base Element
object, and error stack trace.As an alternative to checking the success logs to verify that your migration was successful, you can create a tab for the Base Element
object and check the records on the tab.
Base Element
object, navigate to Setup > Create > Tabs.Check the data in the records. If you see correct values in the fields, data migration was successful.
Performing CMDB 2.0 post-upgrade procedures