Image by “r reeves,” used with Creative Commons license permission*, originally published on Flickr.com.

For CA Unified Infrastructure Management

The Email Gateway (emailgtw) probe converts alarms from the CA Unified Infrastructure Management NAS server into emails sent to designated recipients.

Or to share the love, you can specify multiple recipients. Whether you are creating one or multiple profiles, the procedure is the same.

Create a Profile

1. In the probe configuration GUI, click the Options icon (…) next to the Profiles node in the navigation pane.
   
2. Click the Add Profile option, which appears when you click the Options (…) icon.
3. Update the field information and click Submit.
   
4. Repeat the process to add additional profiles.

If you ever need to delete a profile, don’t worry, that’s easy.

Delete a Profile

1. Click the Options icon next to the profile name node that you want to delete.
2. Click the Delete Profile option.
3. The profile is deleted.

To learn more about this and other probes for CA UIM, visit the CA Technologies Product Documentation wiki and use the drop down menu, here, to navigate to the CA UIM Probes wiki.

As always, we’d like to know what you think of this and other Cookbook articles. So, let us know by taking the survey on Survey Monkey.

*For more information about the Creative Commons license, go here.

Comparing data for various parameters across distributed networks is crucial to performance analysis, but creating a separate dashboard for each option can be time-consuming.

The Challenge: Find a simple means to view comparable data for different systems, data centers, or devices at different time intervals.

The Solution: A new tool in the CA Unified Management’s Dashboard Designer gives users the ability to change views quickly within a single dashboard, giving one dashboard the function of many.

This capability is provided by the new dashboard context widget. By changing context parameters, data displayed in dashboard widgets reflect ad hoc choices without generating a new dashboard or updating data sources.

The widget contains three types of selectors: Time, Custom, and Dashboard. Here’s how they work.

• In the Time selector, the user can select a time period from a dropdown menu, ranging from the last hour to the last 12 months. The selector passes start-time and end-time values to the dashboard parameter list; all SQL data sources in the dashboard that use these parameters pick up those values; and the resulting data is displayed at runtime. Selecting a different time interval from the menu passes new values to the parameter list, and the dashboard automatically updates.

• In the Custom selector, the designer can draw from a variety of data sources: a website, SQL query, dynamic database, or static table. The selector can accommodate up to two columns of data, any SQL values are likewise passed to the parameter list, and the dashboard updates output.

• In the Dashboard selector, the current dashboard is linked to other dashboards. Selection allows easy navigation between dashboards. In addition, if both contain similar context selectors, parameter values pass from one dashboard to the next. In this way, dashboards that display similar data choices for different locations can be linked in a coordinated series.

So, for example, selectors could be created to display comparable information for different data centers and time periods. The user would select a time period from the Time selector menu, a data center from a list defined in a Custom selector to display data for that data center and time interval. After viewing the initial results, the user can then change the time period or data center and run the dashboard again to view the new results. If drill-down data is needed, the user can open a linked dashboard created separately, with selected parameters passed to that dashboard. Any parameters changed in that linked dashboard are likewise passed back to the first dashboard.

This one-to-many relationship within and across dashboards provides system administrators with a means to view data dynamically without having to create multiple dashboards, rewrite SQL queries, or change data sources within dashboard widgets. Context selectors extend the usefulness of a single dashboard, supporting the ease and speed of data retrieval: the wider window to system data.

To learn more about CA’s UIM dashboards, visit the wiki documentation here.

And, as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

All Frame and No Picture by Kevin Dooley (2009), used with Creative Commons license permissions*, originally published on Flickr.com.

*For more information about the Creative Commons license, go here.

The release of UIM version 8.1 introduced new functionality called UDM.  With the introduction of UDM brought many questions – namely what does UDM stand for?  No – it isn’t “U Da Man”, though how great would it be to have such confidence boosting naming integrated in a product? The reality is that the UDM naming piggy backs on the Unified Infrastructure Management naming schema. UDM stands for Unified Data Management. To be clear, the naming isn’t intended to suggest anything about the direction of the database development in UIM. It is merely a consistency strategy that helps us align with the Unified Infrastructure Management product branding.

