mon_config_service (Monitoring Configuration Service) Release Notes

uimpga-ga
mon_config_service_RN
The mon_config_service probe and the mon_config_service_templates package are required to use the Monitoring Configuration Service. Both the probe and the templates package are installed with
CA Unified Infrastructure Management
.
Use the Monitoring Configuration Service to create, modify, and apply configuration profiles for monitoring probes on target devices. Use the profile types that are displayed to create configuration profiles. At regular intervals, the Monitoring Configuration Service deploys probes and applies the configuration to target devices.
The mon_config_service probe is responsible for performing the following tasks:
  • Gathering data that is required for configuration from probes
  • Deploying probes as needed
  • Applying new and modified configuration profiles to target devices
  • Copying configuration profiles when the copy option is used
  • Proxying requests from the primary hub to probes behind a firewall
  • Removing inactive profiles from the database at a configured interval
Contents
3
Revision History
This table describes the history of probe updates.
Version
Description
State
Date
20.33
(Released with UIM 20.3.3)
  • The following new parameters are now available in MCS:
    • txn_timeout: This parameter lets you configure the transaction time out. It is available in the setup section of the MCS configuration. The default value is 1020. For example, txn_timeout = 1020.
    • audit_enabled: This parameter lets you enable or disable the auditing. It is available in the timed section of the MCS configuration. By default, the value is set to true. For example, audit_enabled = true.
    • number_of_processing_devices: This parameter lets you specify the number of devices (which are in the modified or new state) to be processed for the monitoring purpose. It is available in the timed section of the MCS configuration. The default value is 1000. For example, number_of_processing_devices = 1000.
  • (20.31 HF1) Resolved an issue where updates on the UIM profiles were not always triggering the probe restart. (Support Case: 32283937)
  • (20.31 HF1) Resolved an issue where monitoring profiles were not always getting assigned to the server. (Support Case: 32327952)
    The 20.31 HF1 hotfix introduces a new key number_of_processing_devices in the mon_config_service.cfg file (under the timed section). The default value is 1000. This value is configurable. You can change the value based on the number of devices in the inventory that you are monitoring.
  • (20.31 HF2) Resolved an issue where MCS profiles were getting created too slowly. (Support Case: 32440705)
  • Fixed an issue where the UIM provisioning information and the profile name were not matching with the profile variable field. This issue was being observed for the Network Connectivity (Enhanced) profile. (Support Case: 32443342)
  • Fixed an issue where the MCS query was making the SQL transaction log full after every 2-3 days. (Support Case: 32462061)
  • Fixed an issue where for several "disabled" profiles, the expected template or probe versions within the MCS backend tables were actually missing within the UIM probe/package archive. This was resulting in the profiles being disabled as MCS/ADE was unable to locate the required versions for the monitoring configuration deployment. Also, the MCS profiles were not deploying and the MCS logs were showing
    maximum number of profiles
    . (Support Cases: 32481934 and 32469928)
  • Fixed an issue where MCS was creating the profiles at an extremely slow pace. (Support Case: 32440705)
  • Fixed an issue where the MCS template deployment for nic_monitor was failing. The MCS log was not showing up any entries of uploading the new template. It was still referring to the older version. (Support Case: 32445566)
  • Fixed an issue where users were unable to use OC after they upgraded to 20.3.2. They were observing that the performance was too slow. (Support Case: 32467330)
  • Fixed an issue where the probe deployment was getting referred for most of the robots. The MCS deployment dashboard was also showing that the profiles were still in the pending state. (Support Case: 32470045)
GA
March 2021
20.31
  • Released as part of the UIM 20.3.1 patch. The mon_config_service 20.31 package is included in the bundle mon_config_service_bundle 20.31. This bundle is released as part of the UIM 20.3.1 patch. The UIM 20.3.1 patch includes various standalone artifacts. Therefore, ensure that you deploy the related 20.3.1 artifacts (mon_config_service 20.31, mon_config_service_ws 20.31, mon_config_service_recon 20.31, mon_config_service_cli 20.31, robot_update 9.32, OC 20.3.1 Upgrade Installer, uimapi 20.31) to access the complete functionality that the patch provides.
GA
November 2020
20.30
(Included in UIM 20.3.0)
What's New
  • (9.20 HF5) Fixed an issue in which remote profiles are not getting deployed by MCS. (Support Case: 31819927)
  • (9.20 HF5) Fixed an issue where the alarm policy entries in "error" status are with version=-1. (Support Case: 31927120)
  • (9.20 HF5) Fixed an issue where alarm policies are not getting processed: excessive retry count. (Support Case: 31927103)
GA
September 2020
20.10
(Included in UIM 20.1.0)
What's New
  • (9.10 HF2 and 9.20 HF1) Fixed an issue in which MCS could not handle unreachable robots on delete. This hotfix contains the fix for the excessive growth of the SSRV2AudittrailModification tables. This hotfix turns off the entries into the SSRV2AudittrailModification tables whenever the profile is modified. (Support Case: 20032772)
  • (9.10 HF3 and 9.20 HF1) Fixed an issue where the LDAP account user was unable to select the host location for the remote MCS profiles. (Support Case: 20069408)
  • (9.10 HF3 and 9.20 HF1) Fixed an issue in which the last deployed date of an MCS profile in USM was always getting the current time. This hotfix contains the fix for displaying the last deployed date correctly in the UMP UI.
  • (9.20 HF2) Fixes the following issue: (Support Case: 20084368)
    • Fixed an issue where the new name of a USM group was not reflected in the Alarm Policy UI.
    • Fixed an issue where the net_connect auto policies were getting deployed to the target robot instead of the poller robot.
    • Deployment of profiles are decoupled from processing of devices at the group level for increasing the performance of MCS.
  • Fixed an issue where "Last deployed date" of an MCS profile in USM is always current time and not the time it was actually deployed.. (Support Case: 20069054)
GA
March 2020
9.20
(Included in CA UIM 9 SP1)
What's New
  • (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.02 HF2) Fixed an issue in which the database size was growing exponentially after users were configuring MCS enhanced profiles in a CA UIM 9.0.2 environment. This hotfix removes the unnecessary entries from the SSRV2AuditTrailModification table, which was resulting in the increase of the database size. This hotfix also deletes the invalid robots. (Support Case: 01272939)
  • (9.02 HF4) Fixed an issue in which the MCS probe was displaying as red after upgrading from CA UIM 8.5.1 to CA UIM 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 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)
  • Supports changes in the template name and ignores case sensitivity in template names during the migration of enhanced templates.
  • Fixed an issue in which removing a system from a group was not removing the MCS profile configuration. (Support Case: 01283081)
  • (8.58 HF12) Fixed an issue in which multiple profiles were being created for the same drive. This hotfix addresses this issue. Additionally, 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 were 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, it is recommended (not mandatory) to deploy the nis_server 9.00 HF1 hotfix. (Support Case: 01279316)
  • Added a callback upgrade_probe_to_eligible_robots that deploys the required probe version on all the specified robots. You do not need to manually deploy the probe version on each individual robot. For more information, see "Manage Monitoring Using MCS Profile Types" in CA UIM DocOps.
  • Added a callback get_devices_not_having_group_profile_deployed that lets you get a list of devices that do not have a specific group profile deployed on them. For more information, see "Manage Monitoring Using MCS Profile Types" in CA UIM DocOps.
  • Added a callback plugin_metric_correction that fixes the plugin_metric in case the plugin_metric.cfg file is corrupted. For more information, see "Monitoring Configuration Service" in CA UIM DocOps.
  • 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)
  • Improved the profile deployment and probe deployment performance.
  • 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.0.2 HF5) This hotfix resolves the error that was occurring while importing the profiles using the MCS CLI import utility. For 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)
  • Added a new parameter
    enable_container_support_for_alarm_policy
    that lets you enable support for alarm policies for container groups. To enable the support, set the parameter value to
    true
    . The default value is
    false
    .
