Pre-Con Education: CA Service Operations Insight Power User Crash Course

Pre-Con Education: CA Service Operations
Insight Power User Crash Course
Jeff Morris, Ahmed Kira & Kirk O’Quinn
CA Technologies
Session Number OCX47E #CAWorld
OpsCenter

2 © 2014 CA. ALL RIGHTS RESERVED.
Panel Session
Kirk O’Quinn
CA Technologies
Solutions Architect
Jeff Morris
CA Technologies
Principal Engineering
Services Architect
Ahmed Kira
CA Technologies
Advisor, Presales

Abstract
This 3 hour hands-on session will cover the key aspects of how CA Service
Operations Insight can integrate and correlate information from your many
domain management tools into cohesive service models, monitor and manage
your operations at the service level, and transform your NOC into a 21st century
Business Operations Center. Topics covered in this session include:
– Product Architecture and Overview
– Centralized Event Management
– UIM (Nimsoft) Integration
– Event Enrichment
– Cross-Domain Correlation
– Integrating SNMP data sources
– Notifications and Escalations
– Managing to the Service
– Service Modeling / Alert Propagation
– Advanced Topics / Troubleshooting
Jeff Morris
CA Technologies
Principal Engineering
Services Architect

Quick Show of Hands
Hands up if your organization owns CA SOI and has it deployed /
plans to deploy in the near future?

Agenda
SOI OVERVIEW
SOI ARCHITECTURE & CORE CONCEPTS
TROUBLESHOOTING
CENTRALIZED EVENT MANAGEMENT (+LAB)
MANAGING TO SERVICE (+ LAB)
ADVANCED TOPICS
1
2
3
4
5
6

The Problem: Too many tools, Services Cross Too Many
Silos
Silo Domain Managers do not provide a service-wide perspective
Service #1
Service #2
Service #3
Service #4
Service #5
Service #6
Client
Systems
Applications
Databases
Servers
Storage
Networks
Silos

IT Operations without Service Operations Management
The “Blame Avoidance” Game

Service Operations Management
Designed for the Today’s Dynamic Business and IT Environment
Service operations management
Comprehensive domain management
 Service-aware domain discovery, root
cause analysis, performance management,
triage and remediation
Unified event management
 Query, normalize, correlate cross-domain
events
 Manage and escalate alerts by policies
Dynamic business service modeling
 Real time cross-domain service discovery,
modeling and maintenance
Automated actions
 Initiates automated escalation,
synchronization and workflow based on
service impact and risk
Integrated service level
performance management
 Service performance and comparison
management
 Contractual service level management
Service analytics and alerts
 Analytics and alerting for service quality,
availability, impact and risk

Repeatable
Defined
Managed
OptimizedA five-phase approach
11
SOI: It is all about achieving IT maturity
Service-oriented → Lean →Event-oriented →
Initial
Silo-oriented → Business-oriented →
PhaseAttributes
Individual capabilities,
not processes
1
4
3
5
2
CA Service Operations Insight

Step 1: Consolidated Alarm Management in SOI
Alert
Queue
List
Alarms

Step 2: Service Modeling
UCS Blade &
Chassis
Virtual
Machines
Networking
Business
Transactions
Application
Components
ESX Host
Ant Trail
Indicating
Root Cause
Location

Business
services listed
according to:
 Business
importance
 Quality level
 Risk to quality
 Business and IT
subservices
Real-time
service
status
indicators
Historical
service
status
details
Step 3: Service Visualization for all Stakeholders
SLA Health
Quality Risk
Availability
14

SOI Architecture and Core Concepts

SOI Core Concepts
2 Configuration Item
3 Infrastructure Alert
4 Service
5 Service Alert
To plan a successful installation, you need to understand the
terms and concepts used in CA SOI.
1 Catalyst / USM

SOI Architecture

1
CA Catalyst: Vendor Agnostic Integration
Multiple CA and 3rd Party Integrations available today or in development
CA Catalyst

Unified
Connector
Framework
Unified Connector
Framework
Product
Adaptor
CIs, Events, ServicesActions on Silo
MDR
CA Catalyst Bus
EI
USM
EI provides policy
based data
transformation and
normalization
services for the UCF
The Unified
Connector
Framework (UCF)
exposes standarized
interfaces for building
high quality,
consistent
integrations, whether
CA or 3rd party
UCF, Product
Adaptor and EI
Policy = Catalyst
Connector