In addition to questions about the UDM naming, there are additional questions about what UDM brings to the table for UIM – what value does it bring to the product? To understand this, we need to delve a little deeper into what UDM is.

UDM is a new functionality that integrates a graph-based Datomic database in the existing UIM architecture. The Datomic database (as implemented in UIM) consists of three major pieces:

• A transactor – manages initialization, shares connection strings, handles write queries, and sets up schemas. The Datomic Transactor in UIM is represented by the UDM Manager probe. The UDM Manager probe is a service probe that is bundled with the core UIM server product. When you install UIM Server, the UDM Manager probe automatically activates. It requires very little configuration, if any, in most standard installations.
• Peers – jvm libraries that communicate with the Datomic datastore through the transactor. Peers contain their own local read cache that can be used for read queries. In UIM v8.1, the Datomic peers are included in Discovery Server, UGS, and USM. Implementation of the peers in these components provides advanced network interface management.
• Datomic_kvs – an SQL table that represents the UDM datastore in the existing NIS tables in the UIM database. Datomic peers retrieve connection information for the datomic_kvs table from the UDM Manager probe. They can then retrieve data from the datomic_kvs table and store it in their local cache for read queries. Peers send write queries to the datomic_kvs table through the UDM Manager probe.

The image below illustrates how the Datomic components were integrated with the existing UIM components in the 8.1 release.

So what does UDM do for me?  UDM provides a means to optimize inventory and topology management within UIM. The UDM functionality provides:

• a sophisticated graph-based relationship management
• extensible entity types and composition
• easy management of changes to the database over time

The development for UDM is being phased with the initial phase implemented in UIM v8.1.  In this initial phase, advanced network interface management was introduced. Data that is written to the NIS tables is also written to the UDM datastore. The data that is being written to the UDM datastore cannot be queried using standard SQL queries, as there is no public API available. As development continues, additional functionality will be leveraged.

For more information about configuring the UDM Manager probe, go to the UDM Manager probe documentation. For more information about Datomic, see the official Datomic documentation.

For CA Unified Infrastructure Management:

The ability to create groups in USM allows a network administrator to view performance metrics for similar devices in a network. Now, grouping has been extended to interfaces in order to view traffic metrics—for example:

• Utilization % in/out
• Errors % in/out
• Discards % in/out
• MAC address
• Device speed

Interface grouping supports selection of interfaces by type or attribute.

There are three types of interface groups:

• Container – A parent to other groups.

• Dynamic – Interfaces that meet a specified set of criteria. The membership of dynamic groups is updated automatically as new devices are discovered that meet the criteria.

• Static – A user-created list of computer interfaces. The membership of the list does not change until interfaces are manually added or removed.

As a network monitor, you can use interface groups to filter your infrastructure view by location, technology, or even service. For example, you could create a container group for a business service that holds dynamic and/or static groups for web, application, and database servers.

This capability gives users a single place to go to view the performance of interfaces within and across a network.

For more information on creating interface groups in the Unified Service Manager, see the CA wiki documentation here.

And, as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

American Cootville (Fulica americana) by Ingrid Taylar, used with Creative Commons license permissions*, originally published on Flickr.com.

*For more information about the Creative Commons license, go here.

For Unified Infrastructure Management

After you install NAS on a hub with the SNMP Data Monitoring (snmpcollector) probe v2.0, have you ever received duplicate alarms? If you do, check your NAS configuration. Set up NAS as an event responder on the primary hub.

For CA Unified Infrastructure Management

Today in Computer History:
Twenty-nine years ago and, “Nearly eleven years after its founding, Microsoft began trading stock on the NASDAQ stock exchange.”

Today in Your Cube:
Your end-users and you depend on Microsoft applications and servers.

