Configuring Alarm Thresholds in 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 (MCS). The MCS allows administrators and other authorized users to create a set of configuration profiles. The profiles are applied concurrently to hundreds of target devices. The MCS also automatically deploys probes to target devices as needed.
uimpga-ga
HID_alarmthreshold
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 (MCS). The MCS allows administrators and other authorized users to create a set of configuration profiles. The profiles are applied concurrently to hundreds of target devices. The MCS also automatically deploys probes to target devices as needed.
From CA UIM 9.0.2, a new type of MCS profile is included, called an enhanced profile. Enhanced profiles provide a consistent way to configure alarms using MCS. Enhanced profiles enable you to configure metrics, baselines, alarm thresholds, Time Over Threshold alarms, and create custom alarm messages, all within a single MCS profile using the UMP UI if the policy mode parameter is disabled. If the parameter is enabled, you configure the metrics using the UMP UI and define the thresholds, alarm messages in the Operator Console as part of an alarm policy.
This article is not applicable for UIM 20.3.0.
The following topics explain the complete information:
2
2
Probes Supporting Enhanced Profiles
Currently, the following probes support the enhanced profiles:
Probe
Probe GA Version
Probe Enhanced MCS Template Version
Compatible MCS Version
Compatible Robot Version
Upgrade Scenario
Minimum Probe Version
Minimum Probe MCS Template Version
ad_response (Active Directory Response Monitoring)
1.70
ad_response_mcs_templates 1.82
9.10
9.10
1.70
ad_response_mcs_template 1.19
ad_server (Active Directory Server Monitoring)
2.03
ad_server_mcs_templates 2.06
9.02
7.96
2.03
ad_server_mcs_templates 1.17
adevl (Active Directory Events Monitoring)
2.02
adevl_mcs_templates 2.03
9.02
7.96
2.02
adevl_mcs_template 3.54
apache (Apache HTTP Server Monitoring)
1.70
apache_mcs_templates 1.72
9.10
9.10
1.70
apache_mcs_template 1.39
aws (Amazon Web Services Monitoring)
5.40
aws_mcs_templates 5.35 (Beta)
9.02
7.96
5.26
aws_mcs_templates 5.26
azure (Microsoft Azure Monitoring)
3.14
azure_mcs_templates 3.14
9.10
9.10
3.11
azure_mcs_template 3.11
cdm (CPU, Disk, Memory Performance Monitoring)
6.34-MC
cdm_mcs_templates 6.42
9.10
9.10
6.30-MC
cdm_mcs_template 2.56
ceph(Ceph Storage Monitoring)  
1.21
ceph_mcs_templates 1.23
9.10
9.30
1.23
ceph_mcs_templates 1.23
email_response (Email Response Monitoring)
1.44
email_response_mcs_templates 1.45
9.02
7.96
1.44
email_response_mcs_templates 1.12
emailgtw (Email Gateway)
2.84
emailgtw_mcs_templates 2.86
9.10
9.30
2.84
emailgtw_mcs_templates 2.86
ews_response (Microsoft Exchange Server Response Monitoring)
2.04
ews_response_mcs_templates 2.04
9.02
7.96
2.04
ews_response_mcs_template 1.24
dns_response (DNS Response Monitoring)
1.68
dns_response_mcs_templates 1.71
9.02
7.96
1.68
-
hyperv (Microsoft Hyper-V Monitoring)
3.30
hyperV_mcs_templates 3.31
9.02
7.96
3.20
hyperV_mcs_template v3.30
iis (IIS Server Monitoring)
1.91
iis_mcs_templates 1.92
9.10
9.10
1.91
iis_mcs_template 1.36
logmon (Log Monitoring)
4.11
logmon_mcs_templates 4.15
9.10
9.30
4.11
logmon_mcs_template 4.12
ldap_response
1.35
ldap_response_mcs_templates 2.15
9.02
7.96
1.35
ldap_response_mcs_template 2.14
mysql (MySQL Server Monitoring)
1.51
mysql_mcs_templates 3.34 (1.53 template package)
9.10
9.10
1.51
mysql_mcs_template 3.33
net_connect (Network Connectivity Monitoring)
3.37
net_connect_mcs_templates 3.42
9.10
9.10
3.34
net_connect_mcs_template 1.38
nexec (Command Execution)
1.36
nexec_mcs_templates 1.36
9.02
7.96
1.36
NA
ntevl (NT Event Log Monitoring)
4.32
ntevl_mcs_templates 4.31
9.02
7.96
4.24
ntevl_mcs_template 2.21
ntperf (Performance Collector)
2.09
ntperf_mcs_templates 2.10
20.1 HF2
9.30
2.07
ntperf_mcs_templates 2.10
ntservices (Microsoft Windows NT Services Monitoring)
3.50
ntservices_mcs_template 3.50
9.02
7.96
3.50
ntservices_mcs_template 2.3.4
office365 (Office365 Monitoring) 
1.03
office365_mcs_templates 1.05
9.10
9.30
1.03
office365_mcs_templates 1.05
oracle (Oracle Database Monitoring)
5.41
oracle_mcs_templates 5.35
9.10
9.10
5.20
oracle_mcs_template 2.22
processes (Process Monitoring)
4.64
processes_mcs_templates 4.64
9.02
7.96
4.6
processes_mcs_template 1.17
redis (Redis Monitoring)  
1.00
redis_mcs_templates 1.01
9.10
9.30
1.01
redis_mcs_templates 1.01
rsp (Remote System Probe)
5.33
rsp_mcs_template 5.35
9.10
9.10
5.20
rsp_mcs_template 1.11
sap_basis(SAP Basis Monitoring)
2.06
sap_mcs_templates 2.0.7
9.10
9.30
2.0
sap_mcs_templates 2.0.7
sqlserver (SQL Server Monitoring)
5.42
sqlserver_mcs_template 5.42
9.10
9.10
5.30
sqlserver_mcs_template 1.0
sql_response (SQL Server Response Monitoring)
1.80
sql_response_mcs_templates 4.00
9.02
7.96
1.80
NA
url_response (URL Endpoint Response Monitoring)
4.43
url_response_mcs_template 4.45
9.02
7.96
2.56
url_response_mcs_template 1.39
vmware (VMware Monitoring)
7.14
vmware_mcs_template 7.12
9.02
7.96
7.11
vmware_mcs_template 7.11.1
websphere_mq (Websphere MQ Monitoring)
2.22
websphere_mq_mcs_templates 2.22
9.02
7.96
2.22
websphere_mq_mcs_template 2.22.1
websphere (WebSphere Monitoring)
1.81
websphere_mcs_templates 1.81
9.02
7.96
1.81
websphere_mcs_template 1.81.1
logmon
-To successfully migrate legacy profiles to enhanced profiles for logmon, we need to delete
Setup logmon
>
QOS Definition
child template from existing (legacy) logmon template profiles, before migrating.
Prerequisites
The following software environment is required to use the enhanced profiles:
  • CA Unified Infrastructure Management version 9.0.2
  • Monitoring Configuration Service (MCS) version 9.02 - Review the
    Compatible MCS Version
    from the Probes Supporting Enhanced Profiles table.
  • Robot version 7.96 - Review the
    Compatible Robot Version
    from the Probes Supporting Enhanced Profiles table.
  • 1 that includes enhanced templates (
    <probe_Name>
    _mcs_templates.zip). Deploy this package on the computer where MCS 9.02 is deployed.
