CA Unified Infrastructure Management 9.2.0
As part of the regular release cycle for updating CA Unified Infrastructure Management (CA UIM), we are pleased to announce CA UIM 9.2.0. This release includes new and enhanced features, various vulnerability fixes, resolved customer issues, and so on.
As part of the regular release cycle for updating CA Unified Infrastructure Management (CA UIM), we are pleased to announce CA UIM 9.2.0. This release includes new and enhanced features, various vulnerability fixes, resolved customer issues, and so on.
New and Enhanced Features
The following features and enhancements have been included in 9.2.0:
Replacing Oracle JDK with OpenJDK
CA Technologies, a Broadcom Company, is moving towards adopting more open source technologies in its products. As a part of this strategy, various products have started using open-source implementations of Java. To align with this corporate direction, CA UIM 9.2.0 has adopted OpenJDK (8u212). This adoption results in the following changes:
- All previous releases of CA UIM except CA UIM 9.0.2 are no longer available on the Support archive. We recommend that you upgrade to CA UIM 9.2.0. However, if you do not want to upgrade and want to continue with your existing CA UIM setup, then it is recommended that you upgrade Oracle JDK to OpenJDK in your current setup.
- The CA UIM 9 SP1 (9.1.0) release that was using Oracle JDK has also been removed from the Support archive. All the functionality that was included in 9.1.0 is now released as part of CA UIM 9.2.0.
- Upgrading to CA UIM 9.2.0 Server automatically updates the existing Oracle JDK to OpenJDK (8u212) in the existing CA UIM environment. Additionally, this upgrade also deletes the older Oracle JDK instances.
- The java_jre probe has been updated to adopt OpenJDK (8u212). The new version 2.0 of the java_jre probe includes this OpenJDK implementation.
For more information about the OpenJDK adoption in CA UIM 9.2.0, see Adopting OpenJDK.
Secure Hub and Robot
Nowadays, any successful product demands a robust security mechanism to be in place to address ever-increasing threats. Moreover, with newer security issues coming up every day, organizations cannot ignore the focus on the continuous enhancement of their product's security. Understanding the importance of heightened security, CA UIM further enhances its security mechanism by securing
data in transitand allowing its customers to seamlessly move to secure hub and robot. Now, two types of hubs and robots are available—
non-secure. Beginning with this release, secure hub and robot are available, which further improve the security in CA UIM. Secure hub and robot provide robust hub-to-hub and robot-to-hub communication.
- Secure Hub and Robot Package Names:The secure hub and robot package names are as follows:
- hub_secure 9.20S
- robot_update_secure 9.20S
- Queue Attachment in Secure Environment:In a secure setup, CA UIM provides a dedicated thread for attaching to a queue. This helps ensure that a subscription from a secure robot to a queue on a secure hub has a dedicated thread for each subscription. Now, a dedicated thread pool is present for the attach queues. A thread from the pool is allocatedon demandfor the probes that want to subscribe to a queue present in its secure hub. If you want to specify the maximum number of threads, add the parameterproxy_wq_attach_max_threadsto the robot.cfg file.
- The secure bus controller proxy can handle multiple inbound and outbound requests. This implementation takes care of any performance issues. Two new parametersHandling Multiple Requests:proxy_wq_inbound_max_threadsandproxy_wq_outbound_max_threadsare now available. These parameters enable you to specify multiple threads in the controller proxy, thereby improving the performance. You can increase and decrease the number of inbound and outbound threads based on your requirements. You add these parameters to the controller section of the robot.cfg file. The maximum limit for these parameters is decided at run-time based on the number of the processor cores.
For more information about how to upgrade to secure hub and robot, see Secure Hub and Robot.
Removed License Dependency (Hub, Robot, Probes)
From CA UIM 9.2.0 onward, hub/robot- and probe-level licensing requirements have been removed. Deploy the hub, robot, and distsrv versions released with CA UIM 9.2.0 to remove the license dependency. With this change:
- The hub UI displays the license information as perpetual.
- The addition or deletion of license is no longer applicable.
- distsrv 9.20 has a dependency on the robot 9.20/9.20S.
- Take a backup of all the existing licenses before upgrading to CA UIM 9.2.0.
If you want to continue with the older versions of hub/robot and probes that require an extension of the license, contact Support so that they can assist you in extending the license (if required).
All the relevant sections in documentation have been updated with this information.
CA UIM 9.2.0 now provides the following enhancements in the security.cfg file:
- Uses a strong hashing algorithm PBKDF2 for password hashing.
- Encrypts user information (for example, email ID, phone, profile, permissions) of the users available in the file.
All support.nimsoft.com accounts have been migrated to use Broadcom authentication. To continue accessing support.nimsoft.com without any issue, follow the instructions outlined in the Accessing support.nimsoft.com article.
CA UIM 9.2.0 now supports the following platforms for the robot:
- SLES 12 SPx: CA UIM 9.2.0 can monitor systems on SLES 12 SP1 and higher SPs (such as SP4).
- Windows 2019: CA UIM 9.2.0 can monitor Windows 2019 systems.
- RHEL 7.x: CA UIM 9.2.0 can monitor systems on RHEL 7.1 and higher (such as 7.8).
Alarm Policy Enhancements
This release includes the following alarm policy-related enhancements:
- Monitor the state or performance metrics for a container group. This ability helps you add an alarm condition that is inherited down to all the underlying groups and devices, unless a user explicitly overrides it.
- Specify a priority for the alarm policy condition. This priority helps evaluate the metric condition for the alarm policy at the group level. The condition that has the highest priority is used for generating alarms on the device.
For more information, see Manage Alarms with Centralized Alarm Policies.
Telemetry Configuration for the PLA Model
For the Enterprise Software Portfolio License Agreement (PLA) customers, it is mandatory to upload the customer information and usage data to Segment, which is used for internal reporting purpose. The PLA customers can enable or disable the data collection using the wasp configuration.
For more information about configuring telemetry data for the PLA customers, see Configure Telemetry for the PLA Model.
The RESTMon probe now includes the Jackson library vulnerability fix. For more information about the RESTmon probe, see Monitor Technologies using RESTMon.
CABI Probe Deploys CABI JasperReports Server 7.1.1
The cabi probe 4.10 is updated to deploy CABI Server version 7.1.1. This version supports TLS-enabled database in CABI installation for Oracle (PKCS12 wallet) and MSSQL.
For more information, see CA Business Intelligence JasperReports Server with CA UIM Release Notes and CA Business Intelligence with CA UIM.
Operator Console Enhancements
The following enhancements have been made to the Operator Console in this release:
- Run a report immediately, schedule it to run later, or create ad-hoc reports. These enhancements give you more control over how you want to get deeper insight into your monitored infrastructure. For more information, see View Your Reports.
- Create and manage dynamic groups. This enhancement lets you create a dynamic group when you want to monitor specific devices that are discovered after a device discovery. For example, you want to monitor all database servers that belong to a specific region. For this, you can create a dynamic group for the region and can configure the group to accept only the database servers that are discovered during the device discovery. After the devices are discovered, those that match the dynamic group criteria get added to it. For more information, see Manage Groups in Infrastructure Management.
The CA Business Intelligence (CABI) Availability reports enable you to view the availability and reachability for the selected devices (cloud, virtual, and physical) and the groups containing them. Availability implies that a device's power is up and active. Reachability implies that a device is reachable through an ICMP ping. Maintenance implies the percent of time a device is under scheduled maintenance for the selected duration.
For more information, see Availability Reports in Probes Documentation Space.
CA UIM has fixed security issues where bad actors could use brute-force methods to guess your users' passwords and log in. Three new keys have been introduced (
account_lockout_threshold) that enable you to configure the account lock feature.
For more information, see
Configure Account Locksection in the wasp IM GUI Reference article.
This release includes the following performance improvements:
- Improved wasp start-up time:The wasp start-up time has been considerably reduced in this release when compared with the previous release.
- Improved Admin Console login performance:As part of this improvement, instead of displaying a blank page, actual template of Admin Console is displayed. Also, if there is any network latency issue, a spinner is displayed while fetching data. This helps users understand that Admin Console is working on getting the required data.
- The UMP performance has been improved in this release. A new configuration parameterImproved UMP performance (EMS Offloading):ems_offload_enabledis now available that you can add to wasp.cfg. This parameter enables UMP to bypass the ems probe and directly connect to the CA UIM database to fetch the alarms. This ability improves the UMP performance because UMP no longer goes through ems while getting the alarms data. To enable this functionality, set the parameter value totrueand restart the wasp probe; the default value isfalse. Note that all alarm actions still go through ems. In case of any issue after enablingems_offload_enabled, review the wasp.log file.
Addressed Jackson Vulnerabilities
This release of CA UIM addresses the Common Vulnerabilities and Exposures by updating the jackson-databind libraries. Jackson-databind is a Java library that is used to parse JSON and other data formats. The vulnerability occurs when the user input is improperly validated, which may allow an attacker to perform code execution by providing maliciously crafted input.
For more information, see Addressing Jackson Vulnerabilities.
Addressed Update Version Issue in IM
Using different names for the secure and non-secure hub and robot packages addresses the following update version issue in IM:
In Infrastructure Manager (IM), the
Update Versionoption always prompts you to update to the highest version number that is present in the archive. If the secure and non-secure hub and robot have the same package names, then the highest package version includes "S" (for example, 9.20S). Therefore, it prompts you to update to a secure version even when the version that you are updating is non-secure. For example, you want to update the non-secure robot (controller) version from 7.97 to 9.20. If you use
Update Version, you get the option to update to 9.20S (which is incorrect) instead of the correct 9.20. By using different names for the non-secure and secure packages, this issue does not occur, and you get the correct upgrade version.
Addressed Penetration Test Vulnerabilities
Fixed the following penetration test vulnerabilities:
- Fixed an issue where the remote service was supporting SSL/TLS ciphers that offered weak encryption because of 128-bit (or lower) strength.
- Fixed the issue related to access to resources without authentication. Some resources were accessible without any authentication. Information disclosed by these resources could help an attacker gather the information, which could facilitate intrusion.
Removed MCS Utilities Tool
The MCS Utilities Tool is no longer available on the web archive. It is superseded by mon_config_service_cli, which is available in the local archive.
CA UIM 9.2.0 High-Level Installation Process
This section provides a high-level 9.2.0 installation process that helps you quickly get started with this release.
- Before you start the process of installing CA UIM 9.2.0, ensure that your existing environment is using CA UIM 9.0.2.
- If you do not want to install the secure version of the packages currently, we recommend that you delete them from your archive. This helps you avoid situations where you inadvertently use the secure version instead of the non-secure one. If you need the secure versions at a later stage, you can recover them from the uimserverpackages.zip file that is downloaded as part of the 9.2.0 upgrade package.
- Plan whether you want to perform a secure upgrade or not.
- For the secure upgrade, review the secure architecture that is explained in the Secure Hub and Robot article.
- If you want to perform the secure upgrade:
- Ensure that all hubs are connected through tunnels and no direct connections are set up.
- Ensure all hub probes and controller on hubs are running version 7.96 or later.
- Run the 9.2.0 server installer.
- Select (or do not select) the secure option based on your decision.
- Update the robots on the UMP and the CABI computers to 9.20.
- If performing the secure upgrade:
- Deploy the UIMRobotCert package to the UMP robot and the CABI robot. For more information about UIMRobotCert, see Secure Hub and Robot.
- Update the robot version to the secure version.
- Run the UMP installer.
- Deploy the CABI 4.10 package to the CABI robot.
- Follow the required instructions for securing additional hubs, if you selected the secure option. For more information, see Secure Hub and Robot .Alternatively, you can also make your secondary hubs secure before upgrading UMP and CABI to a secure state. It depends on your requirements.
The following issues have been resolved as part of CA UIM 9.2.0:
- Fixed an issue where the time over threshold for bandwidth utilization was not waiting for the configured time. (Support Case: 01147010)
- Fixed an issue that was occurring when many alarms were getting generated (for example, 50k) and a user was changing the (Time over Threshold) ToT configuration. The fix now significantly improves performance. (Support Case: 01204522)
- (8.54 HF6) Fixed an issue in which ade was not deploying robots in mixed-mode authentication. ade uses Java Secure Channel (JSch), which is a third-party library. During runtime, in mixed-mode authentication, JSch was using password authentication implementation (with password as an empty string) instead of the key-based authentication password. This was causing the authentication failure errors. With this hotfix, the key was successfully authenticating with the Linux server in the mixed-mode authentication. (Support Case: 01169113)
- Fixed an issue in which users were facing issues when they were deploying CentOS robots through ade from a remote hub. They were trying to deploy the robots by using an API call to ade. (Support Case: 01281291)
- Fixed an issue in which robot deployments were failing when using the deployment_engine API for sudo access. (Support Case: 01135459)
- (9.02 HF1) Fixed an issue in which when users were trying to deploy robots with XML file by using a sudo account, they were getting an error. The error was stating that communication with the host was not possible, and it was prompting them to verify the user name and password. (Support Case: 01344939)
- (9.02 HF1) With this hotfix, the thread that reads the queue messages is blocked until baseline_engine's in-memory queue size reduces to a certain number. (Support Case: 01227531)
- (9.02 HF2) Fixed an issue in which when the queue subscription was failing, the subscription reference was getting set to NULL, which was later getting referenced without the NULL check. This was causing the NULL pointer exception and baseline_engine was getting restarted. This hotfix now adds the NULL check. (Support Case: 01248777)
- Fixed an issue where the baseline_engine probe was crashing when it failed to subscribe to the queue. (Support Cases: 01248777 and 01227531)
- Fixed an issue where the baseline_engine.QOS_MESSAGE and baseline_engine.BASELINE_CONFIG queues were stuck when many QoS messages were generated by the monitoring probes. (Support Case: 01227531)
- (9.02 HF3)
- Fixed an issue in the dashboard portlet where the dashboard that contains German umlaut, set as Default throws a message: "Not able to load Dashboard definitions in a red popup". (Support Case: 00877169)
- (9.02 HF1) Fixed an issue in which after you upgraded to 9.0.2 in an environment where the back-end database server was Microsoft SQL Server 2008 R2, data_engine was experiencing failures even though the upgrade appeared successful. The following message was getting logged in the data_engine log file:(2) ExecuteNoRecords [Microsoft OLE DB Provider for SQL Server] 'CONCAT' is not a recognized built-in function name.You can also review the related KB Article.
- (9.02 HF2) Fixed an issue in which when users were deleting a device through the USM and selecting to delete the measurements, the QoS data was not getting deleted. To resolve the issue, this hotfix has reintroduced the probe utility (pu) command delete_qos in data_engine. This command was inadvertently removed from the product. (Support Case: 01222421)
- (9.02 HF3) Resolved the following issues:
- Fixed an issue in which data_engine was getting into a restart loop when a QoS was failing to insert. This was increasing the data_engine queue size. To resolve this issue, two parameters have been introduced: Continue_on_insert_fail and Ignore_errors_list. With these parameters, when any insert fails, data_engine checks whether Continue_on_insert_fail is set to 1 and Ignore_errors_list includes list of error messages that can be ignored. If these two conditions are met, data_engine continues with the insert. The default value of Continue_on_insert_fail is 1 and of Ignore_errors_list is “Invalid character value for cast specification | Unspecified error”. This hotfix is applicable when Microsoft SQL Server is used as the CA UIM database. (Support Cases: 01209184, 01236477, and 01276828)
- Fixed an issue in which data_engine was failing to insert QoS data into the database. This hotfix is more resilient to handle corrupt QoS messages. (Support Case: 01275045)
- Fixed an issue in which after enabling the data_engine maintenance, it was purging all the old data. (Support Case: 01331245)
- Fixed an issue where the following message was appearing in the Infrastructure Manager console. This message had no impact on the functionality and data_engine was working fine. (Support Cases: 01265179 and 01241208)NIS Data Engine: /***domain/***hub/***/data_engine - 11/19/18 19:55:51 - InformationDatabase error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified - 11/19/18 19:55:52 - ErrorDB operation failed - 11/19/18 19:55:52 - ErrorUnable to connect to NIS Database - 11/19/18 19:55:52 - WarningNo valid connection with NIS Database - 11/19/18 19:55:52 - Warning
- Fixed an issue in which the snmpcollector probe was not storing data. This issue was resolved when the data_management_partition value was set to yes in the data_engine.cfg file. (Support Case: 01354166)
- Resolved an issue in which the data_engine probe was not purging the old data because of the data_engine schedule setting was configured incorrectly. (Support Case: 01360960)
- Fixed an issue in which data_engine alarms were failing to insert qos_data. The alarm (Insert bulk failed due to a schema change of the target table) was not honoring the alarm-severity configuration. This issue has been resolved by making updates so that the error condition is handled properly. (Support Case: 01355478)
- Fixed an issue in which QoS was not showing up for any device. To resolve this issue, insert and data partitioning have been synchronized so that no two events happen simultaneously on the same table. (Support Case: 1369585)
- Fixed an issue in which when users were trying to query the summarized QOS data in HN_ and DN_ tables, they were noticing that the data was partial or was missing for many CIs. (Support Case: 01254029)
- Fixed an issue in which users were getting the following error (alarm) after every 10 minutes: (Support Case: 01293953)[Microsoft SQL Server Native Client 11.0] TCP Provider: An existing connection was forcibly closed by the remote host. Failed to insert QoS data into the database, check that the database is running.
- Fixed an issue in which users were facing some import metric error in the discovery log. (Support Case: 01200697)
- (8.52 HF1) Fixed an issue in which users were observing device count fluctuation in automatic inventory and a few groups in UMP. (Support Cases: 01297434 and 00966713)
- (9.02 HF2)
- (8.52 HF2) Fixed an issue in which discovery was not validating certain SNMPv3 devices that were using AES256 encryption. (Support Case: 01271190)
- Fixed an issue in which devicetype was showing differently in the USM inventory view and in the details view. (Support Case: 01227594)
- (9.02 HF1) Fixed an issue in which when users were changing the alias for an interface, USM was not reflecting the changed value. However, the change was getting updated in the database. (Support Case: 01275050)
- (7.93 HF11_1) Fixed an issue in which the package copy functionality was not working for Linux. (Support Case: 01245994)
- (7.97 HF1) Fixed an issue in which CA UIM was not downloading the packages into the archive. It was showing the download status as complete, without any errors. However, the package was not showing up in the archive. (Support Case: 01239612)
- (7.97 HF4)
- Fixed an issue in which users were observing memory/handle leak when they upgraded their hubs to v7.97. (Support Case: 01351562)
- Fixed an issue in which the active emailgtw probe was restarting the hub probe intermittently. (Support Case: 01317795)
- (7.93 HF15) Fixed an issue in which alarms that were coming from a robot with no user tag were using the user tag that was specified in the primary hub's configuration. This was giving incorrect information as messages that were not supposed to be processed were also getting processed because of the presence of the user tag that is used from the hub. To resolve this issue, a new configuration parameter (add_hub_user_tags_to_raw_data) has been introduced so that you can add user tags to the message only when you need. This parameter is added to the hub.cfg file. By default, this parameter is disabled (0). (Support Case: 01158176)
- Fixed an issue in which hub was becoming unresponsive whenever users were trying to restart or shut it down. (Support Case: 01353424)
- (7.93 HF16) Fixed an issue in which the hub spooler was not responding when the sysloggtw probe was sending a large amount of data and the error was of the type wsaewouldblock. To resolve this issue, a new parametersock_write_retry_counthas been introduced. This parameter lets you specify the number of tries the hub spooler must consider before it stops sending the message. Add this parameter to the hub section of the hub.cfg file. (Support Case: 01116951)
- Fixed an issue in which the hub probe callback (hubsec_list) was not working with the pu utility. (Support Case: 01203568)
- Fixed an issue in which LDAP server was not allowing special characters in the password field. (Support Cases: 00832861 and 00907941)
- Fixed an issue in which the processes hub.exe and data_engine.exe were using a lot of port connections, which was resulting into the unavailability of the primary hub. (Support Case: 01347775)
- Fixed an issue in which hub 7.96 was frequently going into an unresponsive state. (Support Case: 01278227)
- Fixed an issue in which after upgrading to CA UIM 9.0.2, LDAP with SSL was no longer working. (Support Cases: 20009332 and 20015915)
- Fixed an issue in which when users were trying to create a tunnel server, using Infrastructure Manager on the secondary hub, the hub configuration window was not starting. Therefore, users could not configure the tunnel server using IM on CA UIM 9.0.2. (Support Case: 01258814)
- (7.97 HF3 and 7.93 HF17) These hotfixes resolve the following issues:
- Fixed an issue in which some hubs were being displayed as red in IM; however, when users clicked them, they were immediately getting displayed as green. This was creating a false sense of problem with users spending unnecessary time on trying to investigate the problem. (Support Case: 01220272)
- Fixed an issue in which the QOS_POWER_STATE metric had missing values in the RN_QOS_DATA table. For example, the QoS interval of the power state metric was 5 minutes. So, for 24-hours window, the expectation was to collect 288 (24*12) metrics. However, only 280 records were added to the RN_QOS_DATA table. This was affecting the availability calculation. (Support case 01304869)
- Fixed an issue in which after tunnel implementation, hubs were going red in IM and AC sporadically. And, when clicked, they started recovering. (Support Case: 01195957)
- Fixed an issue in which after upgrading from CA UIM 8.5.1 to CA UIM 9.0.2, the hub probe was not responding continuously. The following error message was getting displayed: (Support Case: 01261471)kernel: hub: segfault at 20 ip 00007a36601a sp 00007f7fdcc8 error 4 in libc-2.17.so[7fa228000+1c2000]
- Fixed an issue in which users were getting the following error, and the primary hub was repeatedly creating temporary connections: (Support Case: 01161603)The Hub <hub_name> has too many active subscribers (<count>). You should consider offloading some of the subscribers to another Hub.
- Fixed an issue in which a user was facing problems with security settings in the primary hub. After upgrading to CA UIM 9.0.2, the user could not see remote hubs in IM. (Support Case: 01279980)
- Fixed an issue in which users were facing communication issues between hubs in their environment. (Support Case: 00803845)
- (7.95 HF1) Introduced a new configuration parametervalidate_ip_suggestionto process the robotip field in the answer file. When you set the validate_ip_suggestion parameter value to 1, the parameter correctly finds the IP (from the list of IPs specified in the robotip field) that matches the computer IP. When you enable this parameter, you must disable the local_ip_validation parameter. The following issues have been fixed with this update:
- Robot IP was not working in the answer file. (Support Case: 01189561)
- The installer was not adding new configuration parameters on Linux and AIX. (Support Cases: 01221346 and 01221360)
- All nimsoft utilities were failing when strict_ip_binding was set to TRUE. (Support Case: 01242592)
- The controller was not handling the robotip value greater than 128 characters. The value of the robotip parameter must not be higher than 2048 characters. (Support Case: 01263533)
- Fixed an issue in which the emailgtw probe was restarting the hub probe. The emailgtw probe was configured and deployed on the primary hub to send emails with alarms from nas (AO). The emails were going to the recipients defined on AO. However, because the emailgtw probe was active, the hub probe was restarting frequently. If the emailgtw probe was deactivated, the restarts were stopping. (Support Case: 01317795)
- Fixed an issue in which hub 7.97 could not connect to hub 7.80 with tunnels. (Support Case: 01311594)
- (7.93 HF16) Fixed an issue in which the robot spooler was not responding when the sysloggtw probe was sending a large amount of data and the error was of the type wsaewouldblock. To resolve this issue, a new parametersock_write_retry_counthas been introduced. This parameter lets you specify the number of tries the robot spooler must consider before it stops sending the message. Add this parameter to the spooler.cfg file. (Support Case: 01243127)
- (7.97 HF1) Fixed an issue in which plugin_metric was not collecting metrics for the probes (which had new profiles created) unless the robot was restarted. This issue has been fixed with this hotfix.
- (7.97 HF3) Fixed an issue in which alarm policies information was not getting added to the plugin_metric.cfg file on some robots. This was creating issues as alarms were not getting generated from these devices when the monitored metrics were exceeding the configured alarm policy thresholds.
- Fixed an issue in which high memory usage was observed on the controller process after robot was upgraded from 7.93 to 7.97.
- Fixed an issue in which deploying robot 7.97 on top of 7.93 was not updating the version in the controller UI status dialog. (Support Case: 01350012)
- Fixed an issue in which duplicate device entries were existing for the same device in the UMP portlet. (Support Case: 00889072)
- Fixed an issue in which the UMP upgrade was failing. (Support Case: 01369904)
- Fixed an issue in which Admin Console was not installing the dependent package and the deployment was failing immediately. The same deployment was completed successfully if done through IM. (Support Case: 00852608 and 1261671)
- Fixed an issue in which TOT alarms were not working as expected. For example, with thresholds set at 85% for major and 90% for critical alarms, the alarms were generating for less CPU utilization. (Support Cases: 01269944, 01260949, 01269925, 01287039, 01290918, 01293428, and 01303742)
- (7.93 HF10) This hotfix supports robot on Ubuntu 18.04 on x86_64 platform. (Support Case: 01242463)
- Fixed an issue in which robot was not starting and rebooting on an AIX computer. (Support Case: 01187252)
- Fixed an issue in which when a robot was unable to find a valid IP address in robot.cfg or DNS, it was taking the loopback address. This was disrupting communication. This issue has been resolved in this release. To resolve this issue, two configurable parameters have been added to robot.cfg: (Support Case: 01219460)
- max_retry_IfLoopBack_attempt Specifies the maximum number of retries that controller can use to find the system IP address. In the case of loopback IP address, if robot_ip is not configured in robot.cfg, then controller tries to get the system IP. It tries to find the IP address for the number of retries that are specified in the parameter. After trying for the specified count, controller starts again with the loopback IP, resulting in the same initial behavior. The default value is 10.
- sleep_btwRetry_IfLoopBack_attempt Specifies the maximum interval for which controller waits before trying again for the subsequent attempt. The default value is 2 seconds.
- Fixed an issue in which users were facing problems with UIM Robot RPM and included systemd unit files. (Support Case: 00913690)
- (7.93 HF18) Fixed an issue in which recently upgraded robots were giving problems on the AIX computers. When users upgraded robots on AIX systems, most robots worked except those that were connecting to an Oracle database. When the upgrade was performed, the robot.cfg file was updated and the LIBPATH value was changed. This hotfix preserves the existing value in LIBPATH when updating a robot using robot_update. (Support Case: 01185299)
- Fixed an issue in which users installed robot on Windows Server 2012 R2 and applied MCS profiles for CPU, Memory, and Disk profile. They were getting some disk and CPU metrics, but no memory metrics. (Support Case: 01249736)
- Fixed an issue in which snmpcollector was not getting launched from Admin Console. This issue was happening because controller was not reachable sometimes. (Support Case: 01307099)
- Fixed an issue in which users were not able to install robot through rpm because it was using the default value (that is, /opt/nimsoft). The command was installing the robot in the correct location /opt/CA/nimsoft; however, it was not updating this file with the correct file path /usr/lib/systemd/system/nimbus. The robot would not start until the path in this file was updated to /opt/CA/nimsoft. The file had /opt/nimsoft. (Support Case: 01347207)
- Fixed an issue in which after upgrading robots, the spooler probe was failing to send the messages after the hub restart. (Support Case: 01306288)
- Fixed an issue in which when users were trying to install robot/hub on CentOS 6.8 using nimldr (from CA UIM 9.0.2) installation, the installation was failing with an error message. (Support Case: 01332537)
- (8.51 HF1) Fixed an issue in which when users were trying to configure the application discovery, they were receiving this error: (Support Case: 01292813)An unknown error has occurred.Refreshing your browser may resolve the issue.Details:com.firehunter.ump.exceptions.DataFactoryException : Failed to create group null: PreparedStatementCallback; SQL [select * from SSRV2Template where templateName = ? order by production desc, version desc]; The column name mon_agent_resolution is not valid.; nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: The column name mon_agent_resolution is not valid.This issue was occurring because the product was looking for a non-existent column mon_agent_resolution in the table SSRV2Template. This hotfix has resolved the issue.
- (9.00 HF1) Fixed an issue in which an inherited group profile for a device was getting deleted and then getting added again. This was happening because the nis_server probe was deleting entries in the cm_group_member table and then re-inserting them back into the table. This was causing the fluctuation in the count of devices under the USM groups. Because of this, MCS was reprocessing the devices, deleting the profile and then inserting, which was causing the loss of configuration for overridden group profiles. With this fix, nis_server does not update the cm_group_member table. The deletion and re-insertion of entries in the cm_group_member table is avoided as a part of this fix. (Support Case: 01269195)
- Fixed an issue in which the maintenance schedules in USM were not appearing as expected. Sometimes, they were not showing up, and then they would randomly show up without doing anything. (Support Case: 01236634)
- Fixed an issue in which the maintenance_mode probe version 9.02 package was not available in Nimsoft archive. (Support Case: 01294815)
- Fixed an issue in which USM performance issues were occurring because of the growth of the maintenance_window table. The maintenance_window table was growing excessively and when there were more than 2000 rows in it, USM performance was getting affected. (Support Case: 01184935)
- Fixed an issue in which after upgrading to CA UIM 9.0.2, users started viewing various errors in the maintenance_mode log and the CPU usage also was very high. (Support Case: 01302475)
- (9.02 HF1) With this hotfix, while loading probe templates available in a probe templates package, MCS ignores those templates that have the same version already present in the database; it proceeds with the loading of the remaining templates. Previously, if MCS found any template with the same version already present in the database, MCS was putting the complete probe templates package in the error state, and it was not loading the remaining templates. (Support Case: 01257258)
- (9.10 HF1 and 9.02 HF6) Fixed an issue in which configuration values were not getting updated after the creation of a profile at a group level. When users were selecting the "Blank" operator during the profile creation at the group level, the default value (>) was getting overridden with the blank value at the device profile, and because of that, alarms were getting generated. (Support Case: 01333132)
- (9.02 HF2) Fixed an issue in which the database size was growing exponentially after users were configuring MCS enhanced profiles in a 9.0.2 environment. This hotfix removes the unnecessary entries from the SSRV2AuditTrailModification table, which was resulting in an increase of the database size. This hotfix also deletes invalid robots. (Support Case: 01272939)
- (9.02 HF4) Fixed an issue in which the MCS probe was not responding after upgrading from 8.5.1 to 9.0.2. (Support Case: 01305660)
- (9.02 HF4) Fixed an issue in which when trying to import an MCS profile (created from a legacy CPU Monitor profile) to a device using the MCS CLI profile-import utility and an XML file successfully generated with the profile-export utility, the command was failing with an HTTP <500> error. This hotfix resolves the error that was occurring while importing the profiles using the MCS CLI import utility. For the import of group profiles, the profile must exist in the database prior to importing the profile. (Support Case: 01300195)
- Fixed an issue in which users were facing issues when they were trying to create a group for each operating system and configuring the monitoring at the group level to apply to all hosts added to that group. (Support Case: 01293948)
- Fixed an issue in which Disk(s) (Enhanced) profiles were not getting removed from the plugin_metric.cfg file. This was resulting into the collection of unwanted metrics. (Support Case: 01315297)
- Fixed an issue in which removing a system from a group was not removing the MCS profile configuration. (Support Case: 01283081)
- Fixed an issue in which alarm policies were not loading in Operator Console in a load-balanced environment. When users were clicking Setup Wizard, Alarm Policies in Operator Console, it was displaying a spinner icon that was not going away. (Support Case: 20001936)
- (8.58 HF12) Fixed an issue in which adding a disk profile at the computer level was not working. Only the group level was working. (Support Cases: 01215107, 01145389, and 01215106)
- (8.58 HF14) Fixed an issue in which the status of many devices was getting modified frequently. This was causing MCS to reprocess those devices unnecessarily, which was leading to performance issues. This hotfix restricts MCS to process invalid robots. With this hotfix, it is recommended (not mandatory) to deploy the nis_server 9.00 HF1 hotfix. (Support Case: 01279316)
- Fixed an issue in which users were not able to add monitoring to new devices that were added to an existing monitoring group. (Support Case: 01201223)
- Fixed an issue in which migration for the cdm templates was not working in MCS. (Support Case: 01189527)
- Fixed an issue in which users were facing problems while resolving profiles marked with a red cross in MCS. (Support Case: 01113379)
- Fixed an issue in which MCS was trying to deploy the Default Disk and Disks templates in the order they were created and not based on the parent-child hierarchy. Default Disk was the parent and Disk was the child. Therefore, the parent (Default Disk) must be deployed first and then the child (Disk). With this fix, the sorting mechanism in MCS has been updated, which identifies and deploys the parent template first and then the related child template. (Support Case: 01212987)
- Fixed an issue in which MCS was unable to configure probes and was also causing performance issues. (Support Case: 01108371)
- (9.02 HF5) This hotfix resolves the error that was occurring while importing the profiles using the MCS CLI import utility. For the import of group profiles, the profile must exist in the database prior to importing the profile. The mon_config_service_ws.zip file is included as part of this hotfix. (Support Case: 01300195)
- Fixed an issue in which MCS profile was not creating the net_connect profile for remote devices. (Support Case: 01283601)
- Fixed an issue in which users were able to create child profiles under a legacy MCS profile that had been converted into an enhanced profile. With this fix, the + option is no longer available for a legacy profile that has been converted to an enhanced profile. (Support Case: 01316154)
- (9.06 HF1) Fixed an issue in which the Time over Threshold (ToT) setting was not waiting for the configured time. This hotfix has a dependency on the Microsoft Visual C++ Redistributable for Visual Studio 2017 package. Ensure that you deploy this 2017 package before you apply the hotfix. (Support Case: 01147010)
- Fixed an issue in which when users upgraded to nas 9.06, all rules started ignoring the setting 'on overdue age' and were triggering an email escalation on every alarm_update. The rules were completely ignoring the time and action mode and were acting after the first escalation trigger like they were set to 'on message arrival'. This issue was occurring because of the user tags getting updated whenever an alarm was getting updated. To resolve this issue, a new key "update_user_tag" has been created. By default, the value is set to yes. If you do not want user tags to update, you can set this key to no. (Support Case: 01295478)
- Fixed an issue in which alarms were getting out-of-sync between IM and UMP. (Support Case: 01260495)
- Fixed an issue in which users were observing that alarms were not getting updated in USM. To resolve this issue, a new fieldSliding Windowis added to theRule: <Name>dialog. This field has been added to a pre-processing rule that users can set to ignore alarms for a time decided by them (based on the last updated time). The value in the sliding windows helps as follows: When an alarm comes, nas checks whether this alarm is in the exclude filter. If the alarm satisfies the exclude rule, the following processing happens:
- nas gets the value of the sliding window from the filter.
- nas gets the last received time for the alarm from the embedded database.
- nas adds these two values and verifies whether the added value is higher than the current time. If it is higher, it ignores that alarm; otherwise, it sends the alarm.
- If you do not select any severity level, the exclude rule allows only one alarm per sliding window to pass.
- If you select all severity levels, the exclude rule allows only one alarm per sliding window to pass.
- If you select some severity levels, this filter works when the selected severity level is reached. For example, consider a scenario where you select the critical severity with the sliding window value as 2 minutes. Now, if five major alarms come, the count goes up to 5. Then, if a critical alarm comes within 2 minutes of the last major alarm, the critical alarm is ignored. Furthermore, if another major alarm comes again, the count goes up to 6. (Support Case: 01104899)
- Fixed an issue in which the nas Auto-Operator profile was getting executed for suppressed alerts. (Support Case: 01335341)
- Fixed an issue in which alarm enrichment rules were not working after upgrading to CA UIM 9.0.2. (Support Case: 01365935)
- Fixed an issue where users were facing problems while configuring the nas probe name services. They were not able to save any modifications. (Support Case: 01290363)
- Fixed an issue in which users created an Auto-Operator profile using the action type as email and added a trigger to that AO profile. The email was getting sent; however, the alarm details were not present in the email. Only the subject/message body that was defined in the Auto-Operator rule was being sent. For more information, see the related KB Article. (Support Case: 01251919)
- Fixed an issue in which Auto-Operator profiles that had "scheduled profiles" attached to them were blocking execution of all other Auto-Operator profiles. (Support Case: 01313824)
- Fixed an issue in which alarm enrichment that required altering the suppression keys for alarms was not working as expected even after configuration. (Support Case: 01349637)
- Fixed an issue in which users were facing problems while trying to configure the nas probe Names Services. In the Address Table, after any type of modification to a name, when they clicked OK, it was not saving the changes. (Support Case: 01290363)
- Fixed an issue in which nas was issuing multiple requests to the maintenance_mode probe at the startup. This issue has been resolved by introducing a nas raw configuration parametermaint_start_window_in_minutes. This parameter helps avoid multiple requests to the maintenance_mode probe. This parameter changes the proposed startup time of the maintenance window by ensuring that it starts x minutes from the time nas starts. So, if any alarm with alarmtime older than the time nas starts comes into this window, then the request to maintenance_mode probe is not prompted. (Support Case: 01308974)
- Fixed an issue where users were receiving deadlock errors in the nas probe. This was causing uncertainty over whether all alarms were getting processed. (Support Case: 01300963)
- (9.06 HF6) Fixed an issue in which the directory path of the nas AO profile scripts was getting displayed incorrectly. This issue was purely related to the GUI display. (Support Cases: 01343764 and 01344935)
- Fixed an issue in which the nas probe was frequently becoming unresponsive mode. This was happening when users were creating pre-processing rules to suppress alarms during patching. (Support Case: 01317848)
- (9.06 HF7) Fixed an issue in which changes in the message field of the alarm were not updating properly in UMP. They were, however, working correctly in IM. (Support Case: 01276841)
- Fixed an issue in which alarm enrichment queue was getting stuck and was delivering delayed alarms. (Support Case: 01342078)
- (9.06 HF3) This hotfix fixes the following issues:
- Fixed an issue in which a test alarm that was sent as critical was getting created as informational instead of critical. (Support Case: 01277944)
- Fixed an issue in which, in the nas UI, the status of the alarm can now be stored based on the date, which was not working correctly. (Support Case: 01183090)
- Created a key to update the time arrival/suppression when you sync with the CA UIM database. (Support Case: 01149554)
- In UTF8 environment, when the message size is getting more than 4000, the message now gets trimmed to 4000 and gets uploaded to the database. The last four characters in 4000 are replaced with spaces. (Support Case: 01295478)
- Fixed an issue that was occurring when many alarms were getting generated (for example, 50k) and a user was changing the (Time over Threshold) ToT configuration. The fix now significantly improves performance. (Support Case: 01204522)
- Fixed an issue in which the ToT was configured and the ToT window and sliding window were the same. Now, if a QoS arrived after a second later, it was not getting considered for the ToT window. This fix changes the configuration so that the QoS can be part of the sliding window, as the QoS for any probe is not collected before 30 seconds. This fixes the issue for all probes where ToT window was getting missed. (Support Case: 01147010)You need to download vs2017_vcredist_x64, if OS is 64 bit or vs2017_vcredist_x86, if OS is 32-bit from the web Archive into the local archive.
- Fixed an issue where random alarms were getting past the maintenance mode. (Support Case: 00919393)
- Fixed an issue in which the NAS sqlite and NIS database were getting out of sync. (Support Case: 01197051)
- Fixed an issue in which when adding Auto-Operator and applying the configuration, the application error event was occurring at startup. (Support Case: 00340967)
- Perl SDK: (5.10 HF1) Fixed an issue in which the process of attaching to a queue and subscribing to messages by using Perl SDK was not working. (Support Case: 01213351)
- Java SDK:
- Fixed an issue in which users were receiving a ppm probe error when they were trying to save monitors in the sql_server probe. (Support Case: 01214959)
- Fixed an issue in which when users were setting up Oracle TLS on an existing CA UIM 9.0.2 environment, only data_engine was connecting and inserting data. All other probes that usually connect to the database were stopping after a few failed attempts to communicate with the database. (Support Case: 01280694)
- C SDK: Fixed an issue in which Infrastructure Manager (IM) was getting very slow after upgrading CA UIM. (Support Case: 01357106)
- Fixed an issue in which the prediction_engine probe was getting stuck, running out of memory, or not processing for some reason. This was creating a large backup of queued messages at the hub, which was causing the probe to be unresponsive. It kept on reading those messages and was running out of memory. (Support Case: 1338322)
- (10.20 HF1) Fixed an issue in which USM pages, reports, and dashboards were slow after upgrading to 9.0.2. (Support Case: 01234697)
- (10.20 HF2) Fixed an issue in which the ems probe was not starting after upgrading to 9.0.2 in an HA environment. An additional property (ha_address) is now available in the ems probe to configure the secondary hub address where HA is deployed. Therefore, to apply the hotfix, deactivate ems, deploy the hotfix, start ems, update the HA address in the ha_address parameter, and restart ems. (Support Case: 01243139)
- Fixed an issue in which ems on the primary hub was failing to start when the HA probe 1.45 was active on the secondary hub. (Support Case: 01237349)
- (10.21 HF1)
- Fixed an issue in which the connection time-out was happening with the maintenance_mode probe registration. Now, users can use themaintenance_mode_cmd_timeoutproperty in the ems.cfg file to increase the connection time-out value. The default value is 15000 ms.
- Fixed an issue in which users were receiving the following error:EMSRestartException: Data Store Open Failed
- Fixed an issue in which the ems probe was becoming unresponsive and USM was failing to load. (Support Case: 01331760)
- (10.20 HF3) This hotfix provides the following fixes and enhancements:
- Fixed an issue in which UMP was not loading alarms and was staying in the loading state. (Support Case: 01280212)
- Fixed an issue in which alarms were not getting forwarded from CA UIM to CA Spectrum. (Support Case: 01280212)
- Made maximum active connections (max_active_pool_connections) and idle database connections (max_idle_pool_connections) parameters configurable. (Support Case: 01280212)
- Upgraded Apache commons-pool2 and commons-dbcp2 to the 2.6.0 versions to resolve the memory leak issues in the library. (Support Case: 01280212)
- Enhanced the ems logging to check the number of database connections the probe is using. (Support Case: 01280212)
- Printing thread ID in the ems logs to capture the stack trace of each request. (Support Case: 01280212)
- Printing alarm IDs of alarms that are returned to CA Spectrum during the incremental sync. (Support Case: 01280212)
- Fixed an issue in which users were getting read time-out with the maintenance_mode probe. To resolve this issue, the maintenance_mode_cmd_timeout value in the ems configuration was increased to 180000 ms. (Support Case: 01245017)This hotfix is not applicable on 8.5.1 if it is using the Microsoft SQL Server database and the Windows authentication mode for authentication.
- (10.18 HF2) Fixed an issue in which the Alarm Console was not updating alarms. The ems probe was also stopping after some time. (Support Case: 01151288)
- Resolved an issue where the ems probe was not working. The probe was restarting itself once a minute, getting a new PID, not getting a port, and then creating a 250 MB MDUMP file. (Support Case: 01305917)
- Fixed an issue where the CA UIM Server installer could not test the database connection when the installation was on Windows 2016 and the database was Microsoft SQL 2016. Additional security settings were needed to be enabled on the database computer. In this case, the server authentication mode needed to be enabled for Microsoft SQL Server and Windows Authentication. (Support case 01304381)
- Fixed the following security and vulnerability issues. (Support Case 01216567)
- The Apache JServ Protocol (AJP) service could be mis-configured and could lead to access to internal resources. Access is now restricted to this service on production systems.
- Development configuration files did not have restricted access, which could have led to exposing sensitive information. All configuration files accessible from the Internet are now restricted.
- The server was vulnerable to slow HTTP Denial of Service (DoS) attacks.
- The server did not return an X-Frame-Options header, which could have led to the portal being at risk of a click-jacking attack. The web server now includes an X-Frame-Options header.
- Fixed an issue by providing support for cross origin resource sharing (CORS) in the REST webservices. (Support Case: 01323135)
- Fixed a potential clickjacking vulnerability (also known as a User Interface redress attack) in Admin Console. (Support Case: 01372889)
- Fixed an issue in which users were unable to upload cabi 3.4.0 from CA UIM 9.0.2 into the local archive. It was failing with the following error: "Import Failed. File size too long" (Support Case: 01326188)
- Addressed an issue in which while trying to access thehttps://<ump>/image/andhttps://<ump>/documents/URLs, the HTTP ERROR 403 error was displaying. To address this issue, add theweb.server.servlet.directory.indexing.enabled=trueparameter to the<Nimsoft>\probes\service\wasp\webapps\ROOT\WEB-INF\classes\portal-ext.propertiesfile. Then, restart the wasp probe. After implementing this step, you can view the two URLs.
- Fixed an issue where after upgrading to UMP 9.0.2, the menu items Add Page, Portlet, and Signout were missing. The portlet permissions were missing for this user role and hence the controls were missing. (Support Case 01302511)
- (9.04 HF3) Fixed an issue in which while editing a maintenance schedule in UMP, users were receiving the following error. Even refreshing the browser did not solve the issue. This issue started occurring after users upgraded from CA UIM 8.51 to CA UIM 9.0.2: (Support Case: 01324224)An unknown error has occurred.Refreshing your browser may resolve the issue.
- (9.04 HF1) Fixed an issue in which UMP was becoming unresponsive when users were clicking a device in the left navigation tree, the right pane was showing Retrieving Data, which was making all the buttons non-functional. (Support Case: 01364799)
- Fixed a performance issue in which UMP no longer interacts with ems to display alarms. It now directly interacts with the CA UIM database to get the alarms data. This significantly improves the UMP performance.
- Fixed an issue where you could not view the Performance Reports Designer data after adding it in a new page. (Support Case 01294911)
- Fixed an issue in which debug information (for example, configuration settings) were getting exposed in UMP. (Support Case: 01010815)
- Fixed performance issues related to the metrics data in the Portal, Unified Service Manager, Details section. When using the snmpcollector, the probe was responding slowly and did not retrieve data. (Support Case 01175919)
- Fixed an issue with UMP dashboards where the SQL table with URL links does not open some of the links. (Support Case 01212526)
- Fixed an issue with the UMP dashboard chart where the pop-up text for any value was hidden beyond the browser window. (Support Case 01227652)
- Fixed an issue in which QoS Data in RN and HN tables was not getting deleted when deleting a data object through the SLM portlet in CA UIM 9.0.2. (Support Case: 01308296)
- Fixed an issue in which USM server pages could not display the data for some VM robots. This issue was specific to VM robots. When clicked on a robot device Details tab, the metrics was not loading. (Support Case: 01332364)
- Fixed a vulnerability issue in the UMP portal that could display Apache Tomcat information, which could have caused a potential security risk. (Support Case: 01366714)
- Fixed an issue where only the administrator user could view groups (like "Application and Server" or "Big Data" and so on) in the Unified Dashboards menu. (Support Case: 01331450)
- Fixed an issue in which UMP was not loading. And, even when it was loading, it was creating problems with the processing of alarms. (Support Case: 20012032)
- Fixed an issue in which updated alarm messages were not showing up in UMP. Users created a pre-process in the nas probe, which added the robotname at the beginning of each alarm message. This was, however, working fine in IM. But, when they verified in UMP, they could not see any update. (Support Case: 20002326 and 20002326)
- Fixed an issue in which the UMP interface was not responding properly. For example, when a user enabled the vmware QoS metrics, the UMP interface became unresponsive. (Support Case: 01357572)
- Fixed an issue in which newly created groups and containers were disappearing from USM after refreshing the browser. (Support Case: 01300020)
- Fixed an issue in which after upgrading from CA UIM 9.0.2, the Dashboard portlet stopped working. It was trying to load for some time and then was getting timed-out. (Support Cases: 20005479 and 20007511)
- Fixed an issue in which users were not able to add groups from USM (Actions, Add to Group). (Support Case: 01267505)
- Fixed a potential security vulnerability on UMP where contents of the file or directory could disclose sensitive information. (Support Case: 01368951)
- Fixed an issue in which List Designer was not working properly when UMP 9.02 was upgraded to 9.02 HF2. (Support Case: 01349236)
- Resolved an issue in which users were unable to create group-level MCS profiles in UMP. (Support Case: 01351497)
- Fixed an issue with the SLA Report where parts of the header and the percentage were not configurable. (Support Case 01225579)
- Fixed an issue where the ump.disallow.simultaneous.logins=true option in the portal-ext.properties file was not working as expected. (Support Case 01190477)
- Fixed an issue in which the UMP/USM was constantly sending the following error message: (Support Case: 1322336)error com.firehunter.ump.exceptions.DataFactoryException : java.lang.RuntimeException: (120) Callback error, Received status (120) on response (for sendRcv) for cmd = 'dispatcher'
- Fixed an issue with the List Viewer and List Designer which did not work as expected after upgrading from version 8.5.1 to 9.0.2. (Support Case 01248140)
- Fixed an issue with the Unified Dashboards, Application, and Server reports did not work as expected after upgrading to 9.0.2. (Support case 01240355)
- Fixed an issue where the Unified Dashboard Server List Reports did not work as expected. Users were not able to modify the List Design. (Support Case 01261246)
- Fixed an issue where the Unified Dashboards did not display the required metrics after upgrading from version 8.5.1 to 9.0.2. (Support Case 01268381)
- Fixed an issue where CABI did not log in automatically from the UMP when you selected CABI Home. (Support Case 1292027)
- Fixed an issue where you could not open the Summary Dashboard in UMP after upgrading to UMP 9.0.2 HF1. (Support Case 01290817)
- Fixed an issue in which users were noticing the following warning on the console: (Support Case: 01269678)Significant clock differences between your client, the UMP server and the database can result in less accurate metric and alarm reporting.
- Fixed an issue where visual artifacts were observed on the Details tab in the USM after applying the ump_usm 8.5.2 HF16 hotfix. (Support Case 01268917)
- Fixed an issue where no metrics were displayed for Unified Dashboards VMWare Host Disk Summary and VMWare Guest Disk Summary. (Support Case 01275552)
- Fixed an issue where the CABI Summary Dashboard did not appear and kept on spinning. (Support Case 01316621)
- Fixed an issue in which UMP was very slow and was taking a lot of time to load the profiles/templates. (Support Case: 01258194)
- Fixed an issue in which on enabling vmware qos, USM was not responding.
- Fixed an issue in which UMP was using outdated software, thereby exposing the application for vulnerabilities. (Support Case: 01010826)
- Fixed an issue where the UMP performance was slow. Specifically, the MCS templates were slow for the user-defined custom group profiles. MCS was retrying infinitely to apply the profiles to all the devices in the group. (Support Case 1298008)
- Fixed an issue in which users were unable to import a dashboard using the .lar file. When they were trying to import the dashboard, they were getting the following error: (Support Case: 01358069)Your request failed to complete.An unexpected error occurred while importing your file.
- Fixed an issue in which a query running from within the UMP portlet Performance Reports Designer was creating issues. (Support Case: 01243328)
- Fixed an issue where the UMP performance was slow, and the flash plugin was showing a timeout error. (Support Case 1220304)
- Fixed performance issues in UMP where UMP was not responding while loading profiles on theMonitoringtab. This was happening when the number of MCS profiles was very high. (Support Cases: 01129912, 01258194, 01220304, and 01184464)
- Fixed an issue in which the UMP 9.02 installation was failing because the wasp probe was not starting. (Support Case: 01298520)
- Fixed an issue in which sometimes USM was taking a lot of time to show the data or alarms. On some occasions, it was only showing "retrieving data…" and not finishing it. It was happening intermittently. (Support Case: 01326211)
- Fixed an issue in which the deployment of probes with a dependency on the vs2017_vcredist_x64 1.0 or vs2017_vcredist_x86 1.0 package was causing the computer restart. To resolve the issue, new package versions vs2017_vcredist_x64 1.01 and vs2017_vcredist_x86 1.01 have been uploaded to the web archive. For more information, see the Windows OS reboot after probe deployment KB Article. (Support Case: 01236381)
- Fixed an issue where the Operator Console was unable to browse groups or select metrics. (Support Case: 01307036)
- Fixed an issue where the groups that have an associated account or user were not visible in the Operator Console. (Support Case: 01241695)
- Fixed an issue where the Settings, Alarm Policies view did not load. (Support Case: 01247515)
- Fixed an issue with the Reports in the Operator Console which did not appear after upgrading to UMP 9.0.2 Hotfix 1. (Support Case 1295840)
- Fixed an issue where the Reports in the Operator Console were not available after upgrading to UMP 9.0.2 HF1. (Support Case 01290817)
- Fixed an issue where the Home Page in the Operator Console was misaligned after upgrading to UMP 9.0.2 HF1. (Support Case 01290817
- Fixed an issue where the wasp/UMP Group_Info option was enabled by default on the primary hub and results in the queue were not being emptied. (Support Case 01256836)
- (9.02 HF1) Fixed an issue in which users were not able to download installer files from the CA UIM Server Home page after upgrading to CA UIM 9.0.2. This issue was occurring specifically on those Linux servers where the path to the files to be download on the primary computer had both lowercase and uppercase letters. (Support Case: 20031255)
- Fixed an issue in which wasp startup was very slow; it was taking too long to start. (Support Case: 01367010)
- Fixed an issue in which after upgrading CA UIM, USM was frequently becoming unresponsive. (Support Case: 20014504)
- Fixed an issue in which the wasp probe was taking too long to get restarted on the UMP robot. On some occasions, it was taking more than 25-30 minutes for the restart. (Support Case: 01360771)
- Fixed an issue in which USM was not responding when users clicked on a monitored device. (Support Case: 20007736)
- Fixed an issue in which USM was not responding when users were trying to browse through tabs (for example, Details, Alarms, Metrics). The tabs were not responding. (Support Case: 01279937)
- (9.10 HF1) Fixed an issue in which UMP was not loading. (Support Case: 1363492)
- Fixed an issue in which users were receiving the following error when they were trying to open template editor for the snmpcollector probe. They were able to open the snmpcollector probe in AC, but when they were trying to open the template editor, the page was not loading: (Support Case: 01184805)Unable to read TemplatesTemplates were unable to be retrieved.The request for configuration timed out.
- Now, robots that include special characters other than the following in the robot names are not displayed in the Admin Console:
Admin Console verifies the robot names and if it finds any name including special characters other than the ones listed here, it does not display that robot and displays an error message stating that the robot name is invalid.
- Fixed issues with the Admin Console 9.03 which did not deploy probes. (Support Cases 1295349, 1298781)
- Fixed an issue in which users were unable to access web archive from Admin Console. Admin Console was displaying the errorCaution: A connection to the web archive can not be obtained. (Support Case: 00966974)
- Change the default credentials of a superuser in Jaspersoft to avoid vulnerability risk. For more information about how to change the default credentials, see the How to change the superuser password in Jaspersoft KB Article.
- Fixed an issue in which the external cabi probe (3.32) was deleting certain users from the Universal CABI server at regular intervals. (Support Case: 01293376)
- Fixed an issue in which the Operator Console Dashboards were getting populated with the data, but the Reports had no data to show. (Support Case: 1342595)
- Fixed an issue in which when users were trying to access reports, some of the resorts were failing. Users were trying to access the Operator Console using administrator, Reports, Servers, and accessing some reports. Those reports were failing with the error: There was an error on the server. Try again or contact site administrators. (Error UID: <ID>). (Support Case: 01331013)
Probes and Packages
This section lists probes and packages that are installed as part of 9.2.0.
The following table lists the probe versions:
9.20 and 9.20S
9.20 and 9.20S
9.20 and 9.20S
9.20 and 9.20S
The following table lists the package versions:
The following MCS templates are deployed during CA UIM installation. For more information about MCS templates and supported probe version, see probe-specific Release Notes.
Packages for CA Business Intelligence with CA UIM
The following optional probes are downloaded to the archive during CA UIM installation. For more information about CA Business Intelligence with CA UIM, refer to CA Business Intelligence Server Release Notes.
MCS 9.20 and Robot 9.20/9.20S Compatibility
If your robot version is 9.20 or 9.20S, ensure that the MCS (mon_config_service) version is 9.20. If this compatibility is not maintained, MCS profiles and alarm policies will not work.
The following are the known issues in CA UIM 9.2.0:
License Add Message Showing Success in IM
In IM, when I try to add a license from the license option under
Archive, Licenses, I receive the success message. However, it should not allow the addition of the license in CA UIM 9.2.0 because 9.2.0 does not support hub/robot- and probe-level licensing.
Though the message states that the license has been added, no license is added to the environment. You can simply ignore this message.
Login Issues in Secure Setup
In a secure setup, you might observe login issues in some CA UIM environments with errors such as SID expired/SID invalid in the hub log files. As a workaround, restart the hub.
CABI TLS v1.2 Feature Does Not Work on Windows Server 2016 for Microsoft SQL
CABI is not supported for TLS v1.2-enabled CA UIM environments on Windows Server 2016 for Microsoft SQL Server database.
Incorrect wasp Version in IM After Upgrading CABI to 9.2.0
When you upgrade CABI from CA UIM 9.0.2 to CA UIM 9.2.0 using IM, the wasp version is displayed as 9.02. However, wasp gets upgraded to 9.20, as expected
Confidential Information is Displayed in the Logs (for TLS Environments)
The trustStore, passkey, and wallet password are displayed in plain text in the logs in the TLS-configured environment.
A resolution is pending from TIBCO
(Case number 01663862).
Alarm Policies Page Not Loading in Operator Console
I have an environment where CA UIM is installed on Linux, Oracle 12c is installed on Linux, and TLS v1.2 is enabled. Now, when I try to access the
Alarm Policiespage (
Settings, Alarm Policies) in the Operator Console, the
Alarm Policiespage is not loading. Moreover, the metrics are getting collected in UMP, but no metrics are showing up in the Operator Console for alarm policies (when you click the plus icon on the
Alarm Policiespage and try to set the condition).
To address this issue, you can use the mcsuiapp_portlet 1.33 HF1 hotfix:
- Download the mcsuiapp_portlet 1.33 HF1 hotfix from the Support archive to your local archive.
- Deploy the hotfix to the UMP computer.The wasp probe is restarted.
- Access the Operator Console.
- Verify that theAlarm Policiespage is now displaying properly and metrics are also displaying for the condition setup.
Cannot Use Space In JDBC Connection URL In CABI (Bundled) 7.1.1
When you deploy CA UIM 9.0.2 (TLS-enabled) with Oracle 12c as the database, and test the connection on the CA UIM data sources, the connection shows the following error:
The JDBC URL contains invalid characters. You might have mistyped it.
This is a known issue and a resolution is pending from TIBCO. This error occurs when the connection URL or password has a space in it. This worked on earlier JasperReports servers. However, it fails in the latest JasperReports servers (6.4.3 or 7.1.1).
For more information, refer the TIBCO Community article - https://community.jaspersoft.com/wiki/unable-use-space-jdbc-connection-url-latest-version-jasperreports-server-web-ui
Relationship Viewer Portlet Not Working in Secure Setup
In a secure hub and robot setup, the Relationship viewer portlet does not work. The portlet is visible in UMP, but it does not fetch any data.
The wasp probe tries to communicate with the hub and stops after five unsuccessful attempts. During this process, it throws communication errors in the wasp log.
Admin Console Portlet Fails to Appear in UMP
The Admin Console portlet fails to display in UMP when the X-Frame-Options are set to 'deny' or when the Content Security Policy (CSP) is set to 'none'.
Add new keys Content-Security-Policy and X-Frame-Options using the wasp raw configure to enable the portlet to be working in UMP.
The keys should be added in the wasp of the CA UIM Server where the adminconsoleapp is running.
Follow these steps:
- Navigate to the wasp probe in the Admin Console.
- Select Raw Configure, webapps, adminconsoleapp, and Create New Key.
- Create the following keys:
- Key: Content-Security-PolicyValue: frame-ancestors http://<X>
- Key: X-Frame-OptionsValue: allow-from http://<X>Xis the address that you are using to access the UMP. This can be FQDN or the IP address with the port if you are not using default port. For example, frame-ancestors http://ump-mycompany.com or frame-ancestors https://ump-location1.com:8080You may add multiple addresses if you use multiple addresses to access the UMP. In the following example, we use IP and FQDN for external access, and localhost for accessing from the local machine. For example, frame-ancestors http://10.1.2.3 http://ump-location1.com:8080 http://umplocalhost
- Select Update and restart the probe.
The following snapshot illustrates the two keys Content-Security-Policy and X-Frame-Options in the wasp raw configure:
For more information about the Content-Security-Policy frame-ancestors, see Mozilla Developer documentation.
For more information about the X-Frame-Options, see Mozilla Developer documentation.
Full Metrics Not Getting Collected When Creating Enhanced Profiles
I created a CA UIM 9.0.2 setup. I then upgraded to this release, including UMP upgrade. After that, I logged in to UMP and created enhanced profiles for cdm. Now, when I check the
Metricstab for a robot on which these profiles are deployed, I do not see full metrics.
This is a known legacy issue. The behavior is as follows:
- No metric is displayed when the s_qos_data table has lower than 20 rows even though some metrics are enabled.
- Only the Power_state metric is displayed if the s_qos_data table has 20 rows even though other metrics are enabled.
- All enabled metrics are displayed if the s_qos_data table has more than 20 rows.
Summary Dashboards Do Not Load After Deploying Bundled CABI
The Summary Dashboards do not load when you deploy bundled CABI.
Delete the work folder on the CABI robot, which is at C:\Program Files (x86)\Nimsoft\probes\service\wasp\work.
Dashboards Are Not Auto-Deployed
The dashboards are not auto-deployed after you install CABI.
You must increase the heap size for the cabi probe by using the raw configuration. The recommended minimum heap-size is 2 GB.
Dashboards or Reports Are Not Displayed
The dashboards or reports are not displayed after you install CABI.
Deploy the uim_core_dashboards_pack, uim_unified_reporter_pack, and uim_cabi_health_library_reports_pack packages manually.
CA UIM Server Installation Not Working on Oracle 12c (TLS Enabled) Installed on Linux
I have Oracle 12c (with TLS enabled) installed on a Linux computer. Now, I try to install CA UIM Server 9.0.2, point it to this Oracle database, and enable the TLS option while installing the server. I receive an error and cannot proceed with the installation. I understand that this scenario is not working in 9.0.2. Can this scenario work in this release?
You can use a workaround to ensure that this scenario works in 9.2.0. You can follow these steps to resolve this issue:
- Upgrade your existing 9.0.2 (UIM Server) to 9.2.0 without enabling the TLS option. This deploys the latest data_engine probe and the latest version of all the impacted probes that are part of 9.2.0. For more information about impacted probes, see the "Probes and Packages Updated for TLS v1.2" section in Support for TLS v1.2 (Oracle).
- Follow the process to enable the TLS option using the data_engine UI. For more information about the process, see the "Additional Information" section in Support for TLS v1.2 (Oracle).
- Access the Oracle computer, open the sqlnet.ora file available in the location (for example,/u01/app/oracle/product/12.2.0/dbhome_1/network/admin) where Oracle is installed, set the value for the SSL_VERSION parameter as follows, and save your changes:SSL_VERSION = 1.2
- Restart the Oracle listener service.
- Restart the Nimsoft service.
Your 9.2.0 setup now works in this scenario.
List Designer and List Viewer Locks When Editing
When editing, the dashboards in List Designer lock and do not allow edits to be made on any browser. Similarly, the dashboards in List Viewer lock while editing and no data is displayed in the List Viewer.
Update the lists_use_java_cache key in the wasp ump_common section of the raw configure folder.
- Deactivate the wasp probe in the UMP Robot.
- Open the wasp probe using Raw Configure.
- Under ump_common section, set the lists_use_java_cache key to true: lists_use_java_cache=true
- Navigate to the <UIM>/probes/service/wasp/work/ folder.
- Delete the work folder.
- Activate the wasp probe in the UMP Robot.
- Clear the browser cache and access the List Designer.
While upgrading to a secure setup, when you deploy the secure packages (hub_secure or robot_update_secure), an error message is shown that states that the deployment has been aborted. However, the deployment completes without any issue. If you receive this error, you can ignore it.
Incorrect Error Message During Secure Hub and Robot Deployment
Incorrect distsrv Dependency Error Message
The distsrv 9.20 probe has a dependency on robot 9.20/9.20S. During an upgrade, when you try to deploy distsrv before the robot deployment, an error message is displayed stating that the existing robot version is lower than 9.20/9.20S. This error message does not display the suffix "S" in the robot version if the robot package is a secure one. It simply displays the version without "S", which is misleading. The following error message is shown:
Dependency check error: Robot version >=9.20 is required (7.97 found)
Third-Party Software Agreements
For a list of third-party software agreements applicable for CA UIM 9.2.0, download the attached file "TPSR.zip".
For a list of third-party software agreements for the 9.0.2 release, see the related TPSR article.