Did you know that CA Infrastructure Management has probes specifically designed to monitor your Microsoft stuff so that you can take care of business? Here are a few:

• Active Directory Response (ad_response)
  Monitors the availability of the Active Directory, which is integrated in most Windows Server operating systems
• Microsoft Exchange Monitoring (exchange_monitor)
  Monitors the performance of an Exchange server, generating quality of service (QoS) and alarm messages on a set of performance related statistics and parameters
• Microsoft Exchange Server Monitoring (ews_response)
  Monitors the end-to-end performance of your Microsoft Exchange server connection by sending and receiving test e-mails
• Microsoft SharePoint Server Monitoring (sharepoint)
  Monitors both Sharepoint Services and Sharepoint Server

For more information about these and other probes, visit the CA Technologies Product Documentation wiki and use the drop down menu, here, to navigate to the CA UIM Probes wiki.

As always, we’d like to know what you think of this and other Cookbook articles. So, let us know by taking the survey on Survey Monkey.

Frank’s Birthday, by prettyinprint, originally published on Flickr.com and used here with Creative Commons license* permissions. *For more information about the Creative Commons license, go here.

For CA Unified Infrastructure Management

Today in Computer History:
On this day in 1928, “Jean Sammet, an early pioneer of computing, is born in New York…” She wrote what The Computer History Museum calls, “one of the classic histories of programming languages,” Programming Languages: History and Fundamentals. And in 1961, while working at IBM, she developed FORMAC, “the first commonly used language for manipulating non-numeric algebraic expressions.” 

Today in Your Cube:
You know that your end-users rely on IBM servers and applications to take care of business. 

Did you know that CA Infrastructure Management has probes specifically designed to monitor the health and performance of your IBM stuff so that you can take care of business? 

• The IBM VM Monitoring (ibmvm) probe monitors the IBM virtualization enabled systems.
• The IBM DS Monitoring (ibm_ds) probe monitors the IBM DS mid-range disk storage solutions for small to large enterprises.
• The IBM SVC Monitoring (ibm_svc) probe monitors the IBM System Storage SAN Volume Controller (SVC) and IBM V7000 storage systems.

For more information about these and other probes, visit the CA Technologies Product Documentation wiki and use the drop-down menu, here, to navigate to the CA UIM Probes wiki.

As always, we’d like to know what you think of this and other Cookbook articles. So, let us know by taking the survey on Survey Monkey.

A simple SNMP network contains three basic components:

• The Network Management System (NMS) with the network management software. In this example, the NMS is running Unified Infrastructure Management (UIM) with the snmpcollector probe.
• The managed device.
• The SNMP agent software that runs on the managed device.

Uses for SNMP

Simple Network Management Protocol (SNMP) provides management of network devices from a host system to network devices running SNMP agents. Some examples of the types of network devices you can monitor are servers, routers, switches, firewalls, load balancers, printers, and IP phones. The host system that you use to manage these devices is the NMS.

Network administrators can use SNMP to manage various types of devices, and the scope of the management activities can vary. Some examples of the types of monitoring activities that can occur are, network performance monitoring, network fault detection, security issue detection, and remote device configuration.

Protocol Standards

SNMP is an internet standard protocol that you use for network monitoring. The Internet Engineering Task Force (IETF) has defined three Request for Comments (RFC) documents that describe the basic SNMP protocol. The following documents are the set of RFCs that provide a basic definition of the standard:

RFC 1157 - Simple Network Management Protocol (SNMP) that defines the application layer protocol. This protocol controls how communications happen between devices that support SNMP and the types and formats of SNMP messages.

RFC 1213 - Management Information Base II (MIB2) that defines a set of data objects that provide information about various components such as systems, interfaces, and networks.

RFC 1902 - Structure for Management Information (SMI) that defines the database schema including the object syntax for referencing and storing MIB data.

Versions of the SNMP Protocol