If your robot version is 9.20 or 9.20S, ensure that the MCS version is 9.20. If this compatibility is not maintained, MCS profiles and alarm policies will not work.
  • Added a new parameter
    enable_container_support_for_alarm_policy
    that lets you enable support for alarm policies for container groups. To enable the support, set the parameter value to
    true
    . The default value is
    false
    .
CA UIM 9.2.0 has adopted OpenJDK 8u212 instead of Oracle JDK. Because of this change, CA UIM 9 SP1 (9.1.0) that was using Oracle JDK (JRE) 8u212 is no longer available and has been removed from the Support site. All the functionality that was included in 9.1.0 is now released as part of CA UIM 9.2.0. Consequently, all references to the 9.1.0 release and the probe version 9.10 (released with it) have also been removed from this probe documentation. We recommend that you move to this version 9.20 of this probe, as the previous version 9.10 is no longer available now. For more information about the OpenJDK usage in CA UIM, see  Adopting OpenJDK.
GA
August 2019
9.02
What's New:
  • Updated this probe as part of addressing CVE-2018-13820 and CVE-2018-13819 vulnerabilities in CA UIM 9.0.2.
  • Updated this probe as part of removing known security vulnerabilities in CA UIM 9.0.2 by using the upgraded MariaDB components.
  • Added a new configuration key
    enable_auto_migration
    . This key helps you automatically migrate existing profile instances to the latest version of the installed probe templates. For more information, see mon_config_service Key Value Reference.
  • Added a new type of Monitoring Configuration Service (MCS) profile, called an enhanced profile. Enhanced profiles enable you to configure metrics, baselines, alarm thresholds, alarms - including Time Over Threshold alarms - and custom alarm and close alarm messages, all within a single MCS profile. For more information, see Configuring Alarm Thresholds in MCS.
  • Added a configuration key
    policy_mode_enabled
    . This parameter decides what sections are displayed in the UMP UI for metrics and alarm definition configuration (for enhanced profiles). For more information, see mon_config_service Key Value Reference.
  • Provided support where certain probes offer a finer level of control for monitoring virtual groups and devices. During the secondary discovery process, MCS recognizes the different virtual device types in the inventory that these supported probes publish. For these supported probes, you can now create static or dynamic USM groups of the probes' different virtual device types. You can then apply profiles for virtual devices to a group, or to an individual device. Furthermore, for supported virtualization probes, you can apply new probe-specific override profiles to either a group or a device. When you apply a profile to a group or a device, MCS automatically configures monitoring in the probe that most recently discovered the group or device.
  • Updated the probe as part of adding the TLS v1.2 support in CA UIM, which establishes a securecommunication with the UIM database: Microsoft SQL Server and Oracle. For more information about how to enable TLS v1.2 support in CA UIM, see TLS v1.2 Support for Microsoft SQL Server and TLS v1.2 Support for Oracle.
Fixed Defects:
  • Fixed an issue in which users were getting a Null pointer error when they were trying to update an MCS profile for a process monitor. (8.5.8 HF5) (
    Support case number 01096147
    )
  • Fixed an issue in which cdmtemplate 6.30 was not getting activated correctly for Default Disk(s). (8.5.8 HF4) (
    Support case number 01002860
    )
  • Fixed an issue in which the MCS web services were not allowing creation of profiles when a template was using a reference device. (8.5.8 HF5) (
    Support case numbers 00965630, 00992064, and 00934729
    )
  • Fixed an issue in which the MCS stopped contacting the unreachable robot for profile deployment after 30 tries. (8.5.8 HF5) (
    Support case number 00987869
    )
  • Fixed an issue where users were unable to activate a new version of the existing template. (8.5.8 HF10) (
    Support case number 00977080
    )
  • Fixed an issue in which MCS failed to deploy Memory Monitor, CPU Monitor, and Default Disk(s) group profiles from another system. The issue occurred when you used the mon_config_service_cli utility  to export profiles from one system and import them into another. The profiles imported but then the mon_config_service probe failed to deploy the imported profiles, indicating that: "NimsoftProbeDeployer.269: Session was closed by remote host, on each attempt until the profile status was set to error." (
    Support case numbers 800075, 782785)
  • Fixed an issue in which, when you cleared a field in the Default Disk(s) profile, the configuration change was not applied to the probe configuration.
  • Fixed an issue in which the mon_config_service_cli fix-profile-diffs tool failed to restore Default Disk(s) monitoring. Because the Filesystem Type Filter field value is applied when discovering disks, any changes made to the value of this field should be deployed with the Default Disk(s) profile rather than the Setup cdm profile. Therefore, to ensure that configuration changes made for each resource type are deployed at the same time, we moved the Filesystem Type Filter field, and other fields that applied to resources of type disk, from the Setup cdm template to the Default Disk(s) template. We also moved the Memory and CPU fields in the Setup cdm template to their respective templates: Memory Monitor and CPU Monitor. (
    Support case number 00800075)
  • Fixed an issue in which MCS continued to deploy a profile in an error state even after the maximum number of retries had been reached. (
    Support case number 00827678)
  • Fixed an issue in which, when a group profile was in an error state, the Monitoring Configuration Service (MCS) would continue creating group member profiles for it. (8.5.8 HF1)
  • Fixed an issue in which MCS would attempt to un-deploy profiles from robots that did not have a
    CM_NIMBUS_ROBOT
    entry due to bad error handling. (8.5.8 HF1)
  • Fixed an issue in which, when robot 7.92HF3 and above was deployed to an environment, MCS was running into errors where the remote host would close sessions on probe config deployments with large payloads. (8.5.8 HF1) (
    Support case number 00827678)
  • Fixed an issue in which the mon_config_service probe incorrectly handled fields designated as variable values if the field value was not set. As a result, the mon_config_service probe did not permit the logmon template to be configured correctly.
    (8.5.8 HF2) (Support case number
    00668211)
  • Fixed an issue in which the application discovery profile was not getting created or deployed.
    (Support case numbers 00944919 and 00780254)
  • Fixed an issue in which, if the mon_config_service probe was used with Microsft SQL Server, it failed to create Port Check profiles. (8.5.8 HF2) (
    Support case number 00878649)
  • Fixed an issue where alarms from MCS were missing expected information.
    (Support case number 01115074)
  • Fixed an issue in which users were getting the following error and MCS was not deploying all profiles:
    (Support case number 1169027)
    This concerns the MCS-102 messages:
    2018-07-02 16:19:26,117 ERROR [ProfileController:15] ProfileController.rollbackSave:1714: Encountered error: The {0} has reached the allowed maximum count of profiles for template {1} [MCS-102] while saving profile name: 'Default Disk(s)' with profile id: 'null' for device id: 27579.
    com.nimsoft.selfservice.exceptions.InvalidProfileException: [MCS-102] The device with device_id 2247 has reached the allowed maximum count of profiles for template 38, The {0} has reached the allowed maximum count of profiles for template {1} [MCS-102], MCS-102
  • Fixed an issue where some MCS profiles were getting locked and users were unable to modify or save changes.
    (Support case number 00850433)
  • Fixed an issue where MCS was not working using distsrv.
    (Support case number 986946)
  • Fixed an issue in which after applying CA UIM SP1 to CA UIM 8.51 installation, the mon_config_service probe was stopping.
    (Support case number 1139629)
  • Fixed an issue in which users were setting up CA UIM (8.5.1) and UMP (8.5.1). They were defining some profile types based on different groups in USM. However, they observed some profiles that had not been applied to robots. They were also receiving the following error in mon_config_service log:
    (Support case numbers 1132817 and 985938)
    [MCS-102] The device with device_id 1386 has reached the allowed maximum count of profiles for template 72.
  • Fixed an issue in which users were not able to export MCS profiles because of version mismatch between CA UIM and MCS. (
    Support case number
    1127928)
  • Fixed an issue in which some of the MCS profiles were returning an error when users were trying to open them for reconfiguration.
    (Support case number 1120023)
  • Fixed an issue where Active Directory MCS configuration was not working.
    (Support case number 01169335)
