User custom settings are lost after applying an IBM Tivoli Monitoring fix pack

Resolving The Problem

Preserving user custom settings

During installation of a fix pack, many product files are replaced with newer versions. Other files are merged with existing files to produce the updated version. Still other files are generated by the installation process using values you provide. Also see the following related topic: “Overview of product behavior with custom configuration settings” down below.

These general rules apply to how user custom settings are preserved:

• User-defined constructs are kept. For example, situations, policies, queries, and workspaces are always preserved automatically on upgrade.

• Values you can change through a supported product interface are preserved.

• Values that you have changed manually (for example, because of a technote or as directed by IBM software support) are probably preserved. Any value that you have changed manually that was restored to a default value during an upgrade is recoverable from the backups made during the upgrade process.

The configuration process works with two basic types of files:

• *.ini (initialization) files are used to collect the inputs from the installation process. This input information is the set of responses to installation questions that are captured as keyword-value pairs. This information is laid down with default values and basic information about the installed components.

• *.config (configuration) files are generated by the values in the .ini files and the values entered during configuration.

Essentially, .ini files are source files, while .config files are output files. Although the input .ini files are modified by the configuration tools and sometimes by hand, the configuration output files are rarely modified. In fact, by their very nature, configuration files are generated, and thus anything changed manually in configuration files is lost during the reconfiguration of that component.

To recover a manual customization after installing a fix pack, do the following:

1. Compare the new version of the .config or .ini or .config file with the version saved in the itm_home\backup\backups\date_and_time_of_upgrade directory.

2. Change the installer-supplied defaults to the hand-edited values found in the backup file, make changes as required to carry your hand-edited custom settings forward, and save the new file.


Files that are preserved on upgrade

This section lists and describes the files that are preserved when you upgrade the IBM Tivoli Monitoring environment. If you have modified these files or settings, you can expect the changes to be preserved on upgrade:

• -D flags in Applet.html: Any changes made to the -D flags in file is preserved.

• Bannerimage.html in the CNB directory. If you add a customer image for your own banner, this is preserved.

• -D flags in "cnp" batch or script files: Any changes made to the -D flags on the Java™ calls of these files are preserved. The specific file names are as follows:

– On UNIX or Linux systems: cnp.sh and cnp_inst.sh
– On Windows systems: cnp.bat and cnp_inst.bat

where inst can be the name of an instance of the Tivoli Enterprise Portal to connect to. The -D flags in cnp.sh are not preserved.

• ENV files: The current settings from ENV files are preserved by checking “key = value” and adding keys that did not exist in the new file from the old file and replacing the value from the old file in the new file. Keys with default values are preserved.

• INI files: The ini files are preserved as generally described above. If a change was made using a provided configuration tool, the value is always preserved. If you were instructed by a technote or by an IBM support engineer to make a manual change, the value is most likely, but not always, preserved (depending on what you changed and why).

• OM_TEC.config in one of the following directories:

– On Windows systems: itm_home\cms\TECLIB
– On UNIX or Linux systems: itm_home/tables/temsname/TECLIB

• tecserver.txt in one of the following directories:

– On Windows systems: itm_home\cms\TECLIB
– On UNIX or Linux systems: itm_home/tables/temsname/TECLIB

Files that are not preserved on upgrade

This section lists and describes the files that are not preserved when you upgrade the IBM Tivoli Monitoring environment. If you have modified these files or settings, you must make backup prior to performing the upgrade. After the upgrade, you must reconstitute your modifications from your backups.

For the Manage Scripts feature in Tivoli Enterprise Portal:

The Manage Scripts feature in the Tivoli Enterprise Portal has a set of built-in scripts that manage 3270 terminal session navigation. These built-in functions persist after you install ITM 6.1 Fix Pack 7, ITM 6.2 Fix Pack 1, or any newer releases of ITM. However, you must save the custom scripts that you define for the navigation of 3270 terminal sessions. The IBM Tivoli Monitoring User’s Guide describes this feature.

For components running on Windows or UNIX or Linux computers:

The following IBM Tivoli Enterprise Console event synchronization files:

• In the TEC_CLASSES directory of the rulebase created during IBM Tivoli Enterprise Console event synchronization install: omegamon.baroc, Sentry.baroc.
• In the TEC_RULES directory of the rulebase created during IBM Tivoli Enterprise Console event synchronization install: omegamon.rls.

Before these files are replaced, backup copies are made automatically and placed in the same directories as the original files and have the .bac suffix added to their names. You can open these backup files and migrate customer modifications manually.

Note: These .baroc and .rls files are backed up only if you choose to automatically upgrade the specified rulebase.

For components running on Windows computers:

• On the Tivoli Enterprise Portal Server, the CNP.bat and applet.html files are built based on the content of the CNPS, CNP, and CNB directories. Except for the -D flags, everything in these files is regenerated.