Three versions of the SNMP protocol exist.

SNMPv1 - This revision is the initial implementation of the protocol.

SNMPv2c - This revision of the protocol contains new features which include the getbulk requests and provided informs, and new message formats.

SNMPv3 - This revision of the protocol contains additional security features which include authentication and encryption capabilities.

NMS Function

One NMS can manage many managed devices. The NMS provides the platform for the applications that can monitor and control the managed devices. The NMS typically performs the following functions.

• Poll managed devices for management data with get, getnext, and getbulk operations.
• Receive unsolicited alerts such as traps and informs from managed devices.
• Configure the managed devices with set operations in some cases.

Managed Device Function

The managed device is a network device that contains an SNMP interface. This interface provides read-only or read/write access to device-specific management data.

SNMP Agent Function

The SNMP agent is a software module that is located on a managed device. The SNMP agent provides access to local device data for the NMS. The agent generally listens on UDP port 161 or port 10161 for secure communications, but many agents allow you to configure alternate ports. The SNMP agent can also send unsolicited alerts or traps. These traps usually have destination UDP ports 162 or 10162.

The SNMP agent contains the Management Information Base (MIB). The MIB describes the structure of the data in a hierarchical namespace that contains MIB Object Identifiers (OIDS). The OIDs identify variables. Each variable contains values that the NMS can read or set with the SNMP operations such as get, set, getnext, or getbulk. SNMP has an extensible design that allows the MIB to be enhanced.

CA’s Unified Infrastructure Manager (UIM) has numerous data visualization options for presenting system data. Of these, four support readily customizable, dynamic views of system metrics:

• Performance Reports
• List Reports
• Unified Reports
• Dashboards

Reports vary as to content and format to suit specific needs:

Performance Reports use drag-and-drop to overlay line graphs of various QoS data for quick comparison of metrics over time. Reports are iterative and dynamic, can be easily changed according to need, and can be saved as templates that can be applied by different groups of users.

List Reports display tabular data for sets of systems or other components. A variety of data visualization options are available for metrics, attributes, and alarms.

Unified Reports combine graphical and tabular elements in a highly customizable display of data. Reports include internal scheduling and advanced tools for output and summary.

Dashboards contain graphical and tabular views of system metrics from multiple data sources, including SQL queries and webpages. Dashboards can also be linked for drill-down into system data.

Of the four, all but the last can be saved to PDF. Individual dashboards can be accessed through browsers.

Which reporting mechanism is right for you? Here are some suggestions:

• Use the performance report when you are doing troubleshooting and wish to do visual correlation of multiple metrics on the same axes. This is the easiest report to generate and alter.
• Use the list report for tabular views that are dynamically assembled for different metrics. This type of report is the most formal in terms of format and output.
• Use a dashboard to create live views of metrics or alarms designed for presentation on screen. This type of report has the greatest number of customizable elements and so requires more time to define.
• Use the unified reports for highly customized presentation of data for export to PDF for export and distribution to non-UIM users. Given the number of display options, this report requires the most time to configure.

With these choices available, there’s an optimal way to present network data and communicate that information to system administrators, managers, engineers, support personnel, and customers.

To learn more about CA’s UIM dashboards, visit the wiki documentation here.

And, as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

20111006-NodeXL-Twitter-Kickstarter network graph by Marc Smith (2011), used with Creative Commons license permissions*, originally published on Flickr.com.

*For more information about the Creative Commons license, go here.

For CA Unified Infrastructure Management

SNMP enabled device information is not automatically added to the snmpcollector probe device inventory. You must import the device data into the snmpcollector probe configuration GUI.

Import Device Information

The discovery_server probe runs on the primary hub. This probe collects information about the devices on the network. The discovery process generates a list of information for each device. This information includes the device name, IP address, and SNMP credentials. You import this list of device data from the snmpcollector configuration GUI, and this information appears in the probe configuration GUI as device profiles.

