Upgrading to version 8.3
The upgrade script upgrades the appliance to BMC Atrium Discovery version 8.3 from the following supported versions:
There is no upgrade path from BMC Atrium Discovery version 7.5 to version 8.3. Rather, you need to migrate your data to a new installation of BMC Atrium Discovery version 8.3.
If you are upgrading from an earlier 7.X or 8.X version you will first need to upgrade to one of the versions listed above.
What you need to proceed with this upgrade
- You must be logged in as the root user with the root user environment.
tidewayservices must be running when you run the upgrade.
- The credentials of a UI user with sufficient permissions to re-import the taxonomy and compile patterns.
- The upgrade script. Download the one appropriate to your architecture from the BMC Electronic Product Distribution (EPD) site. This is one of:
- 32 bit:
- 64 bit:
Vn_nnnnnn_gais the version number. For example,
- 32 bit:
Required appliance specification increased
The required appliance specification has been increased to support the greater discovery capabilities of BMC Atrium Discovery version 8.3. Before upgrading you must ensure that the appliance you are upgrading meets the specification. See the appliance sizing guidelines for more information.
Changes to OS Configuration Files
If you have made changes to operating system configuration files on the appliance, these changes may be overwritten by the upgrade process. After the upgrade has completed, you must check any configuration files you have previously modified and reapply the changes as required.
This upgrade performs an upgrade of the BMC Atrium Discovery database. It is highly recommended that you do not skip running a snapshot. Where a snapshot is created, it can only be restored to an appliance running the pre-upgrade version.
When you run the upgrade, the timezone you have specified will be overwritten and returned to Europe/London unless you have updated the variable
/etc/sysconfig/clock. See Localizing the appliance for information on how to do this.
You may have a number of appliances, for example one or more appliances consolidating to a central consolidated appliance. When a system uses consolidation, the recommended approach is to stop discovery on scanning appliances, ensure that all consolidation operations are complete, and then upgrade all appliances before restarting discovery on the scanning appliances.
Consolidating appliances must always be upgraded first. An 8.3 consolidating appliance can accept data from an 8.2 scanning appliance. An 8.2 consolidating appliance cannot accept data from an 8.3 scanning appliance.
To allow you to better scale your Windows discovery capabilities, Windows Proxy Pools have been added. These allow you to group sets of Windows proxies together, across which the system will distribute discovery requests in order to load balance.
While the pools themselves can be ordered, the proxies in them cannot. Consequently it is not possible to preserve the ordering that has been configured in pre-version 8.3 systems. If you need to preserve certain aspects of the ordering of your existing proxies, you should make a note of what you want to preserve before starting the upgrade.
The following ordering and distribution of proxies occurs automatically during the upgrade.
- All Workgroup proxies are put into their own pool.
- AD proxies are grouped by domain and IP restriction list. AD proxies with the same domain and restriction lists are placed in the same pool.
- Credential proxies are grouped by IP restriction list.
If a VMware ESX/ESXi host is discovered using ssh in the pre-upgrade version of BMC Atrium Discovery, its identity may change post upgrade. The discovery scripts now obtain more information which changes the
UNIX/ESX Linux to
Other/VMware ESX, and because the host's UUID and architecture is now discovered. However, the
last_access_method remains ssh, so the new VMware ESX/ESXi discovery capabilities are not used. You can workaround this by following the following procedure:
- Configure the new VMware ESX/ESXi discovery.
- Cause the ssh discovery to fail and discover using the VMware ESX/ESXi discovery by:
- Changing the username of the ssh credential used.
- Scanning just those VMware ESX/ESXi hosts.
- Reverting the ssh credential username.
The following items are also affected by the upgrade:
- Edge connectivity: Edge connectivity replaces Topology mapping introduced in BMC Atrium Discovery 8.2. If you have used Topology mapping, you can decide whether to retain it or try Edge connectivity. This is described in Edge connectivity in upgraded appliances.
- Tomcat providers: where Tomcat discovery using JMX has been configured, the Tomcat providers are disabled. Tomcat discovery now uses configuration files.
- Sensitive data filters: these have been updated and extended to retrieved files. If you have created custom filters for command line information then the upgrade makes no changes to these. If you have not created custom filters then the new defaults are installed.
- SQL and JDBC credentials: where SQL and JDBC credentials are in use, their existing properties files continue to be used and updated properties files are installed but not used. Where such credentials are unused, the old properties files are replaced with the latest.
tw_options: where the values of
BOGUS_HOSTID_FILTERare the defaults, then they are upgraded to new defaults. If they are non-default, then they are not changed and a warning is written to the upgrade log.
- Windows proxy configuration: Windows proxy configuration information previously held in the
discovery.conffile is now moved to the vault.
- New Runtime Environment node: the Runtime Environment Node replaces the Java SI. The upgrade attempts to find all patterns that trigger on the Java SI (their primary inference is on the Java SI) and writes them to the upgrade log. These patterns will no longer trigger as Java SIs are no longer created. You must modify these patterns to trigger on Runtime Environment Nodes.
Upgrade script options
The upgrade script has the following options:
Do not create a database snapshot before upgrading the BMC Atrium Discovery application. If created, a snapshot takes place after the operating system is upgraded, but before the BMC Atrium Discovery application is upgraded.
Extract the files from the archive contained in the script. This does not perform the upgrade. A manual upgrade is not supported.
Specify a directory in which to store temporary files. The default is
Do not delete the temporary files extracted from the archive after the upgrade has been performed. The temporary files will be owned by the root user.
Automatic mode. Selecting this option means that all questions are automatically answered.
Upgrades the discovery scripts to their latest versions. Any local modifications will be lost. If this option is not specified, the scripts will not be modified, and must be updated manually using the Administration > Discovery Platforms UI after the upgrade is complete. See Managing the discovery platform scripts for more information.
BMC Atrium Discovery UI user. Only valid in automatic mode.
BMC Atrium Discovery UI user password. Only valid in automatic mode.
Provide comprehensive messaging. This information is also logged in the file
Displays a help message on the usage and options. The script then exits.
In the following procedure, the filename is referred to as
Vn_nnnnnn_ga with the version number, in the commands as appropriate. For example,
The upgrade procedure
Delete the contents of the
/var/spool/clientmqueuedirectory. Enter the following commands:
- Copy the
ADDM_Upgrade_<arch>_Vn_nnnnn_ga.sh.gzfile to a temporary directory, such as
Unzip the archive file using the following command:
As the root user, run the upgrade script. Enter:
The following message is displayed:
Enter yes if you have all that you need to perform the upgrade. Answering no aborts the installation.
The script checks that all system requirements are fulfilled.
Then the upgrade itself is commenced, beginning with extracting the files from the archive.
If the temporary directory does not exist you are asked whether it should be created. If it does exist you are asked whether you want to use it. Answering no aborts the installation.
The upgrade then tests that the RPM will install correctly against the current system.
The next part of the upgrade is configuring the system, for example applying patches.
The upgrade script now upgrades the operating system, BMC Atrium Discovery, and any dependencies.
Upgrading the operating system and the BMC Atrium Discovery application may take a long time. If you are not running in verbose mode, you can monitor progress by checking the log file using the following command:
During the operating system upgrade, some SELinux error messages are logged, these can be ignored. See Messages in the Upgrade Logfor notes on messages that may be logged. Part of this stage is to create a snapshot unless you specified otherwise.
The BMC Atrium Discovery application has now been upgraded, but a number of configuration steps need to take place, for example re-importing the taxonomy and recompiling patterns.
If you have asked to upgrade the discovery scripts, a back-up of the current scripts are first saved to
If this fails for any reason, you are asked to confirm whether you still want to upgrade the scripts.
The software upgrade process is now complete. If any further steps are required, in this case rebooting the system after a kernel upgrade, you are informed now, before the script exits.
The appliance is now running BMC Atrium Discovery version 8.3.
Reboot the appliance. Enter the following command:
The software and operating system upgrade is now complete.
Post upgrade steps
After installation there are a number of additional steps required depending on the configuration of the pre-upgrade system. For example, if you have already used CMDB synchronization, you need to update the CMDB.
As well as the notes on this page you should refer to the
postupgrade_8.3_TODO.log written out by the upgrade script at STAGE 6 above. This contains tailored advice of the tasks that must be completed on that particular appliance and these must be completed for correct future behavior.
Messages in the upgrade log
During the upgrade the firewall (
iptables) is restarted. When a kernel upgrade is part of the upgrade, the firewall is unable to restart as there is a mismatch between the running kernel's version and the kernel on disk. The firewall logs a
FATAL message, but as this is entirely expected, the upgrade script wraps it in an information message:
2011-07-25 09:36:46: INFO: FATAL: Could not load /lib/modules/2.6.18-53.1.14.el5 /modules.dep: No such file or directory
This is expected behavior and does not indicate a problem with the upgrade.
Check Windows proxy compatibility
Check the Windows proxy compatibility matrix to determine whether you need to upgrade Windows proxies.
Deactivate existing TKU and activate new TKU
The upgrade installs a new TKU package (TKU-CORE-2011-09-1) but does not activate it. Any TKU Package that you have installed must be deactivated before activating the TKU-CORE-2011-09-1. Information on activating and deactivating TPL packages is available here.
You must activate the new TKU package, unless a newer TKU package is already activated. To know about the latest available TKU, see the latest TKU documentation.
Package changes for CDM Mapping and Discovery Conditions
The CDM Mapping and Discovery Conditions packages have been amalgamated into a single package. Previously, the packages were called:
The new package is called:
Windows proxy configuration file baseline check
The Windows proxy configuration file baseline check now checks the configuration file of all attached Windows proxies, rather than just the local configuration file. As a result, after upgrade this check will display the error "FAILED: Expected results are missing" until it is re-baselined.
Clearing browser caches
After upgrading you should clear the cache of any client browsers or force a refresh (CTRL+F5 in most browsers).
The baseline tool tracks changes to the system configuration from a known baseline. After an upgrade, the appliance configuration will have changed significantly. You should view the baseline page after an appliance upgrade and examine the changes made to the system. When you understand the changes that have been made, you can rebaseline the appliance so that the tool can check for changes from the configuration after upgrading to BMC Atrium Discovery version 8.3.
Maximum cache size
If you upgrade from a version that permits larger cache sizes than the current, the cache size label (see model maintenance settings) is displayed incorrectly.
Export mapping sets
While upgrading, the script will check to see if 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 Software releasing a newer version, then a warning is displayed to the user. The original mapping is renamed by the script to append ".old" to the mapping set descriptor (the file ending with ".properties") and "_old" to the directory containing the mapping files. The user 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 (i.e. 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.