UIM 20.3.1

uim2031
2031_release_notes
As part of the regular release cycle for updating Unified Infrastructure Management (UIM), we are pleased to announce the UIM 20.3.1 patch release. This release includes new and enhanced features, resolved issues, and so on.
3
2
New and Enhanced Features
The following features and enhancements have been included in 20.3.1:
Service Level Management
This release of UIM provides the Service Level Management (SLM) functionality. The SLM view is an interface to create service-level agreements (SLAs) and their component service-level objectives (SLOs) and quality of service (QoS) constraints. With this functionality, you can build powerful, extensible, and measurable agreements with clients. Once you define SLAs in the SLM view, data is recorded and compliance is computed automatically.
For more information about how to work with SLM, see the SLM View article.
SLA Reports
You can also view reports on SLA compliance in the SLA Reports interface and can export them for transmission to clients. The SLA Reports view displays performance information for service level agreements (SLAs) defined in the SLM.
For more information about SLA Reports, see the SLA Reports article.
Access Admin Console from OC
You can now access the Admin Console UI from Operator Console (OC). This ability provides a seamless access to the Admin Console UI without logging out of OC. The Admin Console application allows you to manage and maintain the hubs, robots, and probes on your system.
For more information about how to access Admin Console from OC, see the Admin Console in OC article.
Alarm Policy Enhancement
The alarm policy functionality has been enhanced in this release to provide a centralized threshold management for technologies that are monitored remotely. For remote probes, alarm policies are no longer tied with the robot, which implies that the same policies are not applied to all the devices that a remote probe manages.
You can define separate thresholds for different devices or groups that are monitored through the same remote probe. Therefore, for devices or groups that a remote probe manages, alarm policies are now applied only to those devices for which they were created. This ensures that alarms are generated only for the relevant devices, allowing you to manage your policies and alarms in a more efficient manner.
For more information, see the "Centralized Threshold Management for Technologies Monitored Remotely" section in the  Manage Alarms with Centralized Alarm Policies article.
Copy MCS Profiles
You can now copy a device or a group profile (the source) and apply the copied profile to another device or group profile (the target). Monitoring Configuration Service (MCS) then analyzes the source against the target and performs the appropriate action. When you apply a profile at the group level, MCS applies this profile to all devices within the group.
For more information about how to copy and apply MCS profiles, see the How to Copy and Apply MCS Profiles article.
Delete a Device Using OC
UIM now lets you remove devices using the Operator Console (OC) Inventory view. The process gives you the ability to delete a device from inventory and prevent rediscovery, close alarms associated with the device, and delete stored QoS data for the device.
For more information about how to delete a device using OC, see the Remove Devices in OC article.
Deprecated Portlets
To view the complete list of deprecated portlets, see the Deprecated Portlets article.
Enable Read-Only Access to MCS Profiles
This release of UIM facilitates read-only access to the MCS profiles based on the role of a user. A new permission is now available that provides the read-only access to the user. Users with this permission can only view the MCS profiles; they cannot edit, create, or delete them. This ensures that only relevant users are allowed to perform the required operations on the profiles.
For more information about how to enable the read-only access to the MCS profiles, see the Enable Read-Only Access to MCS Profiles article.
Enhanced Telemetry for PLA Model
Telemetry is a foundational element of the Enterprise Software Portfolio License Agreement (PLA) model. The initial requirement of the Telemetry effort is to collect and report product-specific usage daily in support of the new consumption model. Broadcom uses its own endpoint to support the Enterprise Software Telemetry rollout. This endpoint provides a centralized platform for the collection and routing of usage data through various pre-built integrations and destinations.
For more information, see the Configure Telemetry for the PLA Model article.
Manage Discrepancies Between Expected and Existing MCS Configurations
The GA version of the mon_config_service_recon probe is now available that lets you administer the MCS configurations in your UIM environment. You can use this probe to detect and handle discrepancies between the expected configuration and the existing configuration that is deployed to the probes in your environment.
For more information about how to work with this probe, see the mon_config_service_recon probe documentation.
UIM Perl SDK Supports TLS 1.2
An updated version of the Perl SDK is now available. This version of the SDK supports Perl v5.32, which provides the TLS 1.2 support in the SDK while communicating with the UIM databases (Oracle and Microsoft SQL Server).
The Perl SDK now supports only the following UIM-supported platforms:
  • Microsoft Windows x86_64
  • Linux x86_64
