Upgrading to version 10.1

The upgrade script upgrades the appliance to BMC Atrium Discovery version 10.1.x from the following supported versions:

  • 9.0.x on Red Hat Enterprise Linux 6
  • Previous versions of 10.0.x

Upgrade from BMC Atrium Discovery 10.x

If you are on any version of BMC Atrium Discovery 10.0.x, you can upgrade to a later Patch, Service Pack, or version from the appliance’s UI. For more information, see Upgrading from BMC Atrium Discovery version 10.

Migration from BMC Atrium Discovery 8.3.x

There is no upgrade path from previous versions of BMC Atrium Discovery (8.3.x) to version 10.0. Rather, you need to migrate your 8.3.x data to a new installation of BMC Atrium Discovery version 9.0 running on Red Hat Enterprise Linux 6 and then upgrade to BMC Atrium Discovery version 10.1. This is shown in the following diagram:

Summarizes the upgrade and migration options. Moving from BMC Atrium Discovery versions on RHEL5 to RHEL 6 requires a data migration. Moving BMC Atrium Discovery versions while remaining on RHEL 5 only requires an upgrade.

There is no upgrade path from BMC Atrium Discovery version 7.5 to version 10.1. Rather, you need to migrate your data to a new installation of BMC Atrium Discovery version 9.0 and then upgrade to BMC Atrium Discovery version 10.1.

To create a new installation, see Installing the virtual appliance.

Upgrading from an earlier version

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.

Script to upgrade from BMC Atrium Discovery 9.0.x

To upgrade from version 9.0.x, run the upgrade script.

What you need to proceed with this upgrade

  1. You must be logged in to the appliance using a screen session. See Recovering from a lost connection using screen.
  2. The tideway services must be running when you run the upgrade.
  3. You must change to the root user with the root user environment.
  4. The credentials of a UI user with sufficient permissions to re-import the taxonomy, upgrade discovery scripts, and compile patterns. We recommend that you use the system user.
  5. The upgrade script. Download it from the BMC Electronic Product Distribution (EPD) site. These are:
    • Upgrading from 9.0.x on RHEL 6 to 10.0.x file: ADDM_Upgrade_from_9.0.x_to_Vn_nnnnnn_ga.sh.gz
    • Upgrading from a previous 10.0.x file: ADDM_Upgrade_Vn_nnnnnn_ga.tgz
      Vn is the BMC Atrium Discovery version number to which you are upgrading to and nnnnnn is the build number. There is no upgrade for versions of BMC Atrium Discovery running on Red Hat Enterprise Linux 5.


Changes to OS Configuration Files

If you have made changes to OS configuration files on the appliance, these changes might 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.

Database upgrade

This upgrade performs an upgrade of the BMC Atrium Discovery database. It is highly recommended that you do not skip running a backup. Where a backup is created, it can only be restored to an appliance running the pre-upgrade version.

Upgrade considerations

Click the following items to show additional information or explanation.

 For users with consolidating appliances

When a system uses consolidation, the suggested approach in this upgrade is:

  1. Stop discovery on scanning appliances.
  2. Ensure that all consolidation operations are complete.
  3. Stop discovery on consolidating appliances.
  4. Upgrade consolidating appliances.
  5. Restart discovery on the consolidating appliances.
  6. Upgrade scanning appliances as required.
  7. Restart discovery on the scanning appliances.

Version 9.x scanning appliances can consolidate to version 10.x consolidating appliances, but version 10.x scanners cannot consolidate to earlier consolidating appliances. Once you have upgraded your consolidating appliances, you can then upgrade scanning appliances as required. You should definitely plan to upgrade them all eventually, it is not a permanent solution to leave some scanners at version 9.

 Retaining the set timezone

When you run the upgrade, the timezone you have specified will be overwritten and returned to Europe/London unless you have updated the variable ZONE in /etc/sysconfig/clock. See Localizing the appliance for information on how to do this.

 For users of CMDB Sync

Where an upgrade makes changes to syncmapping files (see Default CDM Mapping and Syncmapping block), the initial CMDB syncs after upgrade might result in longer reconciliation times. Examples of such changes are key changes or attribute changes on a CMDB CI.

 Model changes - RAM and Physical RAM