To use an enhanced profile, you must deploy the compatible robot version on the groups or devices that you want to monitor. For supported remote probes, such as vmware, deploy the robot on the same device where the probe is deployed (this might be your primary hub).
Workflow
The following diagram shows the user workflow:
Configure Alarm Thresholds in MCS
Configure Alarm Thresholds in MCS
The steps are as follows:
  1. Meet the Prerequisites.
  2. Create an Enhanced Profile.
    1. Configure Baselines.
    2. Publish QoS Data.
    3. Configure Alarm Thresholds.
    4. Use Variable Substitution to Create Custom Alarm Messages.
Create an Enhanced Profile
Determine what you want to monitor in your environment and create the corresponding enhanced profile. You can create an enhanced profile for each device or you can create a group configuration profile that MCS applies to all devices in a group. Use the profile types that are displayed in the middle panel of the
Monitoring
tab to create enhanced profiles. You can easily recognize an enhanced profile by the profile name, which includes the word
Enhanced
. Depending on the enhanced profile that you are creating, the available fields might vary. Hover your mouse over any field in an enhanced profile to see the tooltip for that field. Scroll to the right to see all the available configuration options while creating it. 
Follow these steps:
  1. In USM, select the desired group or device.
  2. Click the
    Monitoring
    tab.
  3. In the MCS middle column, select the desired enhanced template. The template name has "Enhanced" added to it; for example, DNS Response (Enhanced).
  4. Click the plus icon.
  5. Enter the required information in the relevant fields.
  6. For metrics and alarm definition configuration, depending on whether the policy_mode_enabled parameter is set to true or false, appropriate sections are displayed. The policy_mode_enabled parameter is present in the
    timed
    section of the MCS configuration file. The default value of the parameter is true.
    • If the value is true (which is the default value), the
      Metrics
      section is displayed in the UI for metrics configuration. The following screenshot shows that the
      Metrics
      section is displayed in the UI:
      Alarm_Policy_Enhanced_Profile.png
      To add alarm and threshold information in this case, use the alarm policy functionality in the Operator Console. You cannot add this information in UMP when the policy_mode_enabled value is true. To complete the remaining tasks, skip Step 9 through Step 16 in this procedure.
    • If the value is false, the
      Metric Collection and Alarm Definition
      section is displayed for metrics and alarms configuration. This section displays the
      Metrics
      ,
      Alarms
      , and
      Time Over Threshold
      sections. The following screenshot shows that the three sections are displayed in the UI:
      Enhanced_Profile_All.png
      In this case, you configure the alarm and threshold information in UMP.
  7. Select the Metrics (QoS) that you want to modify from the available list in the
    Metrics
    section.
  8. Click
    Publish
    , and then click
    Baseline
    .
    Note
    : If you do not select
    Publish
    or
    Baseline,
    CA UIM collects QoS data for any metrics that you have selected, and computes baselines, but does not publish them. Dynamic thresholds (Scalar, Percent, Std Dev) require baselines. Baselines are computed automatically for any thresholds that you configure, but are only published if you select
    Publish
    .
  9. Select an alarm
    Type
    .
  10. Select an algorithm to use:
    • None - Select None if you do not want to generate an alarm.
    • Static - Each threshold is a constant value from actual/last value.
    • Scalar - Each threshold is a specific value from the computed baseline.
    • Percent - Each threshold is a specific percentage of the computed baseline.
    • Std Dev - Each threshold is a measure of the variation from the computed baseline. A large standard deviation indicates that the data points are far from the computed baseline. A small standard deviation indicates that they are clustered closely around the computed baseline.
  11. Set the threshold for each alarm state. Select an operator for the threshold:
    • >
      An alarm occurs when the metric is greater than the set threshold.
    • > =
      An alarm occurs when the metric is greater than or equal to the set threshold.
    • <
      An alarm occurs when the metric is below the set threshold.
    • <  =
      An alarm occurs when the metric is below or equal to the set threshold.
    • =
      An alarm occurs when the metric is equal to the set threshold.
    • !=
      An alarm occurs when the metric is not equal to the set threshold. 
  12. Enter a numeric value for each threshold.
  13. Select a severity for each threshold:
    • Info
    • Warn
    • Minor
    • Major
    • Critical
  14. (Optional) Create a custom alarm message for your environment:
    1. In the
      Alarm Message
      field, enter or select variables to include in a custom message. For a complete list of supported variables, see the "Supported Alarm Policy Message Variables" section in the plugin_metric article.
    2. In the
      Clear Message
      field, enter the message to display when the alarm clears. For a complete list of supported variables, see the "Supported Alarm Policy Message Variables" section in the plugin_metric article.
  15. Select
    Enable
    to enable a Time Over Threshold alarm.
  16. Configure the TOT settings so that you have the desired ratio of minutes to either hours, days or minutes:
    1. Time Over
      - Enter the number of minutes.
    2. Within
      - Enter a number.
    3. From the drop-down list, select
      Hours
      ,
      Days
      , or
      Minutes
      .
      For more information, see The Time Over Threshold Event Rule.
  17. Click
    Create
    or
    Save
    .