For more information, see the Perl SDK section in the Working with Development Tools article.
Resolved Issues
The following issues have been resolved in this release:
  • Resolved an issue where users were getting the data access error when they were trying to launch the MCS Dashboard from the OC UI (with MySQL as the database).
  • Fixed an issue where while trying to create a ticket in ServiceNow from the Alarms view in OC, the ticket was not getting created. The Create Ticket option was available along with the alarms, but it was not allowing to create the tickets.
  • Resolved an issue where when the same groups were created from two different account users, only one group was getting displayed in the tree view. However, the List and the Card views were displaying both the groups. This issue was occurring when the UIM 20.3.0 setup was using the Oracle database.
  • Fixed an issue where the alarms table was displaying the "Error retrieving alarms" message instead of "No active alarms" even when all the alarms were acknowledged. This issue was occurring when the UIM 20.3.0 setup was using the Oracle database.
  • Fixed an issue where moving a robot from one hub to another was not changing the origin in OC. The old hub was still shown as the origin of the robot even when the robot was moved to a new hub.
  • Fixed an issue where after creating the "remote system monitoring" profile at the group level for non-robot devices, when users were trying to click the non-robot device and open the profile, they were receiving an error.
  • Fixed an issue where the MCS profile names in the Remote and Cloud Monitoring option of the Setup Wizard (in OC) were not always visible. This behavior was occurring when the database was Oracle.
  • Fixed an issue where the robot deployment configuration/status was missing for the robot deployment functionality in OC.
  • Fixed an issue where switching from one group to another in the dashboards was not working properly in the tree view. The dashboards were showing the previous group details instead of a new group even when the users moved to the new group.
  • Fixed an issue where the option to remove a device was not available in the Inventory view of OC.
  • Fixed an issue where users were unable to create the Microsoft Windows Service (ntservices) "For-Each" group profile. When they tried to create it, the service name field remained in the disabled state. Therefore, the values were are not becoming available for mapping the keys in the "For-Each" profile.
  • Fixed an issue where users were unable to delete those device-level profiles that were created by the group-level profile. The delete option was not deleting the profiles.
  • Fixed an issue where when the SQL_Response OLEDB legacy profile was created with "For Each Deployment Enable" = Yes, the group level profiles were getting migrated, but not the device-level profiles.
  • Resolved an issue where the device-level profile migration was not working for the For-Each profile.
  • Fixed an issue where the newly enabled metrics were not reflecting in the UI for the existing Apache MCS profile. They were remaining in the disabled state.
  • Resolved an issue where the profiles were not getting created when users were trying to create a "For Each" profile in OC using the "{foreach-instance}" details.
Upgrade Patch Artifacts
The following artifacts are available as part of the UIM 20.3.1 patch:
Artifact
Version Number
Download Location
OC Installers
  • installOC.exe (Windows)
  • installOC_linux.bin (Linux)
20.3.1
Robot Packages
  • robot_update
  • robot_update_secure
9.32
MCS Packages (provided as mon_config_service bundle):
  • mon_config_service
  • mon_config_service_ws
  • mon_config_service_recon
  • mon_config_service_cli
20.31
Perl and Perl SDK Packages
  • Perl_LINUX_23_64
  • SDK_PERL
  • 5.32 (for Perl_LINUX_23_64)
  • 20.30 (for SDK_PERL)
PLA Telemetry
  • uimesdplatelemetry
1.07
UIMAPI Package
  • uimapi