In BMC Atrium Discovery version 10, the model changed to detail Physical RAM and Logical RAM on a host. As part of the upgrade from versions of BMC Atrium Discovery prior to version 10, the old RAM attribute of an existing host is set to zero and it, and the Logical RAM attribute will be repopulated when the host is next scanned.

 Miscellaneous upgrade items

The following items are also affected by the upgrade:

  • 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.
 Re-running an upgrade

You can re-run the upgrade to BMC Atrium Discovery 10 if it is terminated or fails. Destructive actions are recorded and are skipped on subsequent upgrade runs. Consequently when an upgrade is re-run, it is usually significantly quicker. You are unlikely to need to run the upgrade more than once, as it would only be required if an upgrade fails. An option is provided (--redo) to re-run an upgrade as if no previous upgrades to this version have previously run.

 Temporary files directory (default: /usr/tideway/tmp) must be readable by tideway user

The location used by the upgrade for temporary files must be readable by the tideway user. The default location (which will be created if it does not exist) is /usr/tideway/tmp, and can be changed using the command line option --tmpdir.

Upgrade script options

The upgrade script has the following options:




Do not backup the database before upgrading the BMC Atrium Discovery application. If created, a backup takes place after the operating system is upgraded, but before the BMC Atrium Discovery application is upgraded.


Force overwrite of an existing local backup.


Extract the files from the archive contained in the script. This does not perform the upgrade. A manual upgrade is not supported.

--tmpdir dirname

Specify a directory in which to store temporary files. The default is /usr/tideway/tmp
Note: This directory needs at least 3230MB.
Note: This directory must be readable by the tideway user.


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. If you provide invalid credentials, a manual taxonomy import and pattern recompile will be necessary. Details and more information are available in the log file on completion.


BMC Atrium Discovery UI user. Only valid in automatic mode.


BMC Atrium Discovery UI user password. Only valid in automatic mode.
Note: If your password contains any special characters you must escape them with a backslash character, that is instead of $ use \$.


The passphrase used to open the encrypted vault. Only valid in automatic mode.
Note: If your password contains any special characters you must escape them with a backslash character, that is instead of $ use \$.


Re-run the upgrade ignoring anything that has been done in a previous run of this upgrade.


Provide comprehensive messaging. This information is also logged in the file /usr/tideway/log/upgrade_Vn.log. See #Messages in the Upgrade Log for notes on messages that might be logged.


Displays a help message on the usage and options. The script then exits.

In the following procedure, the file name is referred to as ADDM_Upgrade_from_9.0.x_to_Vn _nnnnnn_ga.sh.gz. Replace Vn with the version number and nnnnnn with the build number, in the commands as appropriate. For example, ADDM_Upgrade_from_9.0.x_to_10.0.0.2_365935_ga.sh.gz.