22 © 2014 CA. ALL RIGHTS RESERVED.22 © Computer Associates 2010
Catalyst integration platform
MDR1
MDR2
MDR3

A configuration item (CI) is a representation of an IT element managed by a domain
manager converted to USM format.
Configuration Item
Element Managed by Domain
Manager (CA Spectrum)
Corresponding CI
in CA SOI

Correlation Definition
Correlation identifies related CIs managed across multiple domains. Correlation happens
automatically in CA SOI. No additional OOTB configuration is required.
Each domain ‘projection’ of the CI is added to a single ‘USM Notebook’
In this example, APM, eHealth and Spectrum are all projecting what they know about the
system ‘TIXCHANGE-3.ca.com’ into USM, and those projections have been automatically
correlated together into a single logical representation

Reconciliation Definition
Reconciliation determines which pieces of domain data are the most reliable, and
assigns them to the logical ‘reconciled’ (merged) representation of the CI

An infrastructure alert is a fault condition detected by a domain manager – these are
automatically forwarded to SOI by the connectors.
Within SOI, alerts are automatically associated with the corresponding CI, and will be
mapped to an SOI Severity.
Infrastructure Alert

Service
The concept of a service model, or service, is central to CA SOI (We’ll be exploring
them in much more detail later)

CA SOI generates service alerts based on the impact of related infrastructure alerts.
Service alerts have a corresponding Root Cause alert to quickly identify the highest
impacting infrastructure condition affecting the service
Service Alert

Service
Impacting
Alerts
Alerts
Events
ReduceQuantity,IncreaseQuality
The Event Management Pyramid
Root
Causes

Unified Alert Management Architecture
Non-Service Impacting
Alerts

 Leverages existing Catalyst Connectors as ‘Event Collectors’
– Connectors modified to store historical events and expose interfaces
to enable federated queries and remote configuration of policies
Unified Event and Alert Management Architecture

What is an Alert Queue?
 Filtering Mechanism for Alerts within the SOI Console
 Traditional Event Management Concept
 Allows different teams to be focused on alerts for CIs which
they are responsible
– (i.e. Windows, Linux server teams)

Alert Queues Tab Operations
Use the toolbar or
the right-click
context menu to:
Define a new
queue
Edit an existing
queue
Delete an existing
queue

Define an Alert Queue

Assign Escalation Policy to Alert Queue

Assign User Groups to Alert Queues

Confirm and Save the Queue

Confirm New Queue Exists

Control Alert Queue Access
Two methods are available for defining
Alert Queue access:
Using the Alert Queue wizard
when defining a new queue and
when editing an existing queue
On the Users tab, select a User
Group and add queue access using
the Alert Queues Access tab
The Alert Queues Access tab
provides similar functionality
as the Service Access tab

Creating Escalation Policies and Actions

Escalation Policies and Actions
 Escalation Policy
– Filter or criteria for related alerts
– Alert queue can be defined as the filter
– Additional Time criteria for when to take action
 Escalation Actions
– Action to be taken on all alerts matching
– E-mail, create SD Ticket, run custom script, Clear Alert, etc.

Escalation Management
Escalation Policies
 Policy can be triggered based on any property of the alarm including the user defined
properties that can be set through enrichment
 You can define escalation policy to include or exclude alarms for escalation based on:
– Class or Instance of impacted CI
– Symptoms or root cause conditions
– Alarm severity or service impact
– Alarms impacting CIs or services in Maintenance
– Alarms that have not been acknowledged, assigned or ticketed within a given timeframe, or simply
based on the age of the alarm itself
 Policy can take account of service business hours and can be assigned a schedule (calendar)
to determine whether it should be applied

Escalation Management
Escalation Actions
 Once an alarm has been identified as a candidate for escalation, you can then
assign appropriate actions to take, including:
– Sending an email
– Raising a trouble ticket
– Executing a command
 When invoking an action you can substitute in elements of the alarm or the
impacted CIs and Service as parameters
 The results of any action are stored in the alarm as an annotation so you have the
full audit trail associated with the alarm and any attempts to diagnose or
remediate the condition
 SD tickets and alarms are synchronized so if either is assigned, or closed, that can
be reflected back to the other

Define an Escalation Policy
Specifying automatic actions to occur in response to various
conditions helps ensure the policies are escalated
in a timely and effective manner.

An escalation policy can be global or service specific.
Policy Types

