Monitoring Configuration Service

uim203
mcs
Creating and managing monitoring configurations for hundreds of target devices or resources is time-consuming. You can streamline the manual configuration process by using the Monitoring Configuration Service. The Monitoring Configuration Service allows Administrators and other authorized users to create a set of configuration profiles. The profiles are applied concurrently to hundreds of target devices. The Monitoring Configuration Service also automatically deploys probes to target devices as needed.
You use the provided profile types to create monitoring configuration profiles. The profile types are designed to focus on the components or network elements that probes can monitor. You no longer have to determine which probes to deploy and configure to monitor your devices.
After monitoring configuration profiles are applied to target devices, you can always modify profiles as your monitoring needs change.
Contents
Required Permissions
The Account Admin view in Operator Console (OC) lets bus users create accounts and modify ACL permissions for accounts. See Using Account Admin for more details.
The following table shows which ACL permissions are required to manage configuration profiles created with the Monitoring Configuration Service. The ACL permissions are listed vertically, and the tasks a user might perform are shown horizontally.
ACL Permissions
Manage Group Profiles
Manage Device Profiles
Manage Configuration Service Options
View Profiles
Monitoring Configuration Service
YES
YES
YES
YES
Modify Individual Monitors for Computer Systems
N/A
YES
N/A
N/A
Group Modification
YES
N/A
N/A
N/A
Probe Configuration
N/A
N/A
YES
N/A
Edit Monitoring Templates
YES
YES
N/A
YES
Verify Requirements
The Monitoring Configuration Service uses the following items that are installed with UIM Server and the OC installer:
  • Operator Console (OC):
    Select the
    Monitoring Config
    icon in the Groups View or after selecting the groups or devices in Inventory View to access the Monitoring Configuration Service.
  • mon_config_service probe:
    This probe is deployed to the primary hub during installation. This probe is required if you want to use the Monitoring Configuration Service.
In preparation for using the Monitoring Configuration Service, verify that you have:
  • Downloaded the probes that you can configure with the Monitoring Configuration Service to the local archive. See Download, Update, or Import Packages for instructions on downloading probes to the local archive.
  • Installed the appropriate probe licenses.
    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. If you want to continue with the older versions of hub and probes that require an extension of the license, contact Support so that they can assist you in extending the license (if required).
  • Reviewed the Release Notes for the probes you want to configure with the Monitoring Configuration Service. You can find Release Notes for each probe on the Probes Documentation Space.
Verify the UIM Server and Operator Console are at the same version level.
Probe Supported by Monitoring Configuration Service
For new installations, the following probes appear in either the Local Version or the Web Version column on the
Archive
tab in Admin Console. Use Monitoring Configuration Service to deploy and configure the following versions of probes. The configuration in the profile overwrites the existing monitoring settings for a probe. When probe configuration fields are not included in the monitoring profile, the existing default or configured setting is retained.
  • 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)
Refer to the Probes Documentation Space for information about probes.
Profile Types Included with CA UIM
The following are some of the profile types that you can use to create configuration profiles for monitoring probes. You can configure most profile types for Windows, Linux or HP-UX systems, unless noted.
The two kinds of profile types are:
  • Setup
    -
    Use the setup profile types to configure how the probe operates. The setup profile types are in the lower half of the list.
  • Monitoring - Use the monitoring profile types to configure what a probe monitors, and the types of alarms and QoS metrics the probe generates. The monitoring profile types appear at the top of the profile type list.
Some probes have a single profile type; whereas, others have a
setup
and one or more
monitoring
profile types. When there are several profile types, create a Setup configuration profile first. Some of the setup profile types have settings that are related to the monitoring profile types. For example, the Setup cdm profile type lets you configure sample collection intervals that apply to CPU, disk, memory, and NIC monitoring.
  • 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
  • Disk(s)
  • 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 DB2
  • Setup cdm
  • Setup dirscan
  • Setup dns_response
  • Setup Docker
  • Setup emailgtw
  • Setup log_forwarder
  • Setup log_monitoring_service
  • Setup logmon
  • 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 telemetry
  • Setup URL Response
  • Setup VMware
  • SharePoint
  • SNMP Gateway
  • SQL Server
  • URL Check
  • Windows Services
