pre-con ed: upgrading to ca service management

Pre-Con Ed: Upgrading to CA Service ManagementIndrajit Banerjee - Sr. Services Architect - CA TechnologiesGary Eisenhuth - Sr. Services Architect - CA Technologies

AMX36E

AGILE MANAGEMENT

3 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD

© 2016 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.

The content provided in this CA World 2016 presentation is intended for informational purposes only and does not form any type of warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.

For Informational Purposes Only Terms of this Presentation


Agenda

SERVICE MANAGEMENT COMPONENT OVERVIEW

WHY UPGRADE?

HOW CAN WE HELP?

UPGRADE APPROACH

SWING BOX MIGRATION METHOD

SERVICE MANAGEMENT UPGRADE TIPS AND TRICKS

1

2

3

4

5

6


CA Service Management UpgradeService Management Product Components

CA Service Desk Manager– Incident / Problem / Request; Change / Configuration; Issue; Knowledge Management– Support Automation; CA Configuration Automation

CA Service Catalog– Request Fulfilment

CA IT Asset Management– CA Asset Portfolio Management

CA Server Management Common Components– CA Process Automation; CA Embedded Entitlement Manager; CA Business Intelligence;

CA Unified Self-Service


Why Upgrade?


Would it Make Sense for you to Upgrade?

Upgrade introduces new/innovative features

It combats and/or reduces cyber security threats

It eliminates legacy customizations by using out-of-box functionalities

It maximizes uptime with improved solution architecture

Has better administrative capabilities and improved service delivery efficiency

Stay up-to-date and be fully supported

Easy future upgrades

YES


The Upgrade Approach


ConsExisting and legacy configurations are migrated over both from data and application perspective

Upgrade done in the current production environment – which means higher risk

UsageWhen the same existing hardware is to be used.

When MDB (database) is shared with other applications that cannot be upgraded.

ProsAllows the use of existing hardware

Allows co-existence of older version applications (subject to compatibility)

Upgrade ApproachIn-Place Upgrade


ConsAdditional cost of new hardware; need for temporary hardware for SWING environment

UsageWhen new hardware / OS / database is to be used.

When MDB (database) is not shared or is shared with other applications that are either already updated or will be updated.

ProsAllows the use of new/latest hardware with current OS / database versions

The remains of the legacy customizations and previous upgrade are cleaned up

Less risk as current production environment is untouched

Upgrade ApproachSwing Box Migration


SWING Box Migration MethodCA Service Desk Manager Migration

Secondary Secondary

NewPRODUCTION HW

CA SDM R14.1Fresh Install

Primary

Primary

UpgradedMDB

SWING BOX / PROD

CA SDM Rx.xUpgraded to

CA SDM R14.1

Primary

MDB

SWING BOX / PROD

CA SDM Rx.xFresh Install

TEMPORARY VIRTUAL Environment Required for Migration

UPGRADE PATH

Copy MigratedSite SpecificAdaptations

CopyUpgraded dB

MDB Upgraded toR14.1 Schema

ApplicationUpgraded to R14.1

&Forms

Migrated to R14.1

MDB

Secondary

BEFORE AFTER

Secondary SecondarySecondary

CurrentPRODUCTION HW

CA SDM Rx.x

Primary

MDB

Upgraded forms of R14.1 moved over

CopyExisting dB

CopySite SpecificAdaptations

CA SDM R14.1Fresh Install


SWING Box Migration StrategyCA Service Desk Manager Deployment Architecture Change

Database (MDB)Server

SecondaryServer-1

PrimaryServer

StandbyServer


PrimaryServer

SecondaryServer-2

SecondaryServer-3

CA BIServer

ApplicationServer-1

ApplicationServer-2

ApplicationServer-3

CA BIServer

Rx.x Data Transfer

Rx.x Configuration

Transfer

CURRENT SDM RX.X PRODUCTION ENVIRONMENT

NEW SDM R14.1PRODUCTION ENVIRONMENT

NEW SDM R14.1 PRODUCTION ENVIRONMENT


BackgroundServer

StandbyServer

ApplicationServer-1

ApplicationServer-2

ApplicationServer-3

CA BIServer

Overall Data Migration Path