GA
October 2018
8.56
What's New:
  • Added the ability to configure the clean-up (also known as the "garbage collection") of the audit trail history.
  • Added garbage collection of the MCS SSRV2Audittrail and SSRV2AudittrailModification tables. You can now configure MCS to clean up the audit trail history automatically instead of having to create a separate database process to do so. The audit trail garbage collection process is controlled by threekey valuepairs that you can configure using the Raw Configure option in Admin Console:
    • garbage_cleanup_interval_minutes
      - How frequently the garbage collection process is executed
    • garbage_cleanup_batch_size
      - The number of records to remove during each garbage collection interval
    • days_in_audit_trail_history
      - The number of days of audit trail history to keep in the SSRV2Audittrail and SSRV2AudittrailModification tables
For more information, see mon_config_service Key Value Reference.
Fixed Defects:
  • Fixed an issue in which, when you used MCS to monitor a Windows Service, MCS named the profile with the service name (short name) but when you monitor a Windows Service by directly configuring the ntservices probe, the probe named the profile with the service description (long name).
    DE296201
  • Fixed an issue in which after you upgraded to to UIM 8.5.1 SP1, and you updated the MCS templates to the latest versions, the templates failed to upgrade. Instead, you saw the following error: "Failed to execute probe callback activate_template against probe mon_config_service. Received the following error: Callback error."
    Support case 00786189, DE304702
  • Fixed an issue in which, when MCS encountered a duplicate key exception, then MCS could not continue to process the remaining group profiles. A duplicate key exception indicates that a group member profile has already been created for a group member.
    Support case 00740839, DE300398
  • Fixed an issue in which the mon_config_service probe failed to process group member profiles when a device was found in the CM_COMPUTER_SYSTEM table that did not have an associated device perspective in the CM_DEVICE table.
    DE293344
  • Fixed an issue in which the mon_config_service probe stalled during "deploy removal" configurations for profiles that had never been deployed. Now, profiles are deleted from the database without requiring a probe to be deployed.
    DE288912
  • Fixed an issue in which MCS failed to delete group member profiles that had not yet been deployed.
    DE288912
  • Fixed an issue in which the following query:
    select * from CM_COMPUTER_SYSTEM cs join CM_DEVICE d on d.cs_id=cs.cs_id
    resulted in a null pointer exception. The null pointer exception caused MCS to skip group member profile evaluation/creation.
    DE293344
  • Fixed an issue in which the Setup rsp template version 1.9 failed to import due to an erroneous duplicate error message.
    Support case 00742788, DE293692
  • Fixed an issue in which MCS failed to identify the highest priority group profile in MySQL environment.
    Support case 00750764, DE303571
  • Fixed an issue in which the MCS utilities tool failed with a bad SQL grammar error. When you used the find-profile-diffs MCS utility tool to build the output\devices_with_deltas file that contained a list of robots with profile differences, and you then used this output file as the input to the fix-profile-diffs MCS utility tool, the tool failed with a bad SQL grammar error.
    Support case 00728127, DE289998
  • Fixed an issue which affected users of UIM 8.47 with ntevl 4.24, and mon_config_service 8.42. In this environment, if you created an Event Log Include profile for the ntevl probe, then you activated a Filter in the Event Selection Criteria, the Source field had a 50 character limit.
    Support case 00677952, DE277560
  • Fixed an issue in which, for version 1.37 of the MCS Apache template, the monitor names were appended with the unit of measure, causing all Apache profiles to be corrupted.
    DE294039
GA
August 2017
8.50
You can export and import configuration profiles with the new MCS Utilities Tools.
Removed the reconciliation function from the mon_config_service probe. You can find and fix profile differences using the MCS Utilities Tools.
Replaced the Timed/threads key value with the Timed/device_processing_threads and Timed/config_deployment_threads key values. See mon_config_service Key Value Reference for details.
Replaced the
make_production
command with an
activate_template
command. Use the get_template_activation_status command to determine if a new version of a template is in production. Use the list_template_versions command to get a list of the template versions in the database. See Move Updated Templates to Production for details.
Use new MCS profile types to configure the following probe versions:
  • ad_server v1.91
  • ad_response v1.70
  • aws v5.21
  • docker_monitor v1.42
  • exchange_monitor v5.31
  • iis v1.90
  • jdbc_response v1.25 (for the PostgreSQL profile type)
  • ldap_response v1.35
  • net_connect v3.31
  • nutanix_monitor v1.51
  • openstack v1.36
  • rsp v5.20
  • sap_basis v1.31
  • sharepoint v1.81
  • telemetry v1.30
  • vmware v6.81
New profile types that are included in the mon_config_service_templates v10.31 package are:
  • Active Directory Server
  • Active Directory Response
  • Exchange Monitor
  • IIS
  • LDAP Response
  • Port Check
  • PostgresSQL
  • Remote System Monitoring
  • SAP ABAP
  • SAP NetWeaver
  • Setup AWS
  • Setup Docker
  • Setup net_connect
  • Setup Nutanix
  • Setup OpenStack
  • Setup rsp
  • Setup SAP
  • Setup telemetry
  • Setup VMware
  • Sharepoint
Removed the Debug Mode option from the Configuration Service Options. See Monitoring Configuration Service for details.
The timed/threads key value was replaced with the timed/device_processing_threads and timed/config_deployment_threads key values. Also added timed/check_device_offline_minutes and deploy/queueSize key values. See mon_config_service Key Value Reference for details.
Thecdm5.80-MC probe is included in the mon_config_service_templates v10.30 package. MCS deployscdm5.80-MC when you create configuration profiles with the CPU Monitor, Default Disks, Disks, Memory Monitor, or Setupcdmprofile types.
GA
March 2017
8.44
CA UIM 8.5 release includes the mon_config_service_templates v9.10 package.
Use the new MCS profiles types to configure monitoring for the following probe versions:
  • azure v3.0
  • emailgtwv2.83
  • snmpgtwv1.40
