Configuring after upgrade
The post-upgrade activities that you might consider are the same as post-installation activities. If you have already performed these configuration steps, they are retained on upgrade and do not need to be repeated.
Example post upgrade activities
Depending on the version and configuration of the system before upgrading, some of the following steps may be displayed:
Activate new TKU
The upgrade installs a new TKU package but does not activate it. You must activate the new TKU before performing discovery. If you do not activate the new TKU, the pre-upgrade patterns remain active.
Information on activating and deactivating TPL packages is available here.
The following major changes have been made to the BMC Discovery model:
Logical databases are now stored in dedicated Database nodes rather than the DatabaseDetail nodes previously used. Dedicated Database nodes simplify the separation of databases from other database details. DatabaseDetail nodes are still used for other information about databases, for example schemas and tablespaces.
On upgrade, DatabaseDetail nodes that modeled logical databases are converted to Database nodes. The TKU included with the upgrade, once activated, contains patterns that model databases using Database nodes. You must activate the TKU supplied with the upgrade, otherwise the previously existing patterns will attempt and fail to continue to model databases using the previous model.
For CAM models, you must regenerate and activate the related pattern modules. The upgrade converts all DatabaseDetail nodes used in CAM models to Database nodes as this best reflects what is being modeled. However, for those nodes which you do require to be DatabaseDetail nodes, for example, where you intend to model a table, or schema using a DatabaseDetail, you must edit the model so that it uses DatabaseDetail.
You must regenerate the application mapping TPL whether or not you have edited the model.
To update the CAM model:
- From the CAM Application Mapping channel, run the Groups containing Functional Component Definitions report.
- Check to ensure that the models contain the nodes that you expect.
- Select all of the groups and select Generate Application Mapping TPL from the actions menu.
BMC Discovery 11.2 changes the way that
vm_type attribute. They are now modeled using a Virtual Machine node which makes it easier to find and relate VMs to their containers and Hosts.
On upgrade, SIs that modeled VMs are converted to Virtual Machine nodes. The TKU included with the upgrade, once activated, contains patterns that model VMs using Virtual Machine nodes. You must activate the TKU supplied with the upgrade, otherwise the previously existing patterns will attempt and fail to continue to model VMs using the previous model.
CMDB sync mappings
VirtualSystemEnabler CI changes
As part of the changes to the way virtual machines are modeled, changes have also been made to their representation in the CMDB. Previous releases of BMC Discovery, before version 11.2 created a single BMC_VirtualSystemEnabler CI to represent all virtual machines hosted by a physical machine. Upon first synchronization after upgrade to version 11.2, these singleton CIs will be marked as deleted, and new separate CIs will be created corresponding to the separate virtual machines.
Discovery script changes
Where this topic refers to default scripts, it refers to the discovery scripts that were shipped with the release. For example, in a version 10.1 appliance, the default scripts are those that shipped with 10.1. If you upgrade the appliance to version 11.2, the default scripts are those that shipped with version 11.2.
When you upgrade from one BMC Discovery version to a later version, the discovery scripts may change to implement the new capabilities of the release or to fix defects in the scripts. The new scripts replace the default scripts from the previous release. However, if you have customized any discovery scripts, those are not replaced. Platforms with modified scripts are shown on the Discovery Platforms page with a change bar. When you click through to the platform page you can see the individual scripts that have been modified. Where a script has been modified you are provided with the following additional controls:
- Show Differences – shows side by side versions of the current file and the modified file with highlighted changes. Use this view to identify your modifications, and the changes made during the upgrade, and decide how to move your changes to the new default script.
- Reset To Default – replaces the modified file with the new default script.
Review patterns flagged by the upgrade
The upgrade flags any pattern modules that refer to the old (before BMC Discovery 11.0) data model and therefore need changes to continue to work correctly. Flagged TKU patterns are addressed by activating the new TKU. However, flagged custom patterns require manual review to decide what changes are required.
The Knowledge management page lists pattern modules flagged by the upgrade. If no modules are listed then no action is required. Any listed modules show the errors and/or warnings generated by the upgrade when patterns were compiled. Depending on the severity of the compile messages, pattern modules can be left enabled or disabled. However, all messages should be reviewed to avoid future issues with your patterns. Pattern modules and packages should be updated in the usual way for your environment; either by editing via the user interface or by uploading a new version.
Any pattern packages that you do not wish to update immediately can be deactivated and will no longer be listed. Alternatively, any pattern packages that are no longer required can be deleted.
Upgrading from versions before BMC Discovery 11.0
The structure of the CMDB sync mappings changed in BMC Discovery 11.0 so, if upgrading from an earlier version, you must consider any extensions to existing mappings. The mapping position they extend from may have changed. The
syncmapping versions have been incremented and the knowledge management system will require that you review modules flagged by the upgrade before you can activate patterns.
Before you can activate patterns you must edit the syncmapping extensions. In most cases, you only need to update the version number of an import, but more complex extensions may require more rework because the underlying mappings are quite different.
CMDB sync filters
The CMDB synchronization mechanism was changed in version 10.2 and most filters created using previous versions will no longer work. The filters may be in one of the following states:
- Non functioning, but reviewable. These need to be recreated in the CMDB Sync filter tab.
- Removed. These too need to be recreated in the CMDB Sync filter tab.
For further information, see Recreating legacy filters.
Export mapping sets
The upgrade checks whether there is a newer version of each of the installed mapping sets. If a mapping set has changed since the last version, either by the user modifying it or BMC releasing a newer version, then a warning is displayed to the user. The original mapping is renamed by the upgrade to append ".old" to the mapping set descriptor (the file ending with ".properties") and "_old" to the directory containing the mapping files. You can either:
- Ignore the warning if the export framework is not being used.
- Compare the old mapping set to the new one and keep the new one (that is, do nothing).
- Compare the old mapping set to the new one and decide to keep the old one, in which case the user needs to manually delete the newer mapping descriptor and directory and rename the old ones (removing the .old and _old postfixes).
- Compare the old mapping set to the new one and merge the changes. If the changes to the mapping set have been performed by BMC Software then these changes will be listed in the release notes and the user can apply these changes manually to their own copy of the mapping set.