The following example screenshot shows an enhanced profile:
Enhanced_Profile.png
Enhanced profiles support the configuration of Time Over Threshold alarms but do
not
support configuration of Time
To
Threshold alarms. Use the Admin Console UI to configure Time to Threshold values for those probes that support the Time to Threshold configuration. For more information, see The Time To Threshold Event Rule.
Migrating and Converting Existing Profiles
Review the following considerations before you start migrating your existing MCS profiles:
  • Migrate your existing non-enhanced profiles to the latest available version (non-enhanced)
    before
    you convert them to enhanced profiles
    :
    1. Migrate your existing non-enhanced profiles to the latest available version (non-enhanced).
    2. Convert your existing profiles to enhanced profiles.
  • Do not rename either your existing MCS non-enhanced profile or the enhanced MCS profile that is created when you enhance a profile.
    • When you enhance a profile (for example, "C"), MCS creates an enhanced profile with a similar, associated name (for example, "c"). The enhanced "c" profile is deployed, and the original "C" profile is suppressed.
    • The similar, associated names enable you to delete the enhanced profile and revert to the original profile. If you break the association between the original profile "C" and the enhanced profile "c" by renaming either profile, you
      cannot
      delete the enhanced profile and revert to the original profile. Therefore, we recommend that you keep the name of both the existing MCS profile and the enhanced MCS profile that is created from it.
  • Upgrading from a previous CA UIM version to CA UIM 9.0.2.
    • If MCS profiles are already available for older MCS templates before the upgrade:
      • Enhanced templates will not be visible in UMP by default.
      • If you migrate these existing legacy profiles to the latest legacy template, the enhanced templates will be visible in UMP.
    • If no MCS profiles are available for older MCS templates before the upgrade, then the new legacy and enhanced templates will be visible in UMP.
  • For new CA UIM 9.0.2 installation.
    • Both legacy and enhanced templates are visible in UMP.