New profile types that are included in the mon_config_service_templates v9.10 package are:
  • Email Gateway 1.02
  • Setup Azure 3.0
  • Setupemailgtw1.01
  • Setupsnmpgtw1.01
  • SNMP Gateway 1.02
Thecdm5.72-MC probe, which is deployed when you create a configuration profile using the CPU Monitor, Default Disks, Disks, Memory Monitor, or Setupcdmprofile types.
Minor defect fixes.
GA
December 2016
8.43
CA UIM 8.4.7 release includes mon_config_service_templates v9.0 package.
Changes that are released with CA UIM 8.40 Service Pack (SP) 1 and SP2 are rolled into CA UIM 8.47. For complete details, see the CA UIM 8.40 Upgrading and Release Notes or Installing CA UIM.
Use the new MCS profiles types to configure monitoring for the following probe versions:
  • adevlv2.01 or later
  • ews_response 2.03 or later
  • dns_response 1.68 or later
  • url_response 4.23 or later
New profile types that are included in the mon_config_service_templates v9.10 package are:
  • Active Directory Events Exclude 2.54
  • Active Directory Events Include 2.67
  • MS Exchange Server Response 2.10
  • NIC Monitor 1.05
  • QoS Definition (logmon) 2.14
  • Variables (logmon) 2.58
  • Setup dns_response 1.03
  • Setup URL Response 1.09
See Upgrade Templates for information about moving the newer version of a template to production.
Minor changes were made to the Windows Services template. See the Improvements section for details.
Original templates that are included in mon_config_service_templates 8.42 package and already exist in the database are automatically saved in a Duplicate folder.
Added the force_profile_delete_on_error parameter to the mon_config_service key values. When set to yes, MCS deletes profiles that are in an error state.
Thecdm5.72-MC probe, which is deployed when you create a configuration profile using the CPU Monitor, Default Disks, Disks, Memory Monitor, or Setupcdmprofile types.
Fixed defects:
  • Devices are no longer duplicated. See Devices are No Longer Duplicated for more details.
  • Monitoring Configuration Service works properly after a discovery reset.   
GA
June 2016
8.42
Initial Release
CA UIM 8.4 includes mon_config_service_templates v8.42 and the following profile types. Use profile types to create monitoring configuration profiles with the Monitoring Configuration Service.
  • Apache 1.05
  • CPU Monitor 2.12
  • Default Disk(s) 2.15
  • Disk(s) 2.25
  • DNS Response 1.04
  • Email Response 1.05
  • Event Log Exclude 2.09
  • Event Log Include 2.23
  • File and Directory Scan 2.11
  • Log Monitoring 2.36
  • Memory Monitor 2.16
  • MySQL 1.06
  • NT Performance Metrics 2.10
  • Oracle 0.11
  • Processes 2.21
  • Setup cdm 1.11
  • Setup dirscan 1.05
  • Setup logmon 2.06
  • Setup ntevl 2.10
  • Setup ntperf 1.05
  • Setup ntservices 1.11
  • Setup processes 1.06
  • Setup processes Solaris 1.00
  • SQL Server 1.06
  • URL Check 1.03
  • Windows Services 2.15
The cdm 5.61-MC probe is deployed when you use the following profile types:
  • CPU Monitor
  • Default Disk(s)
  • Disk(s)
  • Memory Monitor
  • Setup cdm
For a list of probes that you can configure with Monitoring Configuration Services, see Probes You Can Configure with the Monitoring Configuration Service.
GA
February 2016
Probe Specific Hardware Requirements
Install the mon_config_service probe on systems with the following
minimum
resources:
  • Memory: 1024 MB of RAM
  • CPU: 3-GHz dual-core processor, 32-bit or, 64-bit
Probe Specific Software Requirements
The following
minimum
software versions are required:
CA Unified Infrastructure Management
9.0.2
  • CA Unified Infrastructure Management
    9.0.2
  • mon_config_service 9.02
  • <probe_name>
    _mcs_templates (probe templates package)
  • discovery_server 9.02
  • ump_usm 9.02 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.5.1 SP1
  • CA Unified Infrastructure Management
    8.5.1
  • mon_config_service 8.50
  • mon_config_service_templates 10.31
  • discovery_server 8.51
  • ump_usm 8.51 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.5.1
  • CA Unified Infrastructure Management
    8.5.1
  • mon_config_service 8.50
  • mon_config_service_templates 10.31
  • discovery_server 8.51
  • ump_usm 8.51 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.5.0
  • CA Unified Infrastructure Management
    8.5
  • mon_config_service 8.44
  • mon_config_service_templates 9.10
  • discovery_server 8.5
  • ump_usm 8.5 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.4.7
  • CA Unified Infrastructure Management
    8.47
  • mon_config_service 8.42
  • mon_config_service_templates 9.0
  • discovery_server 8.42
  • ump_usm 8.47 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.4 SP2
  • CA Unified Infrastructure Management
    8.40
  • mon_config_service 8.42
  • mon_config_service_templates 8.43
  • discovery_server 8.42
  • ump_usm 8.42 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.4 SP1
  • CA Unified Infrastructure Management
    8.40
  • mon_config_service 8.42
  • mon_config_service_templates 8.43
  • discovery_server 8.41
  • ump_usm 8.41 portlet that is deployed wherever the wasp probe is running
CA Unified Infrastructure Management
8.4
  • CA Unified Infrastructure Management
    8.40
  • mon_config_service 8.41
  • mon_config_service_templates 8.42
  • ump_usm 8.40 portlet that is deployed wherever the wasp probe is running
General Considerations
Meet the following prerequisites to allow Monitoring Configuration Service to deploy probes and configuration profiles to target devices:
  • Install robots on the target devices.
  • Use the Admin Console interface to verify that you have downloaded and deployed to the local archive the probes that can be configured with the Monitoring Configuration Service. Otherwise, the related profile types are not configurable on the
    Monitoring
    tab in USM.
  • Verify that all the probe licenses are up to date.
  • Select a
    device model
    for each USM group so that you can create or copy a configuration profile for the group.