Global escalation policies are applied to services on an all or none basis.
Service specific escalation policies are selectively applied to services.
Policy Types Continued

Policy Criteria
Escalation policies can be based on different criteria.
Act on alerts based on attribute value
Act on alerts based on alert type
Act on alerts based on time threshold

Schedule
The escalation schedule identifies when the policy is active.

One or more actions can be performed when an escalation policy is triggered.
Policy Actions

E-mails can be customized and tailored using data from the alert triggering the action
E-Mail Actions

Schedule Maintenance
Services and CIs require regular maintenance.
Maintenance schedules identify regular maintenance time periods.
Specifying how maintenance mode affects the impact of CIs and services
enables you to define an effective escalation policy.

The Operational Mode indicates the current maintenance status.
Production
Maintenance
Operational Mode
Maintenance
Mode Icon

Maintenance Mode Impact Propagation
Global settings control impact propagation for CIs in maintenance mode.
Propagate
Maintenance
Impact = Yes
Propagate
Maintenance
Impact = No

Maintenance Mode Alert Escalation
Alert escalation behavior for CIs and services in maintenance mode is specific to each
escalation policy.

Define Maintenance Schedules
The Maintenance Schedules subview provides the means to create new schedules.

Event Policy – Filtering / Enrichment

Event Streams Can Be Overwhelming
Managing events is like
managing a fire hose…
Too much volume
Impurities
Inconsistent composition

Event Filtering and Normalization is Key to Success
Ultimately, the Alert Console
should contain:
Minimum volume
Maximum quality
(articulation of problem)
Consistent composition
(same schema)
SOI Alert Console

Open the Event Policy Dialog
Define Event Search Criteria

Specify Simple Event Patterns
Define Event Search Criteria
When searching for multiple events using the Any criterion, the
search is satisfied if an event occurs that meets any of the
specified search patterns.

Open Create Event Policy Dialog
Define Enrich Event Policy
Click the Create
Policy button

Define Event Policy

Cross-Domain Event Correlation

Define SOI Alert Queues based on
Spectrum Global Collections or Custom
Attributes

Interface to Map Additional Attributes from
CA Spectrum to CA SOI
New Configuration file AdditionalAtrributes.xml
Following format used to add the additional model attributes
<Models>
<Attribute id="attribute id" name="attribute name"/>
</Models>
Example:
<Models>
<Attribute id="0x23000d" name="Location"/>
<Attribute id="0x23000c" name="ContactPerson"/>
<Attribute id="0x12adb" name="CollectionsModelNameString"/>
</Models>
 Connector needs to be restarted to apply the changes

Interface to Map Additional Attributes from
CA Spectrum to CA SOI
 Map the new attributes in CA Spectrum policy file to transfer
these attributes to Catalyst
<Field output=“CIUserAttribute1" format="{0}" input=" Location "/>
 You can also map to user-defined USM property, in case
relevant target property is not found

CA SOI UI Showing Additional Attributes
Showing Location, ContactPerson and CollectionsModelNameString in user attributes

Creating a new alert queue based on new attribute
Creating Alert queue to show alerts on CIs belonging to global collection ‘uiop’

Event Management Lab (20 minutes)

Event Management Lab
 Experiment with Alert Queues
 Create an Escalation Policy / Action for your Alert Queue to
send yourself an e-mail notification
 (Optional) Experiment with Event Policy
– Filter or Enrich an incoming event
– Should impact your Alert Queue

What is a Service?
 Different meanings to different people
– Often considered somewhat synonymous with application
 Business Service
– A suite of application components and associated infrastructure working together to provide a
specific named value to the organization and/or its customers
– i.e. “On-Line Bill Pay“
 IT Service
– Somewhat more low-level – may not have a front end
– Components of many business services
– i.e. “VOIP"
75

Service Topology
Service propagation
based on:
- Alarm Severity
- CI Significance
- Relationship type
• Letter (O) depicts
relationship type
• Number (8) depicts
significance of child CI
on scale of 1-10

CI Severity
 Severity indicates the condition of a CI.
Severity Color Description
Normal (0) Green Operational
Minor (1) Yellow A nominal displacement of CI function that may or may not merit inspection
Major (2) Orange A serious causal change typically leading to degradation of function
Critical (3) Red High probability of imminent failure and severe degradation of service
Down (4) Burgundy The CI is incapable of providing function or service

CI Severity Continued
 Severity values do not propagate from child to parent.