MCS also provides enhanced profiles. 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. In the UI, enhanced profiles are displayed with the term "(Enhanced)" added to the profile name; for example, CPU Monitor (Enhanced).
Preliminary Tasks
This section describes the one-time setup tasks to perform before you create a configuration profile.
The one-time setup tasks are:
  • Verify that devices in more than one group are managed by the same UIM account.
  • Deploy robots to all target devices
  • Optionally, configure proxy options especially if there are firewalls in your environment.
Create OC Groups
When you create groups in OC for the purpose of applying configuration profiles with Monitoring Configuration Service, MCS applies configuration profiles to devices (in the group) that have the resources that match a profile. For example, Monitoring Configuration Service can apply the Disk(s) or CPU Monitor profile to a group of Windows or Unix devices. But MCS would not apply an NT Performance configuration profile to a group of Unix devices.
Some probes, such as the net_connect or rsp probes, monitor remote target devices from a host computer. For these probes, you can create a group in OC with the host systems that monitor remote devices, and another group with the remote devices the probe monitors.
You use MCS to manage configuration profiles for groups automatically created with the Application Discovery feature. See Use Application Discovery for details.
Move a Device to Another Group
You can move devices between groups. It can take MCS some time to apply group configuration profiles to devices added to groups or remove profiles after a device is removed from a group.See Manage Groups in OC for more details about managing devices in groups.
If you remove a device from a group, and then add the device back to the same group later, restart the robot on the device. This allows Monitoring Configuration Service to reapply the current group configuration profiles at the next evaluation interval.
Best practice:
Add devices to only one OC group.
Using Groups and Accounts with Monitoring Configuration Service
Monitoring Configuration Service fully supports the CA UIM accounts, groups, and origin concepts used to create multi-tenancy or restricted control environments. Carefully create the account and group structure to avoid operator confusion and errors.
Always implement non-overlapping management privileges for any element managed through Monitoring Configuration Service. All users allowed to deploy a profile to an element must be able to see the element, the actual profile, and any potential group profiles. This avoids situations where multiple users can unknowingly apply conflicting configuration profiles to the same device.
Best Practice Example:
A CA UIM administrator works with two IT sites, Accounting IT, and Engineering IT. The administrator wants unified performance reports for all servers, but also wants to allow both departments to override settings. In this scenario, there is a small group of servers that are shared by and are important to both groups.
The CA UIM administrator creates the following structure of groups and permissions:
  • Standard Profiles
    : The Standard Profiles group includes a small set of servers with several configuration profiles, created with Monitoring Configuration Service, applied.
    All
    operators have access to this group and can copy profiles from this group to their servers and groups.
  • Accounting IT Servers
    : The Accounting IT Servers group includes all servers managed by the Accounting IT team.
    Only
    the Accounting IT team has access to the servers. The Accounting IT team can copy profiles from the Standard Profile group to this group and can apply any overrides needed.
  • Engineering IT Servers
    : The Engineering IT Servers group includes all servers managed by the Engineering IT team.
    Only
    the Engineering IT team has access to the servers. The Engineering IT team can copy profiles from the Standard Profile group to this group and can apply any overrides needed.
  • Shared Servers
    : The Shared Servers group includes all servers important to both Accounting IT and Engineering IT.
    Only
    the administrator has access to manage the shared servers. All configuration changes must be requested from the administrator. The administrator implements the requested changes if appropriate for both teams.