For CA UIM 8.47, see the Using Admin Console section for more information about downloading a probe and managing probe licenses.
For CA UIM 8.40, see Download a Probe from the Web Archive and Manage Hub and Probe Licenses for more information about downloading a probe and managing probe licenses.
Profile Types
Profile types are displayed in the UI. The templates are used to generate the profile types. The following are some of the profile types:
  • Active Directory Events Exclude
  • Active Directory Events Include
  • Active Directory Response
  • Active Directory Server
  • Apache
  • Application Discovery Scripts
  • CPU Monitor
  • Default Disk(s)
  • Disk IO Monitors
  • DNS Response
  • Email Gateway
  • Email Response
  • Event Log Exclude
  • Event Log Include
  • Exchange Monitor
  • File and Directory Scan
  • IIS
  • Iostat
  • LDAP Response
  • Log Forwarding
  • Log Forwarding Apache
  • Log Forwarding Catalina
  • Log Forwarding Log4j
  • Log Forwarding Oracle Alert
  • Log Monitoring
  • Log Monitoring Service
  • Memory Monitor
  • MS Exchange Server Response
  • MySQL
  • NIC Monitor
  • NT Performance Metrics
  • Oracle
  • Port Check
  • PostgreSQL
  • Processes
  • Remote System Monitoring
  • SAP ABAP
  • SAP NetWeaver
  • Setup adevl
  • Setup Application Discovery Defaults
  • Setup AWS
  • Setup axa_log_gateway
  • Setup Azure
  • Setup cdm
  • Setup dirscan
  • Setup dns_response
  • Setup Docker
  • Setup emailgtw
  • Setup log_forwarder
  • Setup log_monitoring_service
  • Setup logmon
  • Setup MySql
  • Setup net_connect
  • Setup ntevl
  • Setup ntperf
  • Setup ntservices
  • Setup Nutanix
  • Setup Openstack
  • Setup processes
  • Setup processes Solaris
    (Used only for Solaris systems)
  • Setup rsp
  • Setup SAP
  • Setup snmpgtw
  • Setup SQLServer
  • Setup telemetry
  • Setup URL Response
  • Setup VMware
  • Shared Disk(s)
  • SharePoint
  • SNMP Gateway
  • SQL Server
  • URL Check
  • Windows Services
Probes You Can Configure with the Monitoring Configuration Service
The following list includes probes that you can configure with the MCS:
  • adevl 2.02 (or later)
  • ad_server 1.91 (or later)
  • ad_response 1.70 (or later)
  • apache 1.62 (or later)
  • aws 5.21 (or later)
  • axa_log_gateway 1.00 (or later)
  • azure 3.01 (or later)
  • cdm 5.80 (or later)
  • cdm-MC 5.80 (or later)
  • dirscan 3.14 (or later)
  • docker_monitor 1.42 (or later)
  • dns_response 1.68 (or later)
  • emailgtw 2.82 (or later)
  • email_response 1.44 (or later)
  • ews_response 2.03 (or later)
  • exchange_monitor 5.31 (or later)
  • iis 1.90 (or later)
  • jdbc_response 1.25 (or later) (for the PostgreSQL profile type)
  • ldap_response 1.35 (or later)
  • log_forwarder 1.00 (or later)
  • log_monitoring_service 1.00 (or later)
  • logmon 3.55 (or later)
  • mysql 1.48 (or later)
  • net_connect 3.31 (or later)
  • netapp_ontap 1.21 (or later)
  • ntevl 4.12 (or later)
  • ntperf and ntperf64 2.03 (or later)
  • ntservices 3.24 (or later)
  • nutanix_monitor 1.51 (or later)
  • office365 1.00 (or later)
  • openstack 1.36 (or later)
  • oracle 4.91 (or later)
  • processes 4.01 (or later)
  • rsp 5.20 (or later)
  • sap_basis 1.31 (or later)
  • snmpgtw 1.40 (or later)
  • sharepoint 1.81 (or later)
  • sqlserver 4.94 (or later)
  • telemetry 1.20 (or later)
  • url_response 4.41 (or later)
  • vmware 6.81 (or later)
  • vnxe_monitor 1.01 (or later)
  • xtremio 1.01 (or later)
Installation Considerations
The mon_config_service probe and the mon_config_service_templates package must be deployed on the primary hub to use the Monitoring Configuration Service feature. Both the probe and the templates package are automatically installed during the
CA Unified Infrastructure Management
installation process. Additionally, for CA UIM 9.0.2, deploy the
<probe_name>
_mcs_templates (probe templates package) after downloading from Support Archive.
Install CA UIM 8.40 SP1 and SP2
You can install the CA UIM 8.4 SP1 and then CA UIM 8.4 SP2 on a
CA Unified Infrastructure Management
8.4 system.
Follow these steps:
  1. Complete the installation instructions that are described in Upgrading and Release Notes.
  2. Verify that the following items appear in the Local Archive list:- cdm 5.
    nn
    -MC probe- discover_server 8.41 for SP1 or discover_server 8.42 for SP2- mon_config_service 8.42- mon_config_service_templates 8.43- ump_usm 8.41 for SP1 or ump_usm 8.42 for SP2
  3. Verify that the wasp probe is activated.
Update Templates
There can be several versions of a template that are stored on a UIM server, but only one version of a template can be in production. When you update templates, you import the latest versions of available templates and then migrate your profiles instances to the latest version of the relevant probe templates. Depending on your version of CA UIM, you might then also need to manually move the latest template versions into production.
Migration of profiles is time consuming and is dependent on hierarchy of the template. If the template has more levels then it would take more time to migrate those profiles.
For example, logmon template migration might take more time during migration process if there are more profiles at each level.
(CA UIM 9.0.2) Update Templates
Importing Templates
CA UIM 9.0.2 includes an easier way to migrate your profiles to the latest version of a template. You now use the new installation package, called a
"probe templates package," for
each
probe that you want to import new templates into MCS for. The probe templates package imports all the templates for a single probe into MCS.
Migrating Profiles
The probe templates package also includes a profile migrator that can automatically migrate existing profile instances to the latest version of the installed probe templates. You control whether or not the new probes template package automatically migrates existing profile instances to the latest version of the installed probe templates. To configure MCS to migrate all existing profiles, you use the new
/migration/enable_auto_migration
MCS configuration key. The default value for the
/migration/enable_auto_migration
key is
false
. If you keep the default value of false, the probe templates package imports the probe templates from the probe templates package installation file, but does
not
migrate any of the existing profiles.
Update Templates Steps
Follow these steps:
  1. Get a specific version of a probe templates package (
    <probe_name>
    _mcs_templates.zip) from support.nimsoft.com.
  2. Deploy the probe templates package using IM or the Admin Console on the primary hub robot.
    The mon_config_service probe identifies the request for the probe templates package installation and reads the installation details. If this is successful, then the probe templates package enters an "initialized" state.
  3. After the probe templates package is initialized, the probe templates package transitions to a "loading" state. In the loading state, the package starts importing the templates into the database.
  4. When all the templates are imported into the database, the probe templates package transitions to a "loaded" state.
  5. Then, if the
    /migration/enable_auto_migration
    key is set to
    true
    , the installation process continues. And the probe templates package transitions to a "migrating" state.
  6. Or, if the
    /migration/enable_auto_migration
    key is set to
    false
    , the installation process stops. And the probe templates package remains in the "loaded" state.
  7. If you then execute the
    activate_probe_templates_package
    command, the probe templates package continues migrating until all the existing profiles are migrated to the latest versions of the probe templates.
  8. If all of the existing profiles are migrated successfully, the probe templates package transitions to a "migrated" state.
Troubleshooting
What should I do if the templates fail to import or the profiles fail to migrate?
The probes template package is designed so that all templates are successfully imported or
none
of them are imported. Similarly, all profiles are migrated or none are migrated. If a failure occurs when the probe tries to import templates or migrate profiles, the probe writes an error message  to the
mon_config_service.log
file. The message includes information that you can use to troubleshoot the failure, including: the name of the probe templates package that failed, the probe name, and probe templates package version.
How do I migrate a probe templates package
after the templates have already been imported?
If you set the value to
false
for the
/migration/enable_auto_migration
key and then change your mind, you can use the
activate_probe_templates_package
command to
activate
the probe templates that have already been imported. When you use the
activate_probe_templates_package
command, it migrates any existing profile instances to the latest version of the installed probe templates.
Follow these steps:
  1. In Admin Console, select the primary hub and then the Probes tab.
  2. Click the inline menu button in front of the mon_config_service probe and select
    View Probe Utility in New Window
    .
  3. Select the
    activate_probe_templates_package
    command.
  4. Enter the probe name in the
    probe_name
    field.
  5. Enter the templates package version in the
    templates_package_version
    field.
  6. Click the green arrow to execute the command.
