CMDB 2.0 post-upgrade procedures
After an upgrade to CMDB 2.0, you must assign permission sets to your users or update field-level security of the new fields added to Base Element. Also, you must make changes based on the customizations that were present in CMDB 1.0.
The following topics are provided:
Managing field permissions
After the CMDB 2.0 upgrade procedure is complete, you must assign correct permission sets to your users or update the field-level security of new fields of the Base Element
object. To ensure that your users are able to see all the fields of the Base Element
object, assign the ServiceDesk Staff, ServiceDesk Change Manager, or Remedyforce Administrator permission sets to your users. If you are using profiles, configure the field-level security of the fields added to the Base Element
object for all the required profiles.
For information about new fields of the Base Element
object and the procedures to assign permission sets and update field-level security, see 20.14.01 profile-level permissions in the post-upgrade procedures repository.
Additional post-upgrade procedures
Check the conditions in the following table and perform the recommended actions.
Condition | Action |
---|---|
You were using the following reports:
| After you have switched to CMDB 2.0, but before you delete the CMDB 1.0 data, these reports do not show the data added after the switch to CMDB 2.0. However, after you delete the CMDB 1.0 data, no data is shown in these reports. Therefore, BMC recommends that you rename these reports to:
|
You created filters on the Service and Service Offering lookup fields. | Delete the existing filters on the Service and Service Offering lookup fields and recreate them. |
You were using the Services nearing review date QuickView. | Use the Services nearing review date (CMDB 2.0) QuickView. |
You were using CMDB 1.0 Pentaho packages to import data. | Continue to use the CMDB 1.0 packages. However, BMC recommends that for faster import you use packages for CMDB 2.0. For more information, see Pentaho packages for CMDB 1.0 and 2.0 |
You have marked custom fields as required in CMDB classes (objects). | You can use validation rules. For more information, see How to handle required custom fields in CMDB 1.0 classes (objects). |
You have set a default value of a custom Picklist-type field or an out-of-the-box Picklist-type field. | Set the default values again. |
You have custom workflows, reports, validation rules, triggers, and so on that use the fields of CMDB class objects such as Application and Application Infrastructure (but not Base Element). | Update such workflows, reports, validation rules, and triggers to use the corresponding fields in the Base Element object |
You have created a Master-Detail Relationship in which a CMDB object (except BMC Base Element) is a master. | Create a new custom object and add a Master-Detail Relationship field with For example, you had a custom object Store, which was a detail object for Computer System. Create a new object, New Store, and add a Master-Detail Relationship field that has Base Element as master. Migrate data to the If you also had a Roll-Up Summary type of field for the detail object, add a corresponding Roll-Up Summary field to the |
You have Lookup fields that point to the Base Element object. | You can use the fields of the Base Element object, because all the fields of all the CMDB classes are now available in the Base Element object. |
You have configured Global Search Settings for a CMDB class object (except Base Element). | Configure Global Search Settings by selecting Base Element in the Data Source column and the required fields in the Data Field column. |
Comments
Log in or register to comment.