– The impact of CI severity is propagated.
– The impact is derived from the fault condition asserted on a CI and the
significance value assigned to that CI.
Parent
Children
Severity values are
assigned to CIs with
directly associated
alerts

Significance
 A value that states how important a CI is to a related item

Significance Continued
 Default significance values are established for each CI class
type.

Impact
 Identifies what CI fault conditions really mean to the service
that the CIs support
Impact Color Description
0 Green Operational
1 – 10 Yellow Slightly degraded
11 – 20 Orange Moderately degraded
21 – 30 Red Severely degraded
31 – 40 Burgundy Down
Severity
Normal (0)
Minor (1)
Major (2)
Critical (3)
Down (4)
Impact
0
1 – 10
11 – 20
21 – 30
31 – 40
x =

Impact Continued
 Impact values are propagated.
Impact is
propagated to
related CIs.

Groups
 Groups are intermediate objects that relate CIs to one
another by some role or function.
Group

Propagation Types
 Propagation Types determine how impact values are
propagated.
– Aggregate
– Bound
– Custom
– Operative

Aggregate Propagation
 Aggregate propagation indicates a general-purpose
relationship that propagates impact from one CI to another.

Bound Propagation
 Bound propagation indicates a bidirectional relationship
between two CIs.

Custom Propagation
 Custom propagation indicates that one CI may depend on
several other CIs for some behavior or function.

Operative Propagation
 Operative propagation indicates a related item is affected only
if the impact value of a CI exceeds a defined threshold.

Relationship Types
 Relationships refine how impact values are propagated.

Custom Propagation Policy
Custom policy further refines how impact is propagated for the IsAffectedBy and
IsEvolutionOf relationship types.

Normal Granularity
Service Granularity
Normal granularity
Direct alerts from low level CIs explicitly included in the Service model are
assigned to the low level child object
• Direct alerts are alerts that are instantiated directly against the object
• Low level CIs belong to classes that fall beneath the Top Level classes

Service Granularity
 Low granularity (LoFi)
– Direct alerts are assigned to low level child objects
 The assigned low level child alerts behave as standard managed alerts
– Alerts from low level child CIs not included in the Service model are
intercepted and propagated to the parent CI
– The association is established by matching the device ID
– The Low Fidelity Impact icon denotes the presence of a low granularity
alert
Low Fidelity
Impact icon

Service Granularity
 Low Granularity Example
Direct alert
LoFi alert

Import Services
 Domain managers such as
CA Spectrum Infrastructure Manager, CA
APM, and CA CMDB have service concept.
 Previously defined services in domain
managers can be imported into
CA SOI.
– This leverages your existing investment.
– This establishes that CA SOI should manage
the service.
– The imported services can be modified and
extended.

Auto Import Services
 When Auto import is set to Yes for a connector:
– All existing domain manager services are immediately imported.
– Any new domain manager services are also imported after they become
known to the connector.
Some connectors are not
Auto import capable.
The Auto import toggle
buttons are located here.

Manual Service Import
 Accomplished using the Import Services dialog.

Working with Service Discovery
Service Discovery allows you to define policies that will
automatically build and maintain services in real time
1 Understanding SD Policy Types
2 Navigating the SD Policy Editor

SD Policies
Three types of policies are supported:
– Dynamic Services
 Define policies to place relevant CIs (system-wide) in a service
– Automatic Relationships
 Define policies to connect matching CIs (system-wide)
– Unmanaged Relationships
 Define policies that establishes managed relationships from existing
unmanaged relationships

Navigate the SD Policy Editor
SD policies are defined in the Policy Editor.

SD Policy Editor UI
Access from the SOI Console
 To access the SD Policy Editor,
click Tools > Service Discovery Policies.
 At startup, with the root node selected,
the right pane displays SD policy
descriptor revision details.

SD Policy Editor UI
During Operation, when a policy group is selected in the left
pane, the right pane displays the list of policies that fall beneath
the selection.

SD Policy Wizards
 Context sensitive menus provides access to SD policy wizards.
– The menus are triggered from the navigation tree node.
– The Create, Add, and Modify actions launch the respective policy
editor wizard.

Define Dynamic Service Policy
1 Define Service
2 Confirm
3 Confirm Step Validation
SD policies determine what services are
automatically created and maintained.

Step 1: Define Service
Panel space is
reserved for
messages
Required input
fields are marked
with an asterisk (*)

Step 2: Confirm

Step 3: Confirm Step Validation
 Warning messages identify when the validation process identifies