• The buildpresentation.bat file is generated during installation. Any updates to this file are lost.
  
• The CNB/jrelevel.js file is regenerated during installation. Any updates to this file are lost.

For components running on UNIX or Linux computers:

• ARCH/cq|cj|cw/* (where ARCH is a specific architecture, such as li6263) and one of following two-letter codes: cq, cj, or cw). These files (unless otherwise noted above) are overwritten during upgrade. For example, changes to ARCH/cw/jrelevel.js are not preserved.

• /etc/initd/ITMagentsn (the autostart scripts). These files are regenerated during the installation and configuration.

Special exceptions

On UNIX and Linux, several IBM Tivoli Monitoring configuration files exist whose values do not typically persist during an upgrade. However, the values in these files do persist:

• itm_home/tables/temsname/*.txt, where *.txt refers to all file names that have the text (.txt) tag, including partition.txt (previously including glb_site.txt).

Note: glb_site.txt is not supposed to be preserved. It is a configuration output file and its values are gathered and stored during normal configuration.

• The following files are generated from kbbenv.ini and ms.ini respectively:

– itm_home/tables/temsname/KBBENV
– itm_home/config/.ConfigData/hostname_ms_temsname.config.

Changes made to these files are saved in the same way that changes made to the source .ini files are saved.

Overview of product behavior with custom configuration settings

This section provides an overview of product behavior regarding custom configuration settings.

Before you upgrade to a fix pack

It is advisable to back up your IBM Tivoli Monitoring environment, especially if you have a more complicated environment. Most large companies have a standard process for preserving a backup image of all computer systems, including the IBM Tivoli Monitoring environment.

General operations

Several types of variables control the operation of IBM Tivoli Monitoring component. The basic types are as follows:

• User-modified variables: Users generate these settings while doing a configuration, changing a value in the CLI or GUI configuration GUIs, and then saving the changes. These are user-modifiable variables, and are typically stored in initialization (*.ini) files on the disk using variables, like key=$VAR1$, which are then substituted with the value that the user specifies.

• System variables: The second type of setting is a variable for an internal component that you cannot configure through the common configuration tools. These variables are stored in *.ini files, in entries like NUM_TIMES_TO_TRY=4. No dynamic substitution takes place. This type of setting is static.

The following list describes persistence in several scenarios:

• During upgrade from one version of a component to another, the user-modified variables are always persisted with the installation values that are set through the configuration tools.

• If a user modifies these values by hand, for example adding a new value to the end of an existing $VR$ value, that new value is not persisted.

• The static values for the system are typically not persisted because they are internal component variables, and not typically exposed to the user for configuration. These static variables are not documented. In most cases, they should not be changed. Changing these values without instructions from a technote or IBM Software Support could lead to unpredictable results. To ensure stability of the system, the default values are restored when you upgrade to a new component version level.

Although these variables normally are not persisted, a variable that you add that does not already have a key is persisted. This type of value is usually created under the guidance of IBM Software Support.

Specific details

The parameters are preserved through the following distinct conventions based on platform:

For UNIX or Linux systems

An *.ini file has a single line that starts with @preserved. After that line keys are listed that are considered preserved in that file. Be aware that the @preserved line itself might not persist the merged file after an upgrade, but the line is always present after a fresh installation of the product.

For Windows

Both the *.ini file and the ENV file contain variables that are preserved.

• In the Windows *.ini file, all variables in the [Override Local Settings] section are preserved. Nothing outside this section is preserved.


• In the ENV file variable=value, the same information is kept, unless upgrading from a previous Candle release. In that case, no values are preserved. For example, ENV variables up to the following divider are preserved:

***** ADDED BY CONFIGURATION PROGRAM: DO NOT EDIT BELOW THIS POINT! *****

Nothing after this line is preserved.

Keep notes about any changed static variables that you modify in response to instructions from technotes, IBM Software Support, and so on. After performing an upgrade, examine whether the values need to be reapplied.

Overriding configuration values

Advanced users can apply override values to component customization. This method ensures that values are retained during upgrade. You should test this method in your environment before applying it globally:

Overriding configuration values on UNIX-based systems

To learn about overriding configuration values on UNIX-based systems, refer to http://www.ibm.com/support/docview.wss?uid=swg21502892.

Overriding configuration values on Windows systems

1. Select the monitoring agent that you want to update in the Manage Tivoli Enterprise Monitoring Services window.
2. Right-click and select Advanced > Edit Variables.
3. Click Add.
4. Select KDC_FAMILIES from the pull-down list of variables. The @Protocol@ value is displayed in the Value field.
5. Append IP.PIPE SKIP:15 to the current value. The resulting string is @Protocol@ IP.PIPE SKIP:15.
6. Click OK.
7. Click OK again.