Traditio

nal A

rchite

cture

Advance

d Availa

bility

Configurat

ion


PrimaryServer

SWINGENVIRONMENT

R14.1Migrated Data

R14.1Configuration

PROD Ready – No changes

Production Migration – Target Servers

Current PROD - Untouched

Rx.x: r11.2 to R12.9


Upgrade Stages – Backup Milestones

ENVIRONMENTFreshInstall

Copy Rx.x dB

Rx.x PROD Replicated

R14.1 Migration Complete

Copy R14.1

Migrated dB

Reconfigure NEW PROD with

migrated data

Pre-Go Live

TESTING Go-Live

Current Production

Backup / Snapshot Points

SWING Environment


NEW Production


Rx.x

HE

RE

HE

RE

Rx.x

HE

RE

R14.1

HE

RE

Rx.x Rx.x R14.1

R14.1 R14.1

HE

RE

R14.1

HE

RE

R14.1

CUT-OFF

GO-LIVE

Planned Downtime

HE

RE


Upgrade Approach

CA Service Management Documents– https://docops.ca.com/ca-service-management/14-1/en [English]– https://docops.ca.com [All Documents]

Choose CA Service Management Select the Language of your choice

CA Service Management Community– https://communities.ca.com/community/ca-service-management

The place to share ideas, tips, information, insights, and more with your business peers and CA Technologies experts.

Useful Links

HERE ARE SOME USEFUL LINKS FOR YOUR UPGRADE GUIDELINES

https://docops.ca.com/ca-service-management/14-1/en

https://docops.ca.com/

https://communities.ca.com/community/ca-service-management


CA Service Management UpgradeTips & Tricks


CA Service Management Upgrade – Tips & Tricks

Upgrade decision on method to choose– Which way to go depends on your current version: Stepped or Direct Path– Stepped: May have In-Place followed by Swing-Box migration– Direct Path: Can choose any approach: In-Place or Swing-Box– Fresh Install: With partial data migration

Plan for backups– Virtual Environments: Plan to take multiple snapshots during the course of the

upgrade procedure. This saves time in case you need to revert to a certain point.– Temporarily allocate additional disk space for backups

CA Service Desk Manager



Plan for at least two (2) environments– Development and Production environments should be considered– If only Production environment is available, use SWING as Development environment

Resource Planning– Make sure you plan for the availability of necessary resources at the right time.

Database Administrator – necessary during database upgrade, for backups and restoration, any immediate troubleshooting

Network Administrator – manage / resolve any network communication issues System Administrator – ensure system availability, system level backup / snapshot activities. Access to the Core Team – Escalations, communication and decision making




Prepare Execution Plan– Decide on the “To Be” Solution Architecture – Traditional or Advanced Availability– Identify which components sits in which system– Download all necessary media and distribute to respected systems– Synchronize production data over to the development environment (PROD DEV)– Build a checklist of all tasks to be performed during the upgrade/migration procedure– If time permits, plan for a dry-run to capture actual migration time, validate tasks and

record any possible issues and corresponding resolution– Make sure you have all access permissions necessary for the upgrade procedure




Migration Execution Strategy– In-Place upgrade:

Follow implementation guide and maintain suggested sequence

– Swing-Box method: Keep previously migrated DEV environment accessible to move forms data. Copy these files

to final target systems ahead of time Make sure you have the final target systems installed freshly (application and database) –

ready to go Remember: The purpose of the SWING environment is to migrate the current data to the latest

schema. It is not necessary to test the forms again in SWING environment. We will do that after the final migration is completed in the target systems.

Make sure you plan for the post-migration changes – DNS entry modification, load balancer re-configuration, firewall reconfiguration, SSL certificates (in case of new systems), event monitoring re-configuration, etc.



CA Process Automation Upgrade Planning

You must upgrade to version r3.1 S01 if your current version of CA Process Automation is r2.x, r3.0 or r.3.0 SP01

From version r3.1 SP01 up you may upgrade directly to 4.3 SP01

If you have customized configurations such as the oasis.config.properties file you should have the changes documented and backed up

You need to ensure your current hardware and OS will support CA Process Automation 4.3 when you upgrade