The following diagram shows how device discovery data flows through the primary hub and the secondary hub.

Secondary Discovery and Device Correlation

The device information that is presented to snmpcollector does not initially contain any subcomponent information. The snmpcollector probe uses the IP addresses and SNMP credentials to run a secondary discovery process. The secondary discovery process finds device component information. The probe then returns the updated inventory to discovery_server.

The two inventories are reconciled within discovery_server before the information appears in USM or the probe inventory. Rules that are located in discovery_server control the reconciliation process. These rules can affect how metric information is displayed within USM.

The following diagram shows the device discovery process flow.

Click here for more information.

For CA Unified Infrastructure Management Snap

Snap-bot is doing his best ta-da arm gesture because he’d like to introduce you to Snap 8.2.

With this latest version of Snap, you can:

• Add and manage account users, including their ACL permissions, within the Account Admin portlet.
• View a saved dashboard in a browser window outside of UMP. This allows you to view a dashboard from a remote location at any time.

Download Snap 8.2 here.

Check out the new Snap documentation wiki here.

And as always, we’d like to know what you think of this and other Cookbook articles. So, let us know by taking the survey on Survey Monkey.

Dashboards make critical realtime data readily understood. Wouldn’t it be useful to access your dashboards at any time and from any remote device? Well, you can!

Any dashboard can be accessed through a web browser pointed at the server running the Unified Management Portal. A URL identifies the server, the dashboard folder, and the dashboard of interest, and opens the dashboard in a browser window.

Setup

To be accessible to a device within the network, the dashboard must be published within the Dashboard Designer, with visibility set to ‘Public’, ‘Account’, or ‘No Account’ according to the intended viewers. In addition, users accessing dashboards must have appropriate permissions to do so.

Dashboards can be saved and published in folders for specific user groups. This helps organize the dashboards according to the users for whom they were created.

The Call

To access a known dashboard, enter a URL with the following format in a browser address field:

http://(server)/dashboard/jsp/standalone.jsp?path=folder/file

where “(server)” is the IP address or DNS name of the server where UMP is running and the dashboard is stored, and “folder/file” is the folder and file names under which the dashboard was saved.

On connecting to the server, you will be asked to sign in. Then, the dashboard will appear in the browser window.

If you don’t remember the folder or dashboard name, you can enter the URL without the path:

http://(server)/dashboard/jsp/standalone.jsp?

After you log in, the window will take you to a window listing the folders and dashboards for your visibility setting. You can select from any of those dashboards.

Open and view! Dashboard queries run when the dashboard is opened, giving you up-to-date information on systems and performance at any time and from any web-enabled device!

To learn more about CA’s UIM dashboards, visit the wiki documentation here.

And, as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

Photo of a telescope on the Eiffel Tower by Elias Gayles (2014), used with Creative Commons license permissions*, originally published on Flickr.com.

*For more information about the Creative Commons license, go here.

For CA Unified Infrastructure Management

The SNMP Data Monitoring (snmpcollector) probe associates specific metrics with a device or device component during secondary discovery. The probe implements this behavior by using metric family, vendor certification, and vendor priority files.

Metric Families

A device is subdivided into components by snmpcollector. A component can represent physical components such as CPUs or memory, or logical components such as interface jitter or HTTP response. Metric Families organize all of the metrics that pertain to a component into a comprehensive catalog of metrics.

In most cases, only a subset of the metrics in a metric family are supported by a particular component vendor. For example, a metric family for CPUs contains the metrics cpuUserUtilization, cpuSystemUtilization, and cpuIdleUtilization. A CPU from a particular vendor might only support the cpuSystemUtilization and cpuIdleUtilization metrics.

The following diagram shows an example metric family.

Vendor Certifications

A vendor certification is a library of metric definitions for a specific device from a specific vendor. Many vendor certification files exist in snmpcollector. Each vendor certification file contains device specific:

• Vendor OIDs
  Vendor certifications can contain a subset of the OIDs found in the original vendor MIBs.

