CA SystemEDGE User Guide › Installation and Deployment › Upgrade Managed Nodes and AIM Servers › Agent and AIM Upgrades › Agent Upgrade from SystemEDGE 4.3.4
Agent Upgrade from SystemEDGE 4.3.4
The installer does the following when upgrading configuration files from a previous 4.3.4 release.
- The installer detects and copies previous versions of the following files to the CASYSEDGE\upgraded directory:
- system32\sysedge.cf (Windows) and /etc/syedge.cf (UNIX)
- CASYSEDGE\config\sysedgeV3.cf (Windows and UNIX)
- system32\sysedge.mon (Windows) and /etc/sysedge.mon (UNIX)
- system32\sysedge.lic (Windows) and /etc/sysedge.lic (UNIX)
- CASYSEDGE\plugins\monwin\monwin.cf (Windows and UNIX)
- When the agent starts for the first time, it copies the following files directly into the CASYSEDGE_DATADIR directory:
- CASYSEDGE\config\sysedge.cf (Windows and UNIX)
- CASYSEDGE\config\sysedgeV3.cf (Windows and UNIX)
- As part of the sysedge.cf copy operation, the agent migrates the configuration data in the sysedge.cf, sysedge.mon, and monwin.cf files in the upgraded directory into the new sysedge.cf file in the data directory.
- As part of the sysedgeV3.cf copy operation, the agent migrates the configuration data in the sysedgeV3.cf file in the upgraded directory into the new sysedgeV3.cf file in the data directory.
Note: The data directory stores the version of the sysedge.cf file used for runtime configuration changes.
The agent automatically makes the following changes to configuration file settings when upgrading from a previous release:
- The procAlive process monitor syntax has changed to adhere to the threshold process monitor syntax. The agent automatically converts any existing procAlive entries into the new format.
Note: For more information about the syntax for procAlive entries, see Process and Service Monitoring chapter.
- Disabling the no_process_sets and no_remoteshell_group parameters would allow critical access to the agent system with only an SNMP write community. Consequently, the agent does not migrate previous settings for those parameters and always enables them.
- The sysedge_memory parameter no longer exists and is removed in the upgraded sysedge.cf file. Outstanding alarms are now handled by storing the current state of any monitor in the sysedge.mon file. Existing entries are migrated to the new alarm handling configuration.
- The tc_publish parameter is renamed no_trapcommunity_table (with reverse logic) and is enabled by default.
- When you upgrade from SystemEDGE Release 4.3.4 to SystemEDGE Release 5.7.1 using Remote Deployment, the migrated monitors are stored in the sysedge.cf.bak file.
- Depending on your deployment strategy, you can use Policy Configuration to apply migrated monitors in your environment.
Note: For more information, see the CA Server Automation Bookshelf.
- When you upgrade from SystemEDGE Release 4.3.4 to SystemEDGE Release 5.7.1 on the local system, the installation program migrates monitors and provides them in the new configuration.
All previous syntax is compatible with the new version of the agent. However, many new options are available that enhance agent capabilities. We recommend that you examine older monitor entries and edit the syntax to contain additional options.
Note: When you upgrade SystemEDGE from Release 4.3.4 or above (4.3.x), the installer uses the following parameters only:
CASE_PUBDATADIR
CASE_MANAGER_HOSTNAME
CASE_MANAGER_POLICY_NAME
CASE_START_AFTER_INSTALL
CASE_LEGACY_MODE
CASE_SNMP_PORT
CASE_INSTALL_DOCS
CASE_SNMP_TRAP_COMMUNITY (1)
CASE_SNMP_TRAP_DESTINATION (1)
CASE_SNMP_TRAP_PORT (1)
CASE_SNMP_READ_COMMUNITY (1)
CASE_SNMP_WRITE_COMMUNITY (1)
CASE_SNMP_READ_ALLOWED_MANAGERS (1)
CASE_SNMP_WRITE_ALLOWED_MANAGERS (1)
Other parameters are ignored.
(1) These parameters are special. Their settings are appended to the existing SystemEDGE 4.x settings allowing both the SystemEDGE 4.x manager and SystemEDGE 5.x manager to function.
Copyright © 2013 CA.
All rights reserved.
|
|