http://www.ca.com/us/services-support/ca-support/ca-support-online/product-content/status/compatibility-matrix/ca-process-automation-pam-4-3-compatibility-matrix-summary.html




In-Place versus New Install (Migration)

In-Place Upgrade is done on existing servers

In Place would occur on the existing hardware and Operating Systems

During the Upgrade the system is not available

Would use existing architecture

Migration New servers would be required to duplicate

the current environment Would allow PAM to be installed with new

hardware and Operating system that supports CA Process Automation 4.3

Allows for both environments to be run in parallel with no disruption to the production environment

Allows you to reconfigure and change the architecture

The CA Process Automation workflows will need to be migrated from the existing environment to the new one


CA Process Automation Upgrade Strategy Methods of Upgrade can be In-Place or Migration

Make backups and prepare for

the outage

Complete upgrade

prerequisites

Upgrade the Domain

Orchestrator or any DO node

Upgrade other Orchestrators

and all clustered nodes

Complete post-upgrade tasks

Test your processes with the upgraded Orchestrator

Switch load balancers from

Apache to NGINX

Update F5 pools, iRule

definition, and configuration

Configure agents to use

simplified communication

Test your processes with

simplified communication

Administrators


CA Service Catalog Upgrade Options

Migration you install on new hardware while pointing to the existing database and CA Embedded Entitlements Manager (CA EEM) servers.

Migration install works with the Swing Box method if your are also upgrading CA Service Desk Manager

Traditional you install CA Service Catalog onto an existing CA Service Catalog server

Traditional versus Migration


CA Service Catalog Upgrade Points to Consider

If you are running version 12.6 to 12.9, you may upgrade directly to version 14.1 using the Migration or Traditional model.

If you are running 12.5, you may upgrade directly to 14.1 using the Migration model. With the Traditional model you must upgrade to 12.6 first.

What configurations and customizations have been made to XML, XSL, or other CA Service Catalog files. The upgrade program installs new versions of these files.

Are the customizations backed up and documented?


CA EEM Upgrade

Upgrades are possible from r8.3 or higher to r12.0

Backup before you upgrade– Backup CA EEM data– Configuration files– CA Directory and iTechnology folders

Both In-Place and New Server upgrades are supported


CA EEM Migration Procedures

Export the CA EEM database to LDIF file from existing server

Install CA EEM r.12 on a new server

Import the LDIF file to the r12 server

Configure the User Store

Issue new certificate for each registered application using SAFEX command


How Can We Help?


Go-Live with CACA Service Management

Contact your CA Account Team when you are planning to upgrade– Your CA Account Representative will help you coordinate with the right resources

Inform CA Support on your Go-Live date / plans– Your CA Account Representative will help you register as a Hot-Site for additional support

during the final production migration

Engage CA Services for a smoother / risk free upgrade– CA Service Management Upgrade Services

Complete end-to-end management of the solution upgrade Quicker upgrade, less troubleshooting and downtime, rapid user adoption CA Services has the product expertise, proven methods, field experience, thought leadership


CA Service Management UpgradeIt is highly beneficial for any organization to keep up with the latest release of the CA Service Management product suite. It ultimately is cost effective considering the overall improvements and increased efficiency of service delivery achieved by any organization. It results in better application administration capabilities and more efficient use of time, which in turns means increased operational efficiency and higher end user satisfaction.

DO NOT HESITATE – ALWAYS GO FOR THE NEXT UPGRADE

Summary


Recommended Sessions

SESSION # TITLE DATE/TIME

AMX19S Case Study: Going from Zero to 100 in ITSM Without a Seat Belt at Michigan State University 11/16/2016 at 12:45 pm

AMX11S Case Study: Integrating Service Management Processes to Improve Systems Stability and Reduce Outages and Downtime

11/16/2016 at 1:45 pm

AMX120S It’s Time to Grow Up: 8 Areas to Increase ITSM Maturity 11/17/2016 at 1:45 pm


Must See Demos

Service Desk and Support Analyst xFlow Experience

Software and Hardware Asset Management

Request Management and Self-service

Management Insights –Reporting and Dashboards


Questions?


Thank you.

Stay connected at communities.ca.com