Deploy Robots to Target Devices
A robot must be running on each device. The robot allows the Monitoring Configuration Service to deploy probes and apply configuration profiles to target devices. Robots also facilitates communication between a probe and the network resources or elements the probe monitors. See Deploy Robots for more information.
Getting Started
This section explains some basic Monitoring Configuration Service concepts.
  • What are profile types?
  • Why are there two versions of the cdm probe in the Local Version column on the
    Archive
    tab in Admin Console?
  • Why are there two Setup Processes profile types?
  • Can I specify precedence for a configuration profile?
Profile Types
Monitoring Configuration Service profile types are displayed on the
Monitoring Config
in OC. Each profile type is designed to focus on system resources or elements probes can monitor. For example, the Disk(s) profile type focuses on monitoring disk drives on a computer system. Determine what you want to monitor and use the appropriate profile type to create a monitoring configuration profile.
Profile types are grouped and displayed in the following order:
  • Profile Types with configuration profiles:
    Appear alphabetically at the top of the list. Use the expand icon to view, access, or hide the configuration profile. For profile types that support multiple profiles, all existing configuration profiles are displayed when you expand a profile type.
  • Profile Types without profiles:
    Appear alphabetically after the profile types with configuration profiles. You can create or modify configuration profiles with the profile types that are displayed in normal text.
    Italicized profile types are inactive, meaning you cannot use them to create configuration profiles. Profile types are italicized in the following scenarios:
    • A probe is not in the hub's local archive. (View the
      Archive
      tab in Admin Console to determine if a probe is in the local archive.)
    • The required version of a probe is not in the local archive. See Probe Versions Supported by Monitoring Configuration Service for a list of supported probes.
    • Probes requirements are not met. For example, to create a configuration profile with the IIS profile type, the iis and perfmon probes must be in the local archive.
MCS also provides enhanced profiles. 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.
The following figure shows the major components that are displayed when you select the
Monitoring
Config.UIM Monitoring Tab
Two Versions of the cdm Probe
UIM Server Installer delivers the cdm-MC vx.xx or later probe and the standard cdm probe in the hub's local archive. Both versions of the cdm probe provide the same monitoring and alarm functionality. The cdm-MC vx.xx probe replaces the standard cdm probe that you are used to manually deploying and configuring on devices in your infrastructure.
Some key things to know about the two versions of the cdm probe are:
  • cdm-MC  vx.xx or later does not emit QoS data and alarms until configuration profiles are applied to target devices. The standard cdm probe has preconfigured settings and emits QoS data and alarms immediately after installation.
  • Use Monitoring Configuration Service to configure, deploy, and manage cdm-MC  vx.xx in your infrastructure.
  • When you create configuration profiles, cdm-MC  vx.xx is deployed (with the configuration applied) when no cdm probe is running on a target device. If the cdm probe is running on a target device, Monitoring Configuration Service applies the configuration profile to the cdm probe running on a device.
  • If you manually deploy cdm-MC vx.xx to a target device, it remains silent. The probe does not emit QoS data and alarms until configuration profiles are applied to target devices.
For new Installations of CA UIM:
  • After installation, both versions of the cdm probe appear in the primary hub's local archive.
  • The Operator Console Installer places the standard cdm probe on the Operator Console Server to monitor its performance and critical resources. Leave cdm running on the Operator Console Server.
For more information about the cdm probe, see the cdm article on the Probes Documentation Space.
Using the Setup Processes Profile Types
There are two Setup Processes profile types. Use the profile type that matches the operating system of the target device.
  • Setup processes
    profile type
    Use this profile type to create a profile for Windows, Linux, or HP-UX target devices.
    Note:
    If you configure the Setup Processes profile type for a group that has an Oracle Solaris device, the configuration profile is applied to all devices in the group. However, the monitoring results for the Solaris devices might be inaccurate. To monitor processes for Solaris zones, use the Setup processes Solaris profile type.
  • Setup processes Solaris
    profile type
    Use this profile type to create a profile for Oracle Solaris or Solaris target devices. The Setup processes Solaris profile type lets you configure the zones to monitor.
    Note:
    The system displays an error if you attempt to use the Setup processes Solaris profile type for Windows, HP-UX, or Linux devices.