20.31
High-Level Upgrade/Deployment Process
For the UIM 20.3.1 upgrade, review the following points:
  • Before you upgrade to UIM 20.3.1, verify that your existing environment is using UIM 20.3.0.
  • The UIM 20.3.1 patch does not include any upgrade installer for the UIM Server. The patch contains separate standalone artifacts that you need to deploy manually to upgrade the respective components to 20.3.1. Therefore, ensure that you deploy the latest packages (for example, robot_update, mon_config_service) that are available for 20.3.1.
  • The UIM 20.3.1 patch also includes an upgrade installer for OC. You can run the OC upgrade installer to upgrade OC 20.3.0 to OC 20.3.1.
  • Finally, after upgrading all the appropriate components, you can start using the features that the UIM 20.3.1 patch provides.
The recommended high-level steps to apply the patch artifacts are as follows:
  1. Deploy robot 9.32 to the core robots (for example, hub, OC, CABI).
  2. Run the OC 20.3.1 upgrade installer on the primary hub and specify the OC server during the upgrade.
  3. Deploy the MCS 20.31 packages as follows:
    1. Deactivate the existing mon_config_service probe on the primary hub, deploy the mon_config_service 20.31 package to the primary hub, and activate mon_config_service.
    2. Deactivate the wasp probe on the OC robot, deploy the mon_config_service_ws 20.31 package to the OC robot, and activate wasp. This step is required if you are using the MCS web services.
    3. Deploy the mon_config_service_recon 20.31 package to the primary hub and activate the probe after it gets created. This step is required if you want to use the MCS reconciliation functionality.
    4. Deploy the mon_config_service_cli 20.31 package to the primary hub. This step is required if you are using the MCS CLI functionality.
  4. Deploy the uimapi 20.31 package to the OC robot.
  5. Deploy the other packages: uimesdplatelemetry (on UIM Server) and SDK_PERL (on any robot), if required.
  6. If your environment contains multiple OC instances:
    1. On your secondary OC servers, upgrade the relevant packages listed in Step 2 of the Configure a Secondary OC Server section to the 20.3.1 version. The 20.3.1 packages are available in the local archive.
    2. Execute Step 3b (deploy mon_config_service_ws 20.31) and Step 4 (deploy uimapi 20.31) on the secondary OC robots.
    3. Deploy the ump_slm 20.31 package to the secondary OC robots. The ump_slm 20.31 package is available in the local archive.
Known Issues
The following are the newly added known issues that are applicable for the 20.3.1 patch:
  • [UIM 20.3.1] Delayed Discovery Agent Status
    When a discovery is scheduled, it is taking some time to update the status in the UI. This behavior is occurring because when a discovery is scheduled on a discovery agent, the agent status is delayed by 1 minute due to the internal architecture. This causes the delay in the status. This can be treated as a known issue.
  • [UIM 20.3.1] Context Launch for DX NetOps Spectrum Alarms Not Available in OC
    For the DX NetOps Spectrum-UIM integration, the context launch for the DX NetOps Spectrum alarms is not available from the OC interface. This issue will be addressed soon.
  • [UIM 20.3.1] System-Generated Job Not Getting Created after Saving SLA
    When you save SLA, the system-generated job is not getting created if there is no change in the SLA form.
  • [UIM 20.3.1] Exporting SLA to PDF Truncates the QoS Constraint List of SLOs
    In SLA Reports, when you export the SLA to the PDF format, the SLA and SLO information is exported to the PDF. However, the list of QoS constraints configured in the SLO is not exported completely.
    This issue has been fixed in the UIM 20.3.3 release.
  • [UIM 20.3.1] Incorrect Label “Interface Filters” Coming Up During Group Edit
    If a dynamic group is created with the OR conditions in the group filter criteria, then an incorrect label “Interface Filters” is getting displayed in the UI when you try to edit that group.
    This issue has been fixed as part of the OC 20.3.2 patch release.
  • [UIM 20.3.1] Interchanging of Group Names in Tree View
    When groups are created with the same name by two different account users, the Bus users will see the occasional interchanging of the groups in the tree view.
    This issue has been fixed as part of the OC 20.3.2 patch release.
To view the complete list of known issues that are applicable for this release, see the "UIM 20.3.1 Known Issues" section in the Known Issues article.
Third-Party Software Agreements
For a list of third-party software agreements that are newly added in UIM 20.3.1, download the attached file "tpsrs_uim_2031.zip
To view the complete list of third-party software agreements, see the related TPSR article.