Migrate Your MCS Profile
Migrate your MCS standard profiles to the latest available version (non-enhanced) before you convert them to enhanced profiles. 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.
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 can control whether 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. We recommend you to leave the value in
false
if you have recently upgraded your UIM environment.
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. If you then execute the
    activate_probe_templates_package
    callback command, the probe templates package continues migrating until all the existing profiles are migrated to the latest versions of the probe templates.
  6. If all of the existing profiles are migrated successfully, the probe templates package transitions to a "migrated" state.
  1. 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.
  2. 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.
Convert an Existing Profile to an Enhanced Profile
You can convert your existing MCS profiles to enhanced profiles. We recommend that you first migrate existing profiles to the latest available version (non-enhanced) and then convert them to enhanced profiles. 
Follow these steps
:
  1. Access USM.
  2. In the MCS middle pane, select the desired profile.
  3. In the profile, select the
    Enhance this profile to use centralized alarm configuration (any changes will be lost)
    option.This option is not available when you create a new enhanced profile or when the profile is already converted to an enhanced profile.
    Wait for some time for the profile migration to complete. Do not click Save button after selecting the checkbox.
    The enhanced profile is deployed, and the original profile is suppressed.
    If you select the enhance option and the profile is not converted to an enhanced profile, you must first migrate the profile to the latest available version before MCS can convert it.
Alternatively, you can also use the Infrastructure Management interface to perform this task:
  1. Access the IM interface.
  2. Select
    mon_config_service
    .
  3. Press
    Ctrl+P
    .
  4. Select
    enhance_profiles
    from the drop-down list.
  5. Select the
    profile_ids
    parameter.
  6. Enter the profile ID value for the profile that you want to convert to an enhanced profile.
  7. Click the Run button.
    The
    Command Status
    value is shown as
    OK
    . This implies that the profile is converted to an enhanced profile.