Use Group Profile Priority to Set Precedence
Only one instance of a configuration profile can be applied to a target device. When devices are members of more than one OC group, the following criteria determines the configuration profile that is applied to a device:
  • Higher Group Profile Priority
    For devices that are members of several groups, the configuration profile with the higher Group Profile Priority number is applied.
    Consider the sample scenario in the following table. A user creates an Apache configuration profile for OC groups Denver and Boston. Device A is a member of both OC groups. The Apache configuration profile for the OC group Boston has a group profile setting of 200. This priority setting is higher than the priority (100) assigned to the Apache configuration profile for OC group Denver. Therefore, the Apache configuration profile for OC group Boston takes precedence and is applied to Device A.
    OC Group
    Members
    Configuration Profile
    Group Profile Priority
    Denver
    Device A
    Device B
    Apache
    100
    Boston
    Device A
    Device C
    Apache
    20
  • Device Profile
    After group configuration profiles are applied to devices in a group, an administrator can temporarily overwrite the group configuration settings for a device. The device configuration profile overwrites any group configuration profile settings. See Modify Configuration Profiles for more details.
  • When the same profile type is configured for several groups in OC but different monitoring elements are configured in each configuration profile, both profiles are applied to overlapping devices.
  • When the same profile type is configured for several groups in OC and the same monitoring elements are configured in each configuration profile, the order in which the profiles are applied is non-deterministic.
  • Device configuration profiles that are created from the same profile type must have unique profile names.
Select a Reference Device
When you create group configuration profiles with profile types that require data from a probe, you must select a
reference device
. Monitoring Configuration Service gathers data for the profile type from probes running on a reference device.
By default, the Reference Device field is populated with all devices in the selected group that have a robot and the probe associated with the selected profile type installed. You can add devices to the Reference Device drop-down list by selecting one of the following options:
  • Include Devices Not in Group
    : Select this option to choose any device in another group that has a robot and the probe associated with the selected profile type installed.
  • Include Devices Without Probe
    : Select this option to choose any device in the same group with a robot installed. The devices are not required to have the probe associated with the selected profile type installed. If you select this option and select a reference device without the probe installed, Monitoring Configuration Service deploys the probe to the selected reference device and the probe collects data required for the selected profile type.
  • Select both options
    : Select both options to choose any device in your environment with a robot installed. The devices are not required to have the probe associated with the selected profile type installed. If you select a reference device without the probe installed, Monitoring Configuration Service deploys to the selected reference device and the probe collects data required for the selected profile type.
User Scenario
  • Prerequisite
    • Verify that the processes probe is in the local archive.
  • Environment
    • A group in OC with three test Windows devices.
    • A robot is installed on all three devices.
    • The processes probe is not installed on any of the devices in the OC group.
    • The processes v4.31 probe is in the local archive.
  • Scenario
    • I want to create a Processes group configuration profile to monitor processes running on the devices in a OC group.
    • I want to use a device in the selected group as a reference device.