• Metric definitions
  A metric definition is either an OID which is associated with raw data from the device or an expression that uses an OID in a calculation. The metric definitions are used to generate the metrics for a device which you can view in USM.

The following diagram shows how vendor certifications are associated with a metric family.

Vendor Priorities

Vendor priority files list vendor certifications according to specificity. The most specific vendor certifications are at the top of the list and the most generic vendor certifications are at the bottom of the list.

During secondary discovery, snmpcollector sequentially moves through the vendor priority list searching for key OIDs. The vendor certification provides these key OIDs. The first vendor certification that matches the key OIDs is assigned to the device component. Since each vendor certification file is associated with specific metric definitions, the appropriate metrics are generated for a device component. The pollagent probe retrieves the data for the metrics from the device.

The following diagram shows how a vendor priority file identifies the appropriate vendor certifications.

Click here for more information.

For CA Unified Infrastructure Management

There are two ways to monitor devices in the SNMP Data Monitoring (snmpcollector) probe. You can enable monitors within the probe configuration GUI or through the use of templates. The use of templates is the preferred method because they enable bulk configuration of the entire probe inventory. The ppm probe is required on the primary hub, and any remote hub with snmpcollector to support templates. Template files are stored in the local snmpcollector file system, but the template editing functionality is a component of Admin Console. Once you apply or activate monitoring, pollagent collects the specified metric data.

The following diagram shows how monitoring configuration data flows from the remote hub to the primary hub.

Click here for more information.

For CA Unified Infrastructure Management

Have a question about CA Unified Infrastructure Management (CA UIM)?

Join us this Tuesday, May 12th, from 10-11AM EST for Office Hours for CA UIM.

This is your chance to connect with CA Technologies technical experts via Webex chat. And this is our chance to connect with you. Let us know what you think during this chat, or any time by taking the survey on Survey Monkey.

For CA Unified Infrastructure Management

In today’s application economy, businesses rely on IT more than ever. Yet IT teams are challenged by reduced resources and shrinking budgets. Using the fragmented strategies of the past just won’t work anymore.

Join us for a webcast that will answer your questions about what will work:

•What is a unified approach to infrastructure management?
•How can this approach help you build agile operations and increase efficiency?
•How can you extend capacity planning across IT and the data center?
•How can CA Technologies help you?

When:
May 20, 10:00-11:00 am (US Pacific Time)

What:
In a BrighTALK webcast “Redefining IT Infrastructure Management for Today’s App Economy,” Jose Mora, Jeremy Rossbach, and Umair Khan of CA Technologies reveal how a holistic and unified approach to IT infrastructure management can help you.

We hope to “see” you there.

And as always, we want to know what you think of this and other cookbook articles. Let us know by taking the survey on Survey Monkey.

For CA Unified Infrastructure Management

In the SNMP Data Monitoring (snmpcollector) probe, QoS and alarm data is forwarded to the primary hub by two different processes. QoS data is passed from the remote hub to the primary hub through queues on the message bus. Queues must be configured for QOS data (QOS_MESSAGE and QOS_DEFINITION), and probe_discovery.

Every remote hub with snmpcollector must have baseline_engine, prediction_engine, alarm_enrichment, and NAS installed to enable threshold alarms. The baseline_engine probe monitors the message bus for QoS data that breaches the defined thresholds. The predictive_engine probe is required to enable TimeToThreshold settings, and the alarm_enrichment probe is required to enable TimeOverThreshold settings. As alarm messages occur, the data is passed on to the primary hub through NAS.

Matching versions of NAS must exist on the primary hub and the remote hub so that alarm messages can be forwarded to the primary hub. In order to avoid duplication of alarms, the instance of NAS on the remote hub must be configured as an event responder.

The following diagram shows how QoS and alarm data flows from the remote hub to the primary hub. Click the diagram to view an enlarged image.

Click here for more information.