When you convert your non-enhanced profile to an enhanced profile, a corresponding alarm policy is created if the policy_mode_enabled parameter is true. Creation of this alarm policy adds threshold values present in the non-enhanced profile to the plugin_metric. You can use the alarm policy functionality in the Operator Console to update this created alarm policy. The creator of this alarm policy is displayed as
CA profile migration
in the Operator Console.
Example
This example describes how a corresponding alarm policy is generated when a non-enhanced profile is converted to an enhanced profile. In this example, the group profile is overridden at the device level. The group profile is a Windows group profile; the device included in the group is sahF919.
  1. The following screenshot shows the group level CPU Monitor (non-enhanced) profile in UMP:
    Step1.jpg
  2. The following screenshot shows the device level overridden CPU Monitor (non-enhanced) profile in UMP:
    Step2.jpg
  3. The following screenshot shows the device level CPU Monitor profile after it is converted to an enhanced profile in UMP:
    Step3.jpg
  4. The following screenshot shows the two alarm policies that are generated in Operator Console when non-enhanced profile is converted to an enhanced profile. One alarm policy is generated for the group profile and the other for the overridden device profile:
    Step4a.jpg
  5. The following screenshot shows the group level alarm policy with the thresholds in Operator Console:
    Step4.jpg
  6. The following screenshot shows the device level alarm policy with the thresholds in Operator Console:
    Step5.jpg
Frequently Asked Questions
If I do not want to use enhanced profiles, can I still install or update to CA UIM 9.0.2?
Yes, you can still install or update to CA UIM 9.0.2.
Do I need to upgrade all my robots to use the enhanced profiles?
To use enhanced profiles, you must deploy a robot version 7.96 on the groups or devices that you want to monitor. For supported remote probes, such as vmware, deploy the robot on the same device where the probe is deployed (this might be your primary hub).
Do I need to upgrade all my profiles to use the enhanced profiles?
No, you do not need to upgrade all of your profiles simultaneously to access the new features available in enhanced profiles. You choose which, if any, of your existing MCS profiles that you convert to enhanced profiles.
How do I correct the plugin_metric file?
When you create an alarm policy or an enhanced profile, its configuration information is written in the plugin_metric file.
In robot versions prior to 9.10/9.10S, 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 UMP 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 SP1.
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.
What are the additional scenarios when converting migrated profiles to enhanced profiles?
The scenarios that are discussed in this section are applicable for these conditions:
  • When the migrated non-enhanced profile is converted to an enhanced profile.
  • When robot is 7.96
  • When policy_mode_enabled=true.
When the maximum profile size is one (that is, you can create only one profile instance for a given profile template), the following use cases are applicable:
Device Level
  • A device can have only one profile that is deployed on it for a given profile template. Therefore, when you convert a non-enhanced profile to an enhanced profile, a corresponding alarm policy is created for that device profile.
    Alarms are generated for that alarm policy.
Group Level
  • Group includes multiple devices; group profile is not overridden at the device level
    • A group (Group 1) includes two devices Device 1 and Device 2. Group 1 has a group profile that is applied to it. The same group profile is deployed to the devices (Device 1 and Device 2). You migrate the group level profile to the latest template and then convert the migrated profile to an enhanced profile. In this case, a corresponding alarm policy is created for the group profile.
      Alarms are generated for the same alarm policy.
  • Group includes multiple devices; group profile is overridden at the device level
    • A group (Group 1) has two devices Device 1 and Device 2. Group 1 has a group profile. This group profile is overridden on one device (Device 2). In this case, when the migrated profile is converted to an enhanced profile, two corresponding alarm policies are created. One alarm policy for group profile and the other for device profile (which has overridden profile).
      In this case, the metric_precedence is high for the overridden scenario. This precedence is considered by spooler for alarm generation. metric_precedence is available in the plugin_metric.cfg file.
  • Multiple groups include multiple devices; group profiles have the same priorities
    • Group 1 includes two devices Device 1 and Device 2. Group 2 includes two devices Device 2 and Device 3. Group 1 has the CPU Monitor profile with the priority of 100. Group 2 also has the CPU Monitor profile with the priority 100. In this case, one alarm policy is created for Group 1 and the other for Group 2. That is, alarm policy is created for each group profile. For devices that are part of multiple groups, all the alarm policies are applicable.
      Alarms are generated for each alarm policy.
  • Multiple groups include multiple devices; group profiles have the different priorities
    • Group 1 includes two devices Device 1 and Device 2. Group 2 includes Device 2 and Device 3. Group 1 has the CPU Monitor profile with the priority of 100. Group 2 has the CPU Monitor profile with the priority 200. In this case, one alarm policy is created for Group 1 and the other alarm policy for Group 2. That is, alarm policy is created for each group profile. For devices that are part of multiple groups, all the alarm policies are applicable.
      Alarms are generated for the alarm policy that is created from the profile having the highest priority.
  • When you delete a migrated enhanced profile, corresponding policy is also deleted.
  • If a device is part of multiple groups and only one group profile is converted to an enhanced profile for the same template, it will lead to unpredictable results.
    Example: Group 1 has Device 1. Group 2 also has Device 1. Group 1 has Profile 1 and Group 2 has Profile 2. If only one profile (Profile 1 or Profile 2) is migrated and converted to an enhanced profile, it will result into unpredictable results.
  • If hierarchy of profiles exists, all the child profile thresholds are added as conditions under the parent policy.
  • After alarm policy creation, if you modify the enhanced profile, the alarm policy configuration is not changed. For example, if you change the profile priority, the corresponding alarm policy is not changed.
  • After converting the migrated profile to an enhanced profile, for the corresponding alarm policies, the alarm policy creator is shown as
    CA profile migration
    .
