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.
After you upgrade to 11.3, the UI displays a set of tasks that you must complete. The following sections list all the possible tasks. These tasks can vary in your case, depending on the version and configuration of your system before upgrading.
To upgrade to patch 1
The upgrade to BMC Discovery 11.3 patch 1 requires you to regenerate the appliance keys and certificates. A post-upgrade message to this effect is displayed, with a link to the
To edit the sync mapping extensions for the latest patterns
The structure of the CMDB sync mappings changed in BMC Discovery 11.0. Therefore, if you are upgrading from a version before 11.0, 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.
To activate the new TKU with the latest patterns
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. For additional information, see Knowledge management and
latest TKU activation
.
To reapply customizations to the new Discovery scripts
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.
To 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.
To recreate 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:
- Working
- 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 more information, see Recreating legacy filters.
To grant access to the CSV and XML web APIs
The permission required to access the CSV and XML API changed in BMC Discovery version 11.1. You must grant the new API access permission (api-access group) to users who require access to the CSV and XML web APIs. For more information, see Managing system users and Managing groups.
To reconfigure HTTP header authentication to remove underscores
BMC Discovery 11.3 no longer permits underscores in HTTP headers. If you upgrade to BMC Discovery 11.3 and your HTTP Header authentication scheme permits underscores, it will no longer work. You must update the single sign-on provider and reconfigure authentication using HTTP headers.
To reconfigure the changed 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.
Besides the tasks listed above, the following section provides additional information about model changes and VirtualSystemEnabler CI changes that you must be aware of.
Additional changes to consider
Model changes
After upgrading to BMC Discovery 11.3, existing Software Instance and Virtual Machine nodes that represent containers are converted to the new Software Container node kind.
The new Hardware Container node represents a single physical device that contains multiple hosts, network devices and other components (for example, a blade enclosure that is discovered using a management controller, or a hyper-converged device that contains compute and storage). The Host Container node is used to represent a computer that is logically partitioned into a number of hosts, as opposed to containing physically separate devices. After upgrading to BMC Discovery 11.3, existing HostContainer nodes that were used to represent physical devices containing hosts, network devices, and other components are converted to the new Hardware Container node kind.
Sync mapping 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. On first synchronization after upgrading from a version before 11.2, these singleton CIs will be marked as deleted, and new separate CIs will be created corresponding to the separate virtual machines.
Comments
Log in or register to comment.