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 BMC Discovery 24.2, 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.

VMware implicit scans

During the upgrade to BMC Discovery 24.2, vCenter implicit scans might be enabled, irrespective of the previous setting. We recommend that you check that the setting is correct after the upgrade completes.

Custom reporting

Existing custom reports are migrated to configuration nodes. All compatible channel files in the $TIDEWAY/data/custom/reports directory are converted to configuration nodes and the files moved to a subdirectory called imported .

Files with channels can only be migrated if:

they contain only one channel
there is only one element (the channel element) in the file

If an unmigrated channel depends on a report that is migrated, and it itself is not migrated, the channel will not load as migrated reports are only loaded after the files and the dependency will fail.

As with previous releases, if you create a channel and then delete it:

if you are using it, it will be shown with an error string;
it will appear in the dashboard Edit pane until the service is restarted.

Disk allocation/naming

In appliances running on Centos 7, disks were reliably allocated /dev/sdX files in the order of the devices on the SCSI bus, so the system disk was /dev/sda . With Oracle Linux 9, this is no longer the case. The change in disk allocation has no effect on the operation of BMC Discovery, but if you have any tests or scripts that use specific disk names, then these might fail.

Transitioning to scopes/overlapping IP addresses

The BMC Discovery 20.08 release introduced scopes, a means of distinguishing overlapping IP addresses. On upgrade to BMC Discovery from versions before 20.08, all existing discovered devices are considered to be in the default scope. When you scan an endpoint, all scanned devices appear in the scan's scope and will be distinct from devices scanned in any other scope.

However, if an endpoint has already been discovered, and is then scanned using a non-default scope, this creates a duplicate inferred device. To avoid this, upgraded appliances use scope transition mode, where discovered endpoints that do not exist in the scan's scope are matched against existing endpoints in the default scope. If the endpoint is the same, it is updated, including the addition of the scope.

All AWS EC2 hosts have a scope whether discovered by using AWS Systems Manager or ssh, and scope transition mode will update existing EC2 the updated host scripts with the scope.

When you upgrade to BMC Discovery 24.2 from a version earlier than 20.08, and choose to use scope, you should leave the appliance in transition mode until you have scanned the endpoints covered by the BMC Discovery Outposts or appliances where scope has been configured.

If you do not have overlapping IP addresses and do not scan, or do not plan to scan, AWS EC2 hosts by using Systems Manager (SSM) or Google Compute Engine hosts running in Google Cloud Platform, you do not need to consider scopes.

To activate the new TKU with the latest patterns

After upgrading to a 24.2 system, you must activate the TKU. To do so, from the Knowledge-management UI, click the Activate All button.

For additional information, see Knowledge-management and the latest TKU activation documentation..

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 21.3 (12.3) appliance, the default scripts are those that shipped with 21.3 (12.3). If you upgrade the appliance to version 22.1, the default scripts become those that shipped with version 22.1.

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.

Important

If you customize the default scripts, they are not upgraded automatically when you upgrade BMC Discovery. You must ensure that you update the scripts manually, incorporating your changes. Alternatively, you can leverage the new version's defaults by using the Reset To Default option.

OS migration considerations

If any disk changes were made to the existing appliance before a migration, such as moving the datastore to a separate disk, these changes must be repeated on the new appliance. Otherwise, the restore from the old appliance may fail because of insufficient disk space.

The following file locations can be changed if needed by using the disk configuration utility:

core datastore files
datastore log files
backup archive files