How do I determine the state of a probes template package?
You can determine the state of any probe templates package
installation. To track the progress of a probe templates package installation, execute the
get_probe_templates_package_status
command.
Follow these steps:
  1. In Admin Console, select the primary hub and then the Probes tab.
  2. Click the inline menu button in front of the mon_config_service probe and select
    View Probe Utility in New Window
    .
  3. Select the
    get_probe_templates_package_status
    command.
  4. Enter the probe name in the
    probe_name
    field.
  5. Enter the templates package version in the
    templates_package_version
    field.
  6. Click the green arrow to execute the command.
    The response will include details about the probe templates package:
    • probe_name
    • templates_package_verision
    • status (initialize, loading, loaded, migrating, migrated, error)
    • final_time
    • final_message
    • For each template in the probe templates package:
      • template_name
      • template_version
      • status is one of (loaded, migrating, migrated, invalid, aborted, error)
      • final_time
      • final_message
(CA UIM 8.51) Update Templates
Templates with associated configuration profiles remain in production until an administrator manually moves a new template version to production. After an administrator manually moves a new version of a template with an associated configuration profile to production, Monitoring Configuration Service migrates the configuration profiles.
To upgrade templates for CA UIM 8.4.7 or CA UIM 8.5, see Move Updated Templates to Production.
To upgrade templates for CA UIM 8.5.1:
  1. Export and delete Apache, MySQL, Oracle, or SQL Server configuration profiles that are created with earlier template versions.
(CA UIM 8.5.1 and earlier) Before Updating Apache, MySQL, Oracle, and SQL Server Templates
The Apache, MySQL, Oracle, and SQL Server profile types were redesigned for the mon_config_service_templates v9.0 release. If you created configuration profiles with profile types Apache v1.04 or earlier, MySQL v1.07 or earlier, Oracle v1.43 or earlier, or SQL Server v1.06 or earlier, Monitoring Configuration Service cannot migrate these configuration profiles.
The recommended procedure is to export the profiles to view the configured settings, and then delete the existing profiles. Manually move the newer version of a template to production. Finally, use the exported profiles to re-create configuration profiles with the new template versions.
Follow these steps:
  1. Export the Apache, MySQL, Oracle, or SQL Server configuration profiles you must delete.
  2. On the
    Monitoring
    page, select the profile that you want to delete.
  3. Select the delete (trash) icon to the right of the profile name.
  4. Select
    Yes
    on the Delete Confirmation dialog.
(CA UIM 8.5.1 SP1) View Summary Reports
In UIM 8.5.1, after you deployed the latest version of the mon_config_service templates package, you then used the MCS Summary Report. You used the Summary Report and the
make_production
callback as part of the manual process to move any newly imported templates (with existing profile instances against previous versions of the same templates) into production. In UIM 8.5.1, you read the MCS Summary Report to get the newly imported template IDs so that you could execute the
make_production
callback to put a new template into production. However, in 8.5.1 SP1, the
make_production
callback was deprecated and two new callbacks were introduced:
activate_template
and
list_template_versions
.
With the addition of the
list_template_version
callback, you no longer need the MCS Summary report to get the newly imported template IDs. However, the MCS Summary Report was not removed in 8.5.1 SP1. In UIM 8.5.1 SP2, the MCS Summary Report is removed. The Summary Report is no longer created when new templates are imported. Instead, you now execute the
list_template_versions
callback to determine which template is in production. The template version that has production set to "True" is the template version on which all existing and new profiles are based.
(CA UIM 8.5.1) View Summary Reports
When a new mon_config_service_templates package is deployed to your primary hub, Monitoring Configuration Service generates a Summary Report for each template that is in use but has a newer version. Monitoring Configuration Service cannot update a template when it is in use for a configuration profile. You can view Summary Reports with Remote Desktop.
Follow these steps:
  1. Log in to your primary hub with Remote Desktop.
  2. Navigate to the reports folder <UIM>/Nimsoft/probes/service/mon_config_service/reports.
    The reports folder stores a report for each template that is in use but has a newer version.
    RD-Reports_Folder.png
  3. In the reports folder, look for reports that use the following naming convention:
    <template name>_vn.nn_to_vn.nn_rpt
  4. (CA UIM 8.5.1) Record the template name and the version number that is displayed for each report. Go to View Template Versions.