Can I change the policy_mode_enabled value to false?
By default, the policy_mode_enabled value is set to true. We recommend that you do not change this default value.
When the policy_mode_enabled value is true:
  • For enhanced profiles that you create in UMP, use the alarm policy functionality in Operator Console to set the threshold information.
  • For enhanced profiles that you create in UMP, a default alarm policy is created if the probe template includes default threshold values. The creator of the default alarm policy is displayed as
    CA default policy
    in Operator Console.
  • For non-enhanced profiles, there is no change in the existing behavior. All the thresholds are set in UMP.
When the policy_mode_enabled value is false:
  • For enhanced and non-enhanced profiles, all the thresholds are set in UMP.
  • No default alarm policy is created for enhanced profiles.
If you change the value to false, you must follow these additional steps:
  1. Disable all alarm policies in Operator Console.
  2. In UMP, perform the required actions depending on the following scenarios:
    • For the migrated profiles (non-enhanced) that are converted to enhanced profiles, open the profile and save it again.
    • For the newly created enhanced profiles, open the enhanced profile, provide threshold values, and save the enhanced profile.
What happens to my MCS profiles that I do not upgrade to enhanced profiles?
Any MCS profiles that you do not convert to be enhanced profiles are applied as usual.
Do pre- and post-migration alarms get reconciled after migrating to enhanced profiles?
After you migrate to enhanced profiles, the already existing alarms (pre-migration alarms) and the new alarms (post-migration alarms) are not reconciled. That is, for the same condition breach, a new alarm is generated instead of updating the instance in the already existing old alarm.
What happens if I create a dynamic group and apply an enhanced profile to it, and then new devices that do not support enhanced profiles are added to the group?
When you apply an enhanced profile to a dynamic group, the enhanced profile configuration is applied to any new device that supports it. For those devices that do not support enhanced profiles, the most appropriate standard MCS profile is applied.
Can I change my mind about using the enhanced profiles and go back to using the standard profiles?
I have
not
changed the name of either the enhanced or the standard profile
:
Yes, if you have
not
changed the name of either the enhanced or the standard profile, you can go back to using a standard profile. Simply delete the enhanced profile. MCS then automatically reverts to the original, standard profile.
Note
: You will lose any configuration changes that you made since converting the original, standard profile to an enhanced profile.
I changed the name of either the enhanced or the standard profile
:
No, if you have broken the association between the original profile and the enhanced profile by renaming either profile, you
cannot
delete the enhanced profile and revert to the original profile.
Can I apply a standard profile and an enhanced profile to the same monitoring target?
Yes. You can apply both a standard profile and an enhanced profile to a group or device that supports enhanced profiles. For devices that support enhanced profiles, the enhanced profile takes precedence over the standard profile.
Note
: If you create and apply an enhanced profile to a group or device that does not support enhanced profiles, you see an alarm stating that enhanced profiles are not supported.
What does it mean if the only available profiles for a device are "Remote System Monitoring" and "Port Check"?
If the only available profiles for a device are "Remote System Monitoring" and "Port Check," then this indicates that
no
robot has been deployed on that device. Deploy a robot on the device, and then you will see all the MCS profiles available for the device. You must deploy a robot version 7.96 to see the available enhanced profiles. 
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