The upgrade procedure

  1. Log in to the appliance command line as the tideway user.
  2. Run screen. Enter:

    [tideway@localhost ~]$ screen 
  3. Become the root user. Enter:

    [tideway@localhost ~]$ su 
    [root@localhost tideway]# 
  4. Copy the ADDM_Upgrade_from_9.0.x_to_Vn _nnnnnn_ga.sh.gz file to a temporary directory, such as /usr/tideway/tmp.
  5. Extract the archive file using the following command:

    [root@localhost tmp]# gunzip ADDM_Upgrade_from_9.0.x_to_Vn _nnnnnn_ga.sh.gz
  6. As the root user, run the upgrade script. Enter:

    [root@localhost tmp]# sh ADDM_Upgrade_from_9.0.x_to_Vn _nnnnnn_ga.sh

    The following message is displayed:

    BMC Atrium Discovery and Dependency Mapping Appliance 10.1 upgrade
    The Release Notes for this version contain vital information for any user
    wishing to upgrade their appliance. Please ensure that you have read them
    prior to continuing. The Release Notes are available online:
    Please note:
      - It is important that you perform the post-upgrade tasks listed in
        the Post Upgrade Task Summary.
    To complete the upgrade you will need:
      - To execute this script as the root user
      - ADDM credentials for a user with admin privileges
      - If enabled, the passphrase with which the vault is protected
    NOTE: This upgrade will:
     - Remove any record and pool data on this appliance.
     - Terminate any in progress Consolidation Runs.
    Have you read the Release Notes, and do you have everything you need to
    complete the upgrade (yes/no)?
  7. 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.

    STAGE 1: Pre Upgrade Checks
    1.1: Check Operating System                                [  OK  ]
    1.2: Check ADDM version                                    [  OK  ]
    1.3: Check for development packages                        [  OK  ]
    1.4: Get credentials
        ADDM application (UI) credentials are required for upgrade.
        Please use an ADDM application user with sufficient privileges,
        for example the "system" user.
        Please enter ADDM user (Default: system):
        Please enter password for system:
            Testing credential ...                             [  OK  ]
    1.5: Check temporary directory                             [  OK  ]
        Temporary directory /usr/tideway/tmp/twf.upgrade does not exist.
        Create it (yes/no)? yes
    1.6: Check disk space                                      [  OK  ]
    1.7: Check if ADDM services can be restarted               [  OK  ]
    1.8: Check for Vault passphrase                            [  OK  ]
  8. Then the upgrade itself is commenced, beginning with extracting the files from the archive, and then estimating the time required for the upgrade.

    STAGE 2: Archive extraction and estimation
    2.1: Extracting files                                      [  OK  ]
    2.2: Extracting upgrade tools                              [  OK  ]
    2.3: Estimating remaining upgrade time                     [  OK  ]
        The upgrade is estimated to take between 30 minutes and an hour
        NOTE: This does NOT include any time required to wait for any active
              Discovery or CMDB synchronization to complete.
              Also note that this estimate assumes sufficient resources are
              available, i.e. tasks will complete in a reasonable time and not be
        Do you want to continue (yes/no)?
  9. Enter yes to continue the upgrade. Answering no aborts the upgrade.

    2.4: Unpack OS Upgrade files                               [  OK  ]
    2.5: Extracting RPMs                                       [  OK  ]
    2.6: Check device compatibility                            [WARNING]
        Devices package incompatible with new release
    2.7: Removing incompatible devices package                 [  OK  ]
    2.8: Check if devices need to be upgraded                  [  OK  ]
    2.9: Check default dashboard                               [WARNING]
        The default dashboard has been replaced.
        The previous version has been saved.
    2.10: Ensure Discovery is stopped                          [  OK  ]
    2.11: Ensure Automatic Grouping is complete                [  OK  ]
    2.12: Ensure CMDB sync is complete                         [  OK  ]
    2.13: Cancel in progress Consolidation Runs                [  OK  ]
  10. Now the OS is upgraded.

    STAGE 3: Upgrade Operating System
    3.1: Upgrading the Operating System                        [  OK  ]
      Welcome to the BMC Atrium Discovery and Dependency Mapping Appliance operating system upgrade
      The script will perform the following (unless selected otherwise, see --help):
        - perform upgrade requirement checks
        - extract the relevant files from the archive into the selected directory
        - upgrade the Operating System
        - perform any post installation steps
       Continue with the upgrade (yes/no)?  
  11. Enter yes to continue the upgrade. Answering no aborts the upgrade.

       Performing upgrade requirements checks ...
       Temporary directory /usr/tideway/tmp/twf.upgrade/twf.os.upgrade does not exist, create it (yes/no)?  yes (automatic)
      Extract directory on the same disk as the datastore - need extra 1GB space.
      Checks complete.
    STAGE 1: OS Upgrade - Archive Extraction.
      Starting extraction ...
      Archive extracted.
      Unpacking Archive ...
      Archive unpacked.
      Extraction complete.
    STAGE 2: OS Upgrade - RPM Upgrade Tests
      Starting RPM upgrade test ... this may take a while, please be patient.
      Tests complete.
    STAGE 3: OS Upgrade - Upgrade Operating System
      Stopping services ...
    Stopping httpd: [  OK  ]
      Services stop complete.
      Starting RPM Upgrade ... this may take a while, please be patient
      Packages successfully upgraded.
    STAGE 4: OS Upgrade - Post Installation Configuration.
      Starting services ...
    Starting httpd: [  OK  ]
      Services start complete.
    STAGE 5: OS Upgrade - Post Upgrade Task Summary
      The Kernel has been upgraded. The system MUST be rebooted.
      Task summary can be found in /usr/tideway/log/postosupgrade_6.14.03.04-357114_TODO.log
      OS Upgrade complete - Thu Mar 13 00:43:54 GMT 2014
  12. The upgrade then tests that the RPM will install correctly against the current system.

    STAGE 4: RPM Upgrade Tests
    4.1: Check for new RPM public signature key                [  OK  ]
    4.2: Testing that RPMs can be upgraded                     [  OK  ]
  13. The next part of the upgrade is configuring the system, for example backing up existing discovery scripts.

    STAGE 5: Configure System for Upgrade
    5.1: Audit upgrade start                                   [  OK  ]
    5.2: Backup existing Discovery scripts                     [  OK  ]
  14. The upgrade script now upgrades BMC Atrium Discovery and any dependencies. Part of this stage is to create a backup unless you specified otherwise.

    STAGE 6: Upgrade ADDM and dependencies
    6.1: Upgrading saved baseline files
    6.2: Set model ready flag
    6.3: Moving consolidation configuration into datastore
    6.4: Stop services
    Stopping Tideway application services
        Stopping Application Server service:                   [  OK  ]
        Stopping Reports service:                              [  OK  ]
        Stopping Tomcat:                                       [  OK  ]
        Stopping Reasoning service:                            [  OK  ]
        Stopping CMDB Sync (Transformer) service:              [  OK  ]
        Stopping CMDB Sync (Exporter) service:                 [  OK  ]
        Stopping vSphere Proxy service:                        [  OK  ]
        Stopping SQL Provider service:                         [  OK  ]
        Stopping Phurnace Integration service:                 [  OK  ]
        Stopping Mainframe Provider service:                   [  OK  ]
        Stopping Discovery service:                            [  OK  ]
        Stopping Vault service:                                [  OK  ]
        Stopping Options service:                              [  OK  ]
        Stopping Coordinator service:                          [  OK  ]
        Stopping Model service:                                [  OK  ]
        Stopping Security service:                             [  OK  ]
        Stopping Free Space Monitor service:                   [  OK  ]
    Stopping omniNames                                         [  OK  ]
    Appliance shutdown tasks
        Stopping crond:                                        [  OK  ]
        Stopping httpd:                                        [  OK  ]
    6.5: Performing backup
        Starting omniNames                                     [  OK  ]
        Starting local backup                                                           
        Backup Custom Reports (Task:4/42): Time left: , Processed: 0%                   
        Backup Custom Reports (Task:4/42): Time left: , Processed: 0%                   
        Successfully created archive addm_data_custom_reports.tgz    
        Verify addm_datastore_data (Task:42/42): Time left: 2 seconds, Processed: 95%   
        Successfully verified archive addm_datastore_data.tgz     
        Backup create completed                            
    Stopping omniNames                                         [  OK  ]
    6.6: Check persistence files                               [  OK  ]
    6.7: Performing DB transaction recovery                    [  OK  ]
    6.8: Backup existing mapping sets                          [  OK  ]
    6.9: Copy JDBC drivers                                     [  OK  ]
    6.10: Removing old record data                             [  OK  ]
    6.11: Removing old pool data                               [  OK  ]
    6.13: Remove any old rpmsave files                         [  OK  ]
    6.14: Backup tripwire policy files                         [  OK  ]
    6.15: ADDM RPM upgrade                                     [  OK  ]
    6.16: Check tripwire configuration                         [  OK  ]
    6.17: Remove legacy packages                               [  OK  ]
    6.18: Remove any old BerkeleyDB files                      [  OK  ]
    6.19: Check for conflicting file changes                   [  OK  ]
    6.20: Cleaning up old pattern code                         [  OK  ]
    6.21: Copying TKU bundle to release location               [  OK  ]
    6.22: Check installed mapping sets                         [  OK  ]
    6.23: Check Apache HTTPS redirect rule                     [  OK  ]
    6.24: Check Apache HTTPS server key permissions            [  OK  ]
    6.25: Check the location of a custom graph-definition.txt  [  OK  ]
  15. 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, upgrading discovery scripts, and recompiling patterns. In this upgrade the datastore is reindexed which might take some time, depending on the amount of data contained in the datastore.

    STAGE 7: Post Upgrade Configuration.
    7.1: Restart system services
    Starting httpd:                                            [  OK  ]
    Local appliance start up tasks
        Clearing appliance temporary files                     [  OK  ]
        Starting Cluster Manager service:                      [  OK  ]
    Starting omniNames                                         [  OK  ]
    Starting local Tideway application services
        Starting Security service:                             [  OK  ]
        Starting Model service:
     Transaction recovery...
     Transaction recovery - 10%
     Opening databases...
     Opening databases...
     Upgrading taxonomy
     Upgrading taxonomy
        Starting Vault service:                                [  OK  ]
        Starting Discovery service:                            [  OK  ]
        Starting Mainframe Provider service:                   [  OK  ]
        Starting Phurnace Integration service:                 [  OK  ]
        Starting SQL Provider service:                         [  OK  ]
        Starting vSphere Proxy service:                        [  OK  ]
        Starting CMDB Sync (Exporter) service:                 [  OK  ]
        Starting CMDB Sync (Transformer) service:              [  OK  ]
        Starting Reasoning service: Merging identical pattern packages
        Compiling 1048 pattern modules
        Compiled 10 of 1048 pattern modules
        Compiled 20 of 1048 pattern modules
        Compiled 1040 of 1048 pattern modules
        Updated 90 of 1048 PatternModule nodes
        Updated 210 of 1048 PatternModule nodes
        Finding all rule modules
        Compiling 1098 rule modules
        Compiled 10 of 1098 rule modules
        Compiled 20 of 1098 rule modules
        Compiled 1090 of 1098 rule modules
        Storing rule module details
        Committing changes to datastore
        Initialising Reasoning
        Loading rules and configuration                        [  OK  ]
          Installing new TKU packages: 
            TKU-Core-2014-10-1-ADDM-10.0+: Compiled 390 of 762 pattern modules
        Writing pattern modules to datastore                   [  OK  ]
            TKU-Extended-DB-Discovery-2014-10-1-ADDM-10.0+:    [  OK  ]
            TKU-Extended-Middleware-Discovery-2014-10-1-ADDM-10.0+: [  OK  ]
            TKU-System-2014-10-1-ADDM-10.0+:                   [  OK  ]
        Starting Tomcat:                                       [  OK  ]
        Starting Reports service:                              [  OK  ]
        Starting Application Server service:                   [  OK  ]
        Starting Scanning:                                     [  OK  ]
        Updating cron tables:                                  [  OK  ]
        Updating baseline:                                     [  OK  ]
    7.2: Upgrading JDBC drivers                                [  OK  ]
    7.3: Copy Windows Proxy files to download location         [  OK  ]
    7.4: Converting CMDB Sync properties file                  [  OK  ]
    7.5: Restart remaining services
    Starting crond:                                            [  OK  ]
    7.6: Check if ADDM services are running                    [  OK  ]
    7.7: Restart IPv4 firewall                                 [WARNING]
        Failed to restart IPv4 firewall, probably due to kernel update
    7.8: Restart IPv6 firewall                                 [WARNING]
        Failed to restart IPv6 firewall, probably due to kernel update
    7.9: Audit upgrade end                                     [  OK  ]
  16. The software upgrade process is now complete. If any further steps are required as part of the application software upgrade, in this case re-baselining Tripwire, you are informed now.

    STAGE 8: Post Upgrade Task Summary
    Discovery scripts
    Discovery Scripts have been upgraded.
    Please review the new scripts.
    Taxonomy import
    Ignoring broken extension /usr/tideway/data/custom/taxonomy/BadBat.xml
    Ignoring broken extension /usr/tideway/data/custom/taxonomy/BadBat_Host.xml
    5 warnings
    Some taxonomy extensions failed to import
    Please run (as tideway user, with services running):
      tw_tax_import --clear --username=<username>
    with appropriate credentials to get details on why these extensions failed
    (you will be prompted for a password) and then fix all the issues until you
    can rerun the same command successfully.
    This task summary can be found in /usr/tideway/log/postupgrade_10.0_TODO.log
    and in the ADDM UI.
  17. If any further steps are required as part of the OS upgrade, 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 10.1.

    STAGE 9: Post Operating System Task Summary
    The Kernel has been upgraded. The system MUST be rebooted.
    Re-run /usr/bin/vmware-config-tools.pl after reboot to
    reconfigure VMware tools with the updated kernel.
    Operating System task summary can be found in /usr/tideway/log/postosupgrade_6.14.03.04-357114_TODO.log
    Upgrade complete - Thu Mar 13 01:16:09 GMT 2014
  18. Reboot the appliance. Enter the following command:

    root@localhost tmp]# reboot

    The software and OS upgrade is now complete.