Most people prefer to create a group configuration profile and let Monitoring Configuration Service deploy probes and apply the monitoring configuration profiles to devices in a group. This is the case for this sample scenario.
In this scenario, the first time you view the processes profile type, the Reference Device field is empty because the processes probe has not been deployed to devices in the group. To populate the Reference Device field, you can select the
Include Devices Without Probe
option. This option adds all the devices (with an installed robot) in the selected group to the drop-down list.
After you select a reference device, Monitoring Configuration Service deploys the processes probe to the reference device and then gathers data from the probe. Monitoring Configuration Service populates the Available Processes drop-down list. Select the process you want the processes probe to monitor and configuration the remaining settings. Create the configuration profile. Monitoring Configuration Service deploys the processes probe and then applies the monitoring configuration to all devices in the group.
The group configuration profile remains locked until Monitoring Configuration Service is finished applying the profile to all devices in the group. Once the configuration profile is unlocked, you can modify the configuration or copy the profile to another group or to a device in another group.
Can I Change the Reference Device?
When you create or modify a configuration profile, you can change a reference device. Monitoring Configuration Service gathers data from the newly selected reference device and returns a list of available processes. The list of available processes could be different. You can select a different process to monitor.
Also, if the newly selected reference device does not have the probe associated with the profile type installed, Monitoring Configuration Service deploys the probe to the reference device and then MCS retrieves the required data.
Create a Processes Group Configuration Profile
The following procedure shows you how to create a processes group configuration profile in the environment described at the beginning of this user scenario. The configuration process includes how to use the
Include Devices Without Probe
option to populate an empty Reference Device field, activate a configuration profile, select the type of process the probe monitors on target devices, and configure the Process Restart alarm.
Follow these steps:
  1. Select the test group in OC.
  2. Click the
    Monitoring Config
    .
  3. Select '
    +
    ' and select the Processes profile type.
  4. (Optional) Modify the Group Profile Priority setting. See Use Group Profile Priority to Set Precedence for more details.
  5. Select the
    Active
    check box to enable the probe to generate the configured alarms and metrics.
  6. Enter a unique
    Profile Name
    and a brief
    Description
    for the configuration profile.
  7. Select the desired process in the
    Available Processes
    field.
    Monitoring Configuration Service populates the Process Name, Command Line, and Process Owner fields with data retrieved by the reference device.
  8. Select the
    Track Process by Process Identifier
    option.
    You must select this option to configure the Process Restart alarm settings.
  9. Select the
    Process Restart
    option.
  10. In the Report on Process field, select
    Down
    .
  11. In the Severity fields, select
    Information
    and
    Critical
    .
  12. Create
    the configuration profile.
The following diagram shows the group Processes configuration profile we just created. Notice that the configuration profile appears at the top of the profile type list.
Group Processes Configuration Profile
Workflow for Managing Configuration Profiles
The process of creating and managing configuration profiles, and then rolling out the configurations to production groups consists of the following tasks:
  • Develop and Test Configuration Profiles
    Configure profiles for a 'test' device in a test environment. If probes are not running on target devices, Monitoring Configuration Service deploys the appropriate probes to the target 'test' device and applies the configuration profiles that you created. Observe the QoS data and alarms emitted.
  • Move Configuration Profiles to Production
    Continue to modify configuration profiles for the 'test' device until you determine that the monitoring configuration is correct. When the device configuration profiles are fully tested, copy the device configuration profiles to a preproduction or production group. The copied configuration profiles are applied to all devices in the group. See Copy Profiles for Consistent Monitoring for more details about the copy function.
  • Modify Production Configuration Profiles
    When you want to modify production group configuration profiles, copy the group profiles to the 'test' device. Modify the profiles for the 'test' device. Test the monitoring results to verify that you are seeing the expected QoS data and alarms emitted. When fully tested, copy the configuration profiles from the 'test' device to the production group. The modified group configuration profiles are applied to all devices in the group.
The following figure shows the recommended end-to-end process of creating and copying device configuration profiles to a production group.
Create and Deploy a Configuration Profile
Create and Deploy a Configuration Profile
Always copy pre-production or production group configuration profiles back to the 'test' device in the test environment to modify and test profile configuration changes. Observe QoS messages and alarms in the test environment. When configuration profiles are fully tested, copy the device profiles to a pre-production group. Test, observe results, and then copy the pre-production group profile to a production group.
When upgrading to a newer version of CA UIM with existing MCS configuration profiles applied to target devices, you might notice that probes are not generating the expected metrics or alarms after the upgrade.
To resolve this issue, we recommend the following actions:
  • If an error condition appears in the Profile Status section of a configuration page, manually delete the probe associated with a configuration profile. Use Admin Console to delete probes from target devices.
  • Move the newest version of a profile type to production.
  • Make a minor change to the configuration profile with an error status.