problematic service definition policies.

Define Automatic Relationship Policy
1 Source Criteria
2 Target Criteria
3 Match Criteria
SD policies determine what relationships are
automatically created and maintained.
4 Relationship Scope
5 Confirm

Step 1: Source Criteria
Panel space
is reserved
for messages
Required input
fields are marked

Step 2: Target Criteria

Step 3: Match Criteria

Step 4: Relationship Scope
All Services or Specific Services

 SD Engine Relationship Scope Processing
1. Identify CI pairs fitting the SOURCE, TARGET, and MATCH criteria
2. For each CI pair, identify Services containing the SOURCE CI that fit the
Relationship Scope specification
1. Add the SOURCE->TARGET relationship defined by the policy
to each Service within the identified set

Step 5: Confirm

Define Unmanaged Relationships
Domain manager knowledge of unmanaged relationships
can be easily used to extend the managed relationship
hierarchy within CA SOI services
1 Default Behavior
3 Define Unmanaged Relationship Policy
2 Unmanaged Relationship Discovery

Service
Computer
System
Port
Published by
the connector
Created in
CA SOI
Unmanaged Relationship
• Invisible in CA SOI Service Topology
Managed Relationship
• Scoped to the Service
Default Behavior
 Relationships published by connectors are unmanaged
– MDRs are not aware of the services in which CIs are used and so are
unable to scope the relationships to CA SOI services.
– The unmanaged relationships are not part of nor visible in the CA SOI
service topology.
– Alert impact from unmanaged CIs is not propagated to the service.

Service
Computer
System
Unmanaged Relationship Discovery
 Establishes managed relationships from unmanaged
relationships
– Looks for unmanaged relationships whose source CI is in a Service
– Creates a managed copy of the relationship scoped to the same service
as the source CI
 Implemented as a new Service Discovery policy type
Port
Published by the
connectorCreated in
CA SOI
Managed Relationship
• Starts in a managed CI
• Scoped to the service
• Created by the policy

Step 1: Relationship Criteria
Required input
fields are marked

Step 2: Source Criteria
Class value of
Entity covers all
other classes

Step 3: Target Criteria
Class value of
Entity covers all
other classes

Step 4: Match Criteria (Optional)
Match Criteria are not
required for Unmanaged
Relationships policy

Identify which
Services to apply
the policy against

Step 6: Confirm

Service Modeler Demo /
Instructor-Led Lab (5-10 minutes)

Manual Service Creation
 Manually create this service. Append service name with your
initials
1. Create Child Service:
OnlineOrderingCustomer
2. Create OnlineOrdering
Service
3. Create 2 groups
4. Drag and drop CI’s to define
service

Service Modeling Free Lab (20 minutes)

Service Modeling Lab
 Create a manual service model
 Use the relationships and propagation rules to manage state propagation of
infrastructure events
 Create a Custom (Group) Policy in your Service Model
 Create an Escalation Policy / Action to Escalate only when the
service state is degraded

Using Event Enrichment to change
severity of Alerts

Example Alarms for which Severity could be updated to
‘Down’

Solution: Update Spectrum alarm severity
 Alarm Severity update treated as an enrichment policy
 Enrich Spectrum DEVICE HAS STOPPED RESPONDING TO POLLS
events to change the Severity of the alert from Critical to
Down

Update Spectrum alarm severity
 Open the Event Policy editor, enter the search criteria for Event Pattern 1 :
– Summary="DEVICE HAS STOPPED RESPONDING TO POLLS" or Summary="CHASSIS DOWN”
 NOTE: you can match on multiple events with the logical OR syntax, so one policy
can match many events.
 and then click the Search button and verify your pattern matches as expected
 Click on ‘ Create Policy’

Update Spectrum alarm Severity
From the Create Event Policy page, enter a policy name such as ChangeSev2Down,
then choose Filter Events - Include Events radio button, and then click Next >

Complete the enrichment page as follows:
Type: Script
Script Path: none
Script Name: none

Configure the Severity as desired (Minor, Major, Critical, Fatal (aka Down))

From the Select Data Sources Page, select the Save and Deploy policy radio button,
select the Event Management MidTier Connector data source from the Available
Data Sources list, click the right arrow to move it to the Selected Data Sources list, and
then click Finish.
Wait 1 minute for the event
policy to reload automatically
OR restart the CA SAM
Integration Services (IFW)
and CA SAM Event
Management services.