Post upgrade steps

After upgrading there are a number of additional steps required depending on the configuration of the pre-upgrade system.

As well as the notes on this page you should refer to the postupgrade_10.0_TODO.log written out by the upgrade script at STAGE 8 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 

BMC Atrium Discovery 8.3 Windows Proxies

The default keys and certificates used in very old versions of BMC Atrium Discovery expire in 2015. The transition to newer default keys started with version 9.0, meaning that, as long as the version 10.1 appliance is configured to use the legacy keys, an appliance can use a version 9.0 proxy, but it cannot use a version 8.3.x proxy that uses the default keys.

To use a version 8.3.x proxy, by far the best approach is to upgrade the proxy to version 10.1. If that is not possible, suitable CA certificates must be installed on the proxy.

To make 8.x proxies operate with a 10.1 appliance

To make 8.x proxies operate with a 10.1 appliance you must copy the new certificate authority file to the main proxy folder and each of the runtime folders. To do this:

Ensure that the appliance is using the legacy key and certificate.

  1. Concatenate the two files containing the public keys, /usr/tideway/etc/ca/appliance_ca.pem (new public key) and /usr/tideway/etc/ca/appliance_ca_1.pem (old public key), using the following command:
    cat /usr/tideway/etc/ca/appliance_ca.pem /usr/tideway/etc/ca/appliance_ca_1.pem > /usr/tideway/etc/ca/appliance_ca.pem
  2. Copy /usr/tideway/etc/ca/appliance_ca.pem from the appliance to the 8.x proxy folders. Put a separate copy in the main proxy folder and each of the runtime folders. For example:
    • C:\Program Files (x86)\BMC Software\ADDM Proxy\etc
    • C:\Program Files (x86)\BMC Software\ADDM Proxy\runtime\<proxy name1>\etc
    • C:\Program Files (x86)\BMC Software\ADDM Proxy\runtime\<proxy name2>\etc
  3. Restart all of the proxies.
  4. Move the appliance_ca.pem file out of the /usr/tideway/etc/ca/ directory, for example to the /tmp directory.