(CA UIM 8.5.1) View Template Versions
At any time, use the
list_template_versions
command to view the versions of a template that is stored in the Processed folder on your UIM Server. The output from the
list_template_versions
command shows the version of a template in production, the earlier template versions, and the new template versions that you can move to production. With a few exceptions (see Before Updating Apache, MySQL, Oracle, and SQL Server Templates), Monitoring Configuration Service can migrate configuration profiles to a newer template version in production with the
activate_template
command (see Move Updated Templates to Production (CA UIM 8.5.1).
Follow these steps:
  1. Access Admin Console.
  2. Select the
    Robots
    tab.
  3. Select the primary hub.
  4. Select the
    Probes
    tab.
  5. Click the inline menu button for the mon_config_service probe and select the
    View Probe Utility in New Window
    option.
  6. Click the
    list_template_version
    command.
  7. Enter a profile type name.
  8. Click the green arrow to execute the command.
    A table displays with all the versions of a template that is stored on the UIM Server. Each table entry has an entry number (for example, 0, 1, 2) in the Name field. The template version currently in production has
    production = true
    in the table entry. Use the
    activate_template
    command to move a newer version of a template into production. See Move Updated Templates to Production for details.
    The following figure shows two versions of the Oracle template that is stored in the Processed folder. Notice that Oracle v2.14 has production=true, which means this template version is in production.
    list_template_versions.png
  9. (Apache, MySQL, Oracle, SQL Server) If you are upgrading to
    CA Unified Infrastructure Management
    8.5.1, and you have existing MCS configuration profiles for monitoring Apache Servers, MySQL, Oracle, or SQL Server databases:
    1. Look at the Template Version for existing Apache, MySQL, Oracle, and SQL Server configuration profiles.
      Oracle template .011.png
    2. If there are configuration profiles with template versions Apache v1.04 and earlier, MySQL v1.07 and earlier, Oracle v1.43 and earlier, or SQL Server v1.06 and earlier, go to Before Updating Apache, MySQL, Oracle, and SQL Server Templates. Then continue to the next section.
(CA UIM 8.5.1) Move Updated Templates to Production
Moving new versions of templates to production is a manual process. This requires a monitoring administrator to make a deliberate decision to move a new version of a template to production. Before you complete this procedure, you should have completed:
Follow these steps:
  1. Issue the
    activate_template
    command.
    1. In Admin Console, select the primary hub and then the
      Probes
      tab.
    2. Click the inline menu button in front of the mon_config_service probe and select
      View Probe Utility in New Window
      .
    3. Select the
      activate_template
      command.
    4. Enter the new
      template version
      in the template_version field.
    5. Enter a profile type name (for example, CPU Monitor) in the
      template_name
      field.
    6. Click the green arrow to execute the command.
      If an error occurs, an error message displays.
      activate_template_already_in_use.png
      If you attempt to update a template version that cannot be updated (see Before Updating Apache, MySQL, Oracle, and SQL Server Templates for details), the following error message displays:
      Unable to activate template <template_name> version <version_number>. Profiles created with template version <version_number> currently exist and cannot be upgraded.  See the Release Notes for the mon_config_service probe.
  2. Write down the displayed
    activation_id
    .
    Note: The activation_id is displayed only once.
    activation_id.png
  3. To determine when the new version of a template is in production, use the get_template_activation_status command.
    1. In
      View Probe Utility in New Window
      in Admin Console, click the
      get_template_activation_status
      command.
    2. Enter the activation_id displayed after you executed the activate_template command.
    3. Click the green arrow to execute the command.
      get_template_activation_status.jpg
    4. Time stamps for initiation and completion of the task, and one of the following states is displayed:
      In progress
      - Template activation is still in progress.
      Succeeded
      - The new version of a template is in production.
      Failed
      - The template activation processes failed.
  4. Verify that the configured values are migrated to the new version of the template.
    1. Select the
      Monitoring
      tab in USM.
    2. Open an existing configuration profile that was created with a previous version of a template. Existing configuration settings are migrated to the newer template.
(CA UIM 8.4.7 or CA UIM 8.5) Move Updated Templates to Production
Moving new versions of templates to production is a manual process. This requires a monitoring administrator to make a deliberate decision to move a new version of a template to production.
Follow these steps:
  1. If you are upgrading to
    CA Unified Infrastructure Management
    8.4.7 or
    CA Unified Infrastructure Management
    8.5, and you have existing MCS configuration profiles for monitoring Apache Servers, MySQL, Oracle, or SQL Server databases:
    1. Look at the Template Version for existing Apache, MySQL, Oracle, and SQL Server configuration profiles.
      Oracle template .011.png
    2. If there are configuration profiles with template versions Apache v1.04 or earlier, MySQL v1.07 or earlier, Oracle v1.43 or earlier, or SQL Server v1.06 or earlier record the configured settings.
    3. Delete configuration profiles with template versions Apache v1.04 and earlier, MySQL v1.07 and earlier, Oracle v1.43 and earlier, or SQL Server v1.06 and earlier.
  2. Record the Template ID of new template versions.
    1. Log in to your primary hub using Remote Desktop.
    2. Go to
      <uim>/Nimsoft/probes/service/mon_config_service/reports
      and look for reports that use the following naming convention:
      <template name>_vn.nn_to_vn.nn_rpt
      MCS generates a report for each template with existing configuration profiles.
    3. Open the report in a text editor.
    4. At the top of the report, record the template ID displayed for the new version of the template. The information that is displayed is similar to the following:
      Source template: Windows Services 2.15 Template ID: 36
      Target template: Windows Services 2.17
      Template ID: 46
  3. Increase the callback timeout value:
    1. Access Admin Console.
    2. Select the
      Robots
      tab.
    3. Select the primary hub.
    4. Select the
      Probes
      tab.
    5. Click the inline menu button for the mon_config_service probe and select the
      View Probe Utility in New Window
      option.
    6. Click
      Actions
      (upper right corner of the page) and select
      Set Timeout
      .
    7. Change the value to 300 seconds.
    8. Click
      Save
      .
      Note:
      The timeout setting remains active until you close the Probe Utility window. After you close the window, timeout returns to the default of 30 seconds.
  4. Issue the make_production command with the new Template ID.
    1. In
      View Probe Utility in New Window
      in Admin Console, click the
      make_production
      command.
    2. Enter a template ID for the new version of a template. Click
      Enter
      to save the value.
    3. Click the green arrow to execute the command.
  5. Verify that the configured values are migrated to the new version of the template.
    1. Select the
      Monitoring
      tab in USM.
    2. Open an existing configuration profile that was created with a previous version of a template. Existing configuration settings are migrated to the newer template.
Not Seeing Metrics After Updating Templates?
Some earlier versions of templates (for example, the Apache template) required an administrator to enable a metric, select the desired alarms, and select the desired QoS metrics.
apache_UIM8-50.jpg
When migrating configuration profiles for some templates available with
CA Unified Infrastructure Management
8.4.7 or earlier to a new version of a template, the probe might not generate QoS metrics.You can fix this issue.
Follow these steps:
  1. Access the configuration profiles and select the desired
    Publish
    setting in the first column of the Alarm and QoS metrics table.
    Oracle_8-51.jpg
  2. Save
    the configuration. The probe will generate metrics after it applies the modified configuration to a target device.
Updating Versions of Probes Deployed to Target Devices
When you deploy a configuration profile to a target device, Monitoring Configuration Service deploys the version of the probe in the local archive to the target device. After you install CA UIM service packs or upgrade to a newer version of CA UIM, configuration profiles and the versions of probes that are deployed to target devices remain unchanged.
You can update the version of a probe that was previously deployed to a target device.
Follow these steps:
  1. Update the version of a probe on a target device:
    1. Manually deploy a newer version of a probe to a target device.
      See the Using Admin Console section for more information about deleting and deploying a probe.
  2. Move the newest version of the template for a probe to production. See Upgrade Templates for more information.
  3. Make a minor change to the template for a probe so that MCS deploys the configuration profile to the newer version of a probe. For example, clear a check box, select the check box again, and then click
    Save
    .
MCS reconciles any configuration changes, and then deploys the configuration profile to the newer version of the probe.
Improvements
CA UIM 8.5.1
Find and Fix Profile Differences with the Probe Utilities Tools
The reconciliation function was removed from the mon_config_service probe to enhance the performance of the Monitoring Configuration Service. Expanded reconciliation functionality is now available with the Probe Utilities Tools. These tools allow you to find and fix profile differences, and export and import profiles.
Export and Import Profiles with the Probe Utilities Tools
You can export and then import configuration profiles with the Probe Utilities Tools. These tools allow you to find and fix profile differences, and export and import profiles.
CA UIM 8.47
Monitoring Configuration Service Template Updates
The templates that are delivered with CA UIM 8.47 have been updated and default values were configured, where appropriate.
CA UIM 8.40 SP2
Monitoring Configuration Service Template Updates
CA UIM 8.4 SP2 contains the following updates to the Monitoring Configuration Service templates:
Processes 2.19 Template Changes
  • Added a Binary Path field and Use Binary Path check box. Use these fields to identify processes to be monitored on UNIX systems. Enter the location (or path) of a process in the Binary Path field, and then select the Use Binary Path checkbox.
CA UIM 8.40 SP1
Monitoring Configuration Service Template Updates
CA UIM 8.4 SP1 contains the following updates to the Monitoring Configuration Service templates:
  • The field length restriction was removed for the profile Description field. Applies to the Disks, Event Log Include, File and Directory Scan, NT Performance Metrics, Processes, and SQL Server profile types.
  • Modified some parameter values to match validation that occurs in templates. Applies to the Disks, Event Log Include, File and Directory Scan, Oracle, Setup Processes, Setup Processes Solaris profile types.
  • Slight modification to the variables format. Applies to the Event Log Include, NT Performance Metrics, and Processes.
  • Removed the Logfile field. Applies to the Setup ntperf, Setup Processes, and Setup Processes Solaris profile types.
  • Slight modification to the CPU Range Severity options for the Processes profile type.
  • Removed the Active check box from the Actual Value Scaling and the Max Value sections in the NT Performance Metrics profile type.
  • When a CPU Monitor configuration profile is deleted, the cdm probe on the target device stops emitting alarms.
  • Updated the profile types to support the newer version of the cdm probe. Applies to the CPU Monitor, Default Disks, Disks, Memory Monitor, and Setup cdm profile types.
Windows Services 2.19 Template Changes
  • The Active field is selected by default.
  • The Service Display Name field was changed to be read-only.
  • Added a new field, Service Message Key, which is populated with an abbreviated version of the service that is selected in the Select Service field. The Service Message Key value appears in alarm messages to provide a reference to the Windows Services profile used to configure a ntservices probe on a target device.
  • Removed the Active check box from the Actual Value Scaling and the Max Value sections in the NT Performance Metrics profile type.
Processes 2.22 Template Changes
  • Added a new field, CPU Range Severity, which generates an alarm of the configured severity level when CPU utilization for a process is above the configured minimum and maximum alarm thresholds.
MySQL 1.08 Template Changes
  • Added a new field, Alarm Source, which allows you to specify the IP address where QoS messages and alarms should be routed.
SQL Server 1.07 Template Changes
  • Minor correction to the template. MCS was attempting to reconcile configuration profiles that are created with this template at each reconciliation interval. This behavior is corrected once this new version of the template is in production.
force_profile_delete_on_error Parameters added to mon_config_service Probe Configuration
The force_profile_delete_on_error parameter was added to the Timed section of the mon_config_service configuration. When this parameter is set to
true
, MCS can immediately delete a configuration profile when the profile is in an error state. For example, if you create a device configuration profile, but MCS cannot apply the profile because a probe is unreachable on a target device, MCS deletes the profile.
By default, the force_profile_delete_on_error parameter is set to
false
. If a profile is in an error state when this setting is
false
, MCS cannot delete the profile until the configured maxdaysinactivedeviceprofile days is exceeded.
Fixed Defects
CA UIM 8.40 SP1
Devices are No Longer Duplicated
Duplicate devices are no longer created when a monitoring administrator clicks a device in USM before creating a configuration profile with the Monitoring Configuration Service.
Monitoring Configuration Service Works Properly After a Discovery Reset
If a monitoring administrator performs a discovery reset for CA UIM 8.4, Monitoring Configuration Service can now properly rediscover devices and apply configuration profiles. (support cases: 00329724 and 00323978).
Known Issues
(CA UIM 8.5.1 SP2) MCS Template Activation Fails When You Activate Templates from the mon_config_service_templates 10.3.2
Symptom
Migration of MCS template activation fails in the following scenario:
  1. You are using CA UIM 8.5.1, with mon_config_service 8.50, with mon_config_service_templates package version 9.1.1.
  2. You have created profiles for one or more templates from the mon_config_service_templates package 9.1.1, which depend on any one of the following probes: cdm, ntservices, sqlserver, mysql, oracle.
  3. You upgrade to CA UIM 8.5.1 SP2, and deploy mon_config_service_templates package version 10.3.2.
  4. You activate a template from the 10.32 mon_config_service_templates package that depends on any one of the following probes: cdm, ntservices, sqlserver, mysql, oracle.
Workaround
Deploy the mon_config_service_templates package 10.41 and activate the desired template again.
(mon_config_service_templates 10.32) MCS Template Activation Fails When You Deploy the mon_config_service_templates 10.32 After You Have Deployed mon_config_service_templates 10.41
Symptom
If you have deployed mon_config_services_template package 10.41 and then deploy mon_config_services_template package 10.32 to the same system, activation could potentially fail for any template that depends on any one of the following probes: cdm, ntservices, sqlserver, mysql, oracle.
Workaround
If you have deployed mon_config_services_templates package 10.32 to the same system on which you had deployed the mon_config_services_templates package 10.41, and the template activation failed, redeploy version 10.41 and activate the template again.
(azure 3.01 and later) Azure MCS Template
Symptom
The Azure MCS template can be put in a state where the
Save
button is not enabled and the alarm threshold value indicates an error. This state occurs with monitor values that appear as QoS or None and the data type required is an integer.
Solution
To resolve this issue, remove the decimal point (0
.
x
) from the alarm threshold value.
(CA UIM 8.5 and earlier) Accurate Discrepancy Count in the Audit Trail
Symptom
When the profilereconcile/active parameter is set to ‘yes’ and the profilereconcile/action parameter is set to ‘audit’ for the mon_config_service probe, MCS reconciles probe configuration changes at the configured profilereconcile/checkFrequencyMins interval. The number of changes that are detected are displayed in the Audit Trail in your UIM database. If you manually change a probe configuration GUI, when MCS performs reconciliation, the number of changes that are displayed in the Audit Trail can contain changes that were made by the tool itself and the changes that you made.
Solution
To correct the Audit Trail, use Raw Configure to access the mon_config_service probe configuration. Set the following values:
  • profilereconcile/action = overwrite
  • profilereconcile/active = yes
At the next profilereconcile/checkFrequencyMins interval, MCS enforces the probe’s stored MCS configuration profile. Once the reconciliation is complete, the number of detected changes will be zero because MCS will overwrite any configuration changes made outside MCS that were in conflict with the configuration profile that is stored in MCS.
(CA UIM 8.4.7 and later) Updating to Newer Versions of the Apache, MySQL, Oracle, and SQL Server Templates
The Apache, MySQL, Oracle, and SQL Server profile types were redesigned after their initial release. If you created configuration profiles with the Apache v1.05, MySQL v1.06, Oracle v0.11, or SQL Server v1.06 profile types, you must delete existing profiles before you move newer versions of these templates to production. See Before Updating Apache, MySQL, Oracle, and SQL Server Templates for details.
Use the Default Disk(s) or the Disk(s) Profile Type
Use either the Default Disk(s)
or
the Disk(s) profile type to create a configuration profile for file systems (disks) in your CA UIM environment. If you inadvertently configure both profile types for a USM group, the configuration profiles might not be applied to target devices as you might expect.
It is important that all the devices in a group have similar characteristics. Before you configure one of the Disks profile types, ensure that the configuration settings are applicable to all storage locations for devices in the group.
Scenario 1:
A monitoring administrator selects the Default Disk(s) profile type to create a configuration profile for a group of UNIX servers. The administrator configures default settings, and these settings are applied to all storage locations on servers in the group. The administrator does not configure the Disk(s) profile type.
As file storage locations are added to servers in the group, the Default Disk(s) configuration profile is applied.
Scenario 2:
A monitoring administrator selects one or more Disks profile types to create a configuration profile for a group of Windows devices. The administrator configures settings for disks C:, D:, and E:. This profile is deployed and applied to all disks C:, D:, and E: on devices that are members of the group. The administrator does not configure the Disk(s) profile type.
As new disks are added to devices in the group, the Disk(s) configuration profile is applied.