Result: Monitoring Configuration Service deploys the version of the probe in the local archive and applies the configuration profile to target devices. The probe generates the correct metrics and alarms.
Monitoring Configuration Service attempts to apply configuration profiles to a probe on a target device. The Profile Status can show an error condition when Monitoring Configuration Service cannot apply a configuration profile to an older version of a probe.You might also notice that probes are not generating the expected metrics or alarms. To resolve this issue, manually remove an older version of a probe from target devices. Make a minor change to the configuration profile Monitoring Configuration Service applied to target devices. This makes Monitoring Configuration Service deploy the version of the probe in the local archive to target devices. Then MCS applies the configuration profile to the target devices. The probe should begin to generate metrics and alarms.
Correcting the plugin_metric.cfg File
When you create an alarm policy or an enhanced profile, its configuration information is written in the plug_in file.
In robot versions prior to the secure version, sometimes, this information is not written properly in the plugin_metric file. For example, you create an alarm policy, but that alarm policy configuration is not deployed properly. In this case, the corresponding information is not updated correctly in the plugin_metric file and this creates issues. Similarly, when you delete a child profile from the Operator Console UI, the same information is not deleted from the plugin_metric file. This issue has been fixed in the robot version released with CA UIM 9.2.0 and later releases.
To resolve such issues in your environment, you can use the
plugin_metric_correction
callback that is available for the mon_config_service probe. This callback re-deploys enhanced profiles and alarm policies based on your input.
Follow these steps:
  1. Ensure that you do not create any MCS profiles or alarm policies when you are performing this operation.
  2. (Optional) Open the mon_config_service raw configuration and increase the thread count to 10 in the
    timed
    section for each parameter:
    • device_processing_threads
    • config_deployment_threads
    We recommend that you increase the thread count so that the process completes quickly. After you complete the process, change the settings back to the original values.
  3. Access the probe utility (pu) for the mon_config_service probe.
  4. Locate and select the
    plugin_metric_correction
    callback from the drop-down list.
  5. Enter the appropriate information for the following parameters, as required:
    • process_all_devices_flag
      Enter the value as true if you want to re-deploy enhanced profiles or alarm policies on all the devices. If you select this parameter, all the remaining parameters are not required.
    • robot_names
      Enter the specific robot name on which you want to re-deploy the enhanced profiles or alarm policies. If you want to use more than one entry, enter a comma-separated list.
    • computer_system_ids
      Enter the specific computer system ID (cs_id) on which you want to re-deploy the enhanced profiles or alarm policies. If you want to use more than one entry, enter a comma-separated list.
    • cm_group_ids
      Enter the specific group ID on which you want to re-deploy the enhanced profiles or alarm policies. All the devices that are part of that group are considered for re-deployment. If you want to use more than one entry, enter a comma-separated list.
    Note:
    You can use any combination of
    robot_names
    ,
    computer_system_ids
    , and
    cm_group_ids
    .
  6. Run the callback.
    A message appears in the right pane stating that the process has started for the devices. However, note that no completion message is displayed. The process completes all related tasks in the background. If you want to check the status, you need to verify the database.
  7. Verify the status by running the following queries:
    • select * from ssrv2policytargetstatus where cs_id in (<ID>);
    • select * from ssrv2profile where cs_id in (<ID>);
    The status OK means that the re-deployment has occurred without any issue.
  8. Similarly, to find whether any error has occurred, run the following query:
    • select * from ssrv2audittrail where
      userid
      like 'plugin_correction%';
    From the result of this query, note down the object IDs (failed computer system IDs), review the error messages, resolve them, and then again run the callback for these failed devices.
You have successfully repaired the plugin_metric file.