To make proxies upgraded from 8.x to 9.x operate with a 10.1 appliance

Proxies that have been upgraded from 8.x to 9.x also require a manual upgrade of their default certificates in order to operate with a 10.0 appliance. To do this:

  1. Copy C:\Program Files (x86)\BMC Software\ADDM Proxy\etc\ca_01.peminto each of the proxy runtime folders. For example:
    • C:\Program Files (x86)\BMC Software\ADDM Proxy\runtime\<proxy name1>\etc
    • C:\Program Files (x86)\BMC Software\ADDM Proxy\runtime\<proxy name2>\etc
  2. Restart all of the proxies.

Proxies deployed from a 9.x proxy manager, whether upgraded or newly installed, work without any manual configuration.

Check the Windows proxy compatibility matrix to determine whether you need to upgrade Windows proxies.

Activate new TKU

The upgrade installs a new TKU package (TKU-Core-2014-10-2-ADDM-10.1+) but does not activate it. The new TKU must be activated before performing discovery. Information on activating and deactivating TPL packages is available here.

Review patterns flagged by the upgrade

The upgrade flags any pattern modules that refer to the old network 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.

Baseline changes

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 a newer version of BMC Atrium Discovery.

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.

Recovering from a lost connection using screen 

If you lose the connection to the appliance during the upgrade and you have used screen, you can reconnect to the appliance and recover the virtual terminal running the upgrade. To do this:

  1. Reconnect to the appliance and login as the tideway user.
  2. List the current screen sessions. Enter:

    [tideway@appliance01 ~]$ screen -ls
    There is a screen on:
    23274.pts-0.appliance01 (Detached)
    1 Socket in /var/run/screen/S-tideway.

    You can re-attach to it with a simple command:

    [tideway@appliance01 ~]$ screen -r

    The virtual terminal is recovered and you can see how the upgrade is progressing.

Was this page helpful? Yes No Submitting... Thank you