Integrating SNMP Events
(time permitting)

SNMP Connector Overview
 A generic data collection connector, receives SNMP traps from
any SNMP-capable product, transforms the traps, and maps the
generic SNMP attributes to the USM model
 Each domain manager requires a separate connector policy that
dictates the varbind to SOI attribute mappings
 Connector policy is XML-based and extremely flexible, offering
ability to parse, normalize data

Steps for Creating SNMP Connector Policy
1. Direct SNMP traps from domain manager to the SNMP Connector
2. Review the raw trap data received by Connector
3. Modify <SOI>/resources/Core/CatalogPolicy/snmp_policy.xml to
determine how CIs will be created from traps
4. Create the snmp_policy.APPLICATION.xml to determine format of the
Alerts created from traps
 SOI 3.2 includes a UI for creating and configuring this policy
5. Review results

1. Review Raw SNMP Trap Data Received by Connector

2. Modify snmp_policy.xml to Create CIs

3. Modify the Alert EventClass to Format Alerts

SOI 3.2 Event Policy UI Enhancement
Quickly and Easily Map Raw SNMP Trap Values Through the UI

 Six core Services
– SOI Manager (“CA SAM Application Server”)
 Tomcat application and core engine for SOI (listens on port 7090 for debug/admin pages)
– UI Server (“CA SAM User Interface Server”)
 Presentation Layer – hosts web GUI and launch point for console
 Also a Tomcat instance (by default listens on port 7070)
– IFW aka Integration Services (“CA SAM Integration Services”)
 Java application that hosts all connectors running on a given machine
 Communicates to SOI MGR via ActiveMQ messaging buss
– Event Management (“CA SAM Event Management”)
 Controls communication with the local Event Store, event queries, etc.
 Must be deployed wherever there is an IFW instance
– UCF Broker (“CA UCF Broker”)
 Supports the “Unified Connector Framework” (aka Catalyst)
 Southbound integrations – listens on port 8020
– Store Indexer (“CA SAM Store Indexer”)
 Indexing of USM data for display in USM Web View
 Must install on same host as “UI Server”
SOI Installed Services Tour

Troubleshooting SOI Connectors
 Connector architecture is very asynchronous
– First must isolate the root cause domain
 SOI Manager,
 Connector Framework (IFW)
 Domain Manager
– Use DEBUG mode of Log files to isolate

Where are the Log Files?
 <SOI>tomcatlogs
– Log files for SOI manager
 <SOI>jswlogs
– Service Logs
 <SOI>log
– Connector Logs
 <SOI>logdebugData
– Detailed debugging files containing CI files for the different connectors
 <SOI>SAMUIlog
– Logs for UI server

Configure Connector debugData
 Config file - <SOI>/resources/log4j.xml
 Make sure the following “logger” sections are uncommented
 Files will be located in <SOI>/log/debugData directory

For More Information
To learn more about DevOps, please visit:
http://bit.ly/1wbjjqX
Insert appropriate screenshot and text overlay
from following “More Info Graphics” slide here;
ensure it links to correct page
DevOps

For Informational Purposes Only
This presentation was based on current information and resource allocations as of August 2014 and is subject to change or withdrawal by CA
at any time without notice. Not withstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the
rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any
CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and
timing of any features or functionality described in this presentation remain at CA’s sole discretion. Notwithstanding anything in this
presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA will make such
release available (i) for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as
part of CA maintenance and support, and in the form of a regularly scheduled major product release. Such releases may be made available to
current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis. In the event
of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall
govern.
Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your
informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of
the information. To the extent permitted by applicable law, CA provides this presentation “as is” without warranty of any kind, including
without limitation, any implied warranties or merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be
liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment,
business interruption, goodwill, or lost data, even if CA is expressly advised in advance of the possibility of such damages. CA confidential and
proprietary. No unauthorized copying or distribution permitted.
Terms of this Presentation
Copyright © 2014 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong
to their respective companies. CA confidential and proprietary. No unauthorized copying or distribution permitted.

Pre-Con Education: CA Service Operations Insight Power User Crash Course

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à Pre-Con Education: CA Service Operations Insight Power User Crash Course

Similaire à Pre-Con Education: CA Service Operations Insight Power User Crash Course (20)

Plus de CA Technologies

Plus de CA Technologies (20)

Dernier

Dernier (20)

Pre-Con Education: CA Service Operations Insight Power User Crash Course