This article applies to CA Unified Infrastructure Management v8.2.

We’ve been making changes to the probe GUI displayed in Admin Console. Much of what you see in the probe’s GUI is dependent on the version of ppm running on the hub that hosts a probe. For a list of probes that can be configured with Probe Provisioning, see the ppm Release Notes.

Starting with CA UIM v8.2, ppm v3.11, baseline_engine v2.5 and prediction_engine v1.2 are bundled together. When you deploy ppm v3.11 to a hub, baseline_engine v2.5 and prediction_engine v1.2 are also installed. The reason…ppm displays the user interface (UI) but baseline_engine and prediction_engine are required if you want to configure dynamic, static (if applicable), and Time To Threshold alarm and threshold settings for monitoring probes. In addition, if you want to configure Time Over Threshold alarm and threshold settings, you’ll need to deploy the nas package comprised of the alarm_enrichment v4.67 and the nas v4.67 probe. The alarm_enrichment and nas probes are also required for alarm processing.

For fresh installs of CA UIM v8.2, ppm and the nas package are automatically deployed to the primary hub when you run the CA UIM Server Installer.

Upgrading

If you upgrade from CA UIM v8.0 or CA UIM v8.1 to CA UIM v8.2, you’ll need to deploy ppm v3.11 on the primary and all applicable secondary hubs and the nas package to at least the primary hub.  You cannot upgrade to ppm v3.11 from an earlier version of ppm.

Matching Versions

Whether you’re installing CA UIM v8.2 or upgrading to CA UIM v8.2, it’s important that you have the same probe versions running on all hubs. This means with CA UIM v8.2, the following versions of the probes are deployed (or at the very least are in the Local Archive in Admin Console) and activated on hubs:

• ppm 3.11
• baseline_engine v2.5
• prediction_engine v1.2
• alarm_enrichment v4.6
• nas v4.6

And as always, we want to know what you think of this and other cookbook articles. Let us know by taking the survey on Survey Monkey.

This article applies to CA Unified Infrastructure Management v8.2.

We’ve been making changes to the probe GUI displayed in Admin Console. Much of what you see in the probe’s GUI is dependent on the version of ppm running on the hub that hosts a probe. For a list of probes that can be configured with Probe Provisioning, see the ppm Release Notes.

Starting with CA UIM v8.2, ppm v3.11, baseline_engine v2.5 and prediction_engine v1.2 are bundled together. When you deploy ppm v3.11 to a hub, baseline_engine v2.5 and prediction_engine v1.2 are also installed. The reason…ppm displays the user interface (UI) but baseline_engine and prediction_engine are required if you want to configure dynamic, static (if applicable), and Time To Threshold alarm and threshold settings for monitoring probes. In addition, if you want to configure Time Over Threshold alarm and threshold settings, you’ll need to deploy the nas package comprised of the alarm_enrichment v4.67 and the nas v4.67 probe. The alarm_enrichment and nas probes are also required for alarm processing.

For fresh installs of CA UIM v8.2, ppm and the nas package are automatically deployed to the primary hub when you run the CA UIM Server Installer.

Upgrading

If you upgrade from CA UIM v8.0 or CA UIM v8.1 to CA UIM v8.2, you’ll need to deploy ppm v3.11 on the primary and all applicable secondary hubs and the nas package to at least the primary hub.  You cannot upgrade to ppm v3.11 from an earlier version of ppm.

Matching Versions

Whether you’re installing CA UIM v8.2 or upgrading to CA UIM v8.2, it’s important that you have the same probe versions running on all hubs. This means with CA UIM v8.2, the following versions of the probes are deployed (or at the very least are in the Local Archive in Admin Console) and activated on hubs:

• ppm 3.11
• baseline_engine v2.5
• prediction_engine v1.2
• alarm_enrichment v4.6
• nas v4.6

And as always, we want to know what you think of this and other cookbook articles. Let us know by taking the survey on Survey Monkey.