7.6.04 sp2_upgrade tips.pdf

www.bmc.com

BMC Remedy IT Service Management Suite 7.6.04 Service Pack 2 Upgrade Procedures and GuidelinesWhite Paper

Supporting

BMC Remedy Action Request SystemBMC Remedy IT Service Management Suite 7.6.04 SP 2

October 2011

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

UNIX is the registered trademark of The Open Group in the US and other countries.

The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation.

Restricted rights legendU.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

Customer support

You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”

http://www.bmc.com

Support website

You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support. From this website, you can

■ read overviews about support services and programs that BMC offers■ find the most current information about BMC products■ search a database for issues similar to yours and possible solutions■ order or download product documentation■ download products and maintenance■ report an issue or ask a question■ subscribe to receive proactive e-mail alerts when new product notices are released■ find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and

telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the issue

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

3

http://www.bmc.com/support

mailto:[email protected]

4 BMC Remedy Action Request System 7.6.04 Service Pack 2 Upgrade Procedures and Guidelines

ContentsChapter 1 Introduction 9

Supported upgrade paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9The role of overlays in an upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Upgrade paths and stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Servers used in the staged upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Required upgrade tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2 Staging server setup 17

Setup Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Setup Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Accelerated Staging Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Duplicated Staging Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Install the required software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Duplicating the Production Server Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 3 Upgrade with overlays present 25

Stage 1 - Upgrade AR System server with overlays present . . . . . . . . . . . . . . . . . . . . . 26Stage 6 - Upgrade applications and adjust customizations . . . . . . . . . . . . . . . . . . . . . . 27Stage 7 - Test and promote staging server to production . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 4 Upgrade without overlays present 33

Stage 1 - Upgrade AR System server without overlays present . . . . . . . . . . . . . . . . . . 34Stage 2 - Create overlays for existing customizations (optional but strongly

recommended) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Stage 3 - Acquire origin objects (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Stage 4 - Restore origin objects to the staging server (optional) . . . . . . . . . . . . . . . . . . 40Stage 5 - Minimize overlays (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Stage 6 - Upgrade applications and adjust customizations . . . . . . . . . . . . . . . . . . . . . . 43Stage 7 - Test and promote staging server to production . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 5 Fixing non-permitted modifications 51

Fixing non-permitted changes for objects that include __o in an object name . . . . . . 51Fixing non-permitted modifications for forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Changing the inclusion or exclusion of a form in a deployable application . . . . 52Changing unique indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Changing Vendor form information for Table Name or Vendor Name . . . . . . . . 53Changing Join form Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Changing View form information for Table name or Key field . . . . . . . . . . . . . . . 54

Fixing non-permitted modifications for fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Changing the data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Changing the Column properties on View and Vendor forms . . . . . . . . . . . . . . . 55Changing the Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Contents 5

Changing the Length Units property of Character fields . . . . . . . . . . . . . . . . . . . . 55Changing the Column field properties for Parent field ID, Data field ID and Data

Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Changing the Entry Mode —Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Changing the field type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapter 6 Comparing overlays to overlaid objects on the same server 59

Setting Migrator difference mask options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Comparing staging server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Chapter 7 Creating overlays with the Best Practice Conversion Utility 63

Usage overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Configuring your system for BPCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Using BPCU to generate difference reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Using BPCU to generate overlays for modified legacy objects . . . . . . . . . . . . . . . . . . . 69

Difference reports overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71BPCU log information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 8 Viewing differences between objects 75

Migrator Instruction Files and Difference Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Creating Difference Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 9 Delta Data Migration 77

Delta Data Migration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Restrictions on product activities during the delta data period . . . . . . . . . . . . . . . . . . 78Preparing the destination server for Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . 80

To disable DSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80To disable escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80To disable database triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80To fix backend data on the production server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Performing the Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82To resolve issues before Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83To perform data migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86To review the migration results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Extending Delta Data Migration to include customizations . . . . . . . . . . . . . . . . . . . . . 93Understanding the application package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Manually adding custom forms to the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Adding custom forms to the package by using the Customer Form Instruction

Generation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Updating a field mapping file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Performing Delta Data Migration for server groups. . . . . . . . . . . . . . . . . . . . . . . . . . . 100Resolving post-Delta Data Migration issues for BMC Service Request Management . .

102Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6 BMC Remedy IT Service Management Suite 7.6.04 Service Pack 2 Step-by-Step Upgrade Guide

Appendix A Overlay hash files 105

BMC product information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105BMC integration information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Obtaining the hash files for analyzing and converting customizations . . . . . . . . . . 108

Appendix B Migrator configuration options 109

Appendix C System objects that might be overwritten during upgrade 111

Contents 7

C h a p t e r 1
1 Introduction
This document describes the full end-to-end upgrade process for the 7.6.04 SP2 release of the BMC Remedy ITSM Suite. The following topics are provided:

■ “Supported upgrade paths”

■ “The role of overlays in an upgrade”

■ “Upgrade paths and stages”

■ “Servers used in the staged upgrade process”

■ “Required upgrade tools”

Supported upgrade pathsVersion 7.6.04 SP2 supports upgrades from the following product versions to SP 2 except for BMC Service Level Management (SLM), which remains at SP 1.

■ BMC Remedy Action Request (AR) System 7.0.01 patch 007

■ BMC Atrium 2.0.01 patch 004

■ BMC Remedy ITSM Suite 7.0.03 patch 009

■ BMC Service Level Management 7.1

■ BMC Service Request Management (SRM) 2.2

■ BMC Remedy Knowledge Management (RKM) 7.6.03

If you are also upgrading the following products, the staged upgrade process and Delta Data Migration tool supports migration of data for these products.

Introduction 9

The role of overlays in an upgrade

■ BMC Service Impact Manager (SIM) 7.1

■ Integration for BMC Remedy Service Desk 7.1.1

■ BMC ProctiveNet Performance Management (BPPM)

If you are at a version that is earlier than any of these, you must migrate to a supported version before you can upgrade directly to version 7.6.04 SP2.

The role of overlays in an upgradeIn BMC Remedy ITSM Suite 7.6.04, the overlays feature was introduced to preserve application customization. During an upgrade, the upgrade installers ignore application overlays and change only the objects that were originally installed with the application or server. After the upgrade, the application or server continues to use the overlays instead of the origin objects for runtime operations.

The following terms are used in the uprade process:

■ Custom object: A customer created object that is not distributed by BMC.

■ Origin object: An original unmodified object that is included with a released BMC software product.

■ Overlaid object: An origin object that has an overlay associated with it.

■ Overlay object: A customized version of an origin object that is used in place of the origin object. In this case, the origin object becomes and overlaid object.

■ Staged upgrade: A method that makes use of a staging server, which eventually becomes the new production server. This method has the least amount of server downtime when completing the upgrade.

For information about preserving customizations with overlays and custom objects in version 7.6.04 SP2, see the Form and Application Objects Guide, “Customizing objects,” page 119.


Upgrade paths and stages

Upgrade paths and stagesTo upgrade to 7.6.04 SP2, choose one of the following upgrade options.

■ Overlays already present: Upgrade with overlays already created

This is a three-stage upgrade for customers who have previously installed AR System 7.6.04 or 7.6.04 SP1 and have already implemented overlays.

■ Without overlays present: Upgrade with one-time conversion to overlays

This is a seven-stage upgrade for customers who do not already have overlays implemented and want to keep all customizations.

These stages are based on the assumption that your upgrade environment is already set up, and that you have created and verified a staging server. Stages 2 - 5 are performed once, when upgrading from a previous release that was customized without overlays. If you already captured customizations in overlays, stages 2-5 are not performed.

The following flowchart provides a brief overview of each of the main upgrade stages for the staged upgrade method.

Table1: Upgrade stages

Overlays already present

Without overlays Upgrade stage

X X “Stage 1 - Upgrade AR System server”

X “Stage 2 - Create overlays for existing customizations (optional but strongly recommended)”

X “Stage 3 - Acquire origin objects (optional)”

X “Stage 4 - Restore origin objects on staging server (optional)”

X “Stage 5 - Minimize overlays (optional)”

X X “Stage 6 - Upgrade applications and adjust customizations”

X X “Stage 7 - Test and Promote staging server to production”

Introduction 11


Stage 1 - Upgrade AR System server

In stage 1, the AR System server on is upgraded to 7.6.04 SP2. This stage must be performed before you can upgrade to newer versions of any BMC applications or other platform components.



After completing stage 1 you can upgrade and run your applications, or install new applications. If you customized your application without using overlays and you upgrade after this stage, your customizations will be lost.

Stage 2 - Create overlays for existing customizations (optional but strongly recommended)

In stage 2, you create overlays to preserve your existing customizations. The application installers for releases later than 7.6.04 SP2 are designed with the assumption that all customizations are captured in overlays. The installers for these releases will replace origin objects without attempting to preserve any changes that might have been made to those objects.

If you upgrade to versions of applications without completing this stage, you will need to reapply all of your customizations after upgrading, including additional custom fields and their data.

After completing stage 2, all customizations are captured in overlays and custom objects. This includes AR System customizations as well as all other applications and components.

Stage 3 - Acquire origin objects (optional)

In stage 3, which is optional, you acquire unmodified origin objects onto a reference server. The origin objects are used to compare with your overlay objects.

After completing stage 3, you can compare the overlays on your staging server to unmodified origin objects on the reference server. This allows you to see exactly what has changed in any object.

Stage 4 - Restore origin objects on staging server (optional)

In stage 4, which is optional, you move the 7.6.04 SP2 origin objects from your reference server to your staging server.

If you perform the procedures in this stage, when your upgrade is complete, you can run either the unmodified version of the application using only origin objects, or you can run your customized version that uses overlays in place of overlaid origin objects.

After completing stage 4, you have acquired copies of all of your origin objects in their original state. This does not affect any overlays that you created.

Stage 5 - Minimize overlays (optional)

In stage 5, which is optional, you minimize the number of overlays on your system. This reduces the analysis required on subsequent application upgrades or patch installations.

Introduction 13


When an overlaid object is modified during an upgrade, you should see if new functionality has been introduced that should be added to the overlay.

After completing stage 5, you have removed any unnecessary overlays on your system.

Stage 6 - Upgrade applications and adjust customizations

In stage 6, you upgrade all of your applications and AR System components to version 7.6.04 SP2. Any existing customizations to those items are preserved by making use of the overlays and custom objects that were created in previous stages.

After completing stage 6, you have upgraded your remaining AR System components and your applications. Any overlays whose origin objects were modified during the upgrade process have been identified.

Stage 7 - Test and Promote staging server to production

To test and promote the staging server to production:

1. Copy all modified data on your current production system to the staging server using the Delta Data Migration tool.

2. Promote the staging server to be the new production server.


Servers used in the staged upgrade process

Servers used in the staged upgrade processThe staged upgrade process allows you to upgrade your application and create overlays or otherwise address pre-existing customizations to your AR Server objects while your production server remains available to users. The following diagram shows the set of servers that might be required to perform the upgrade.

The server listed on the right side of the diagram at the top is a staging server for staged upgrades. Completing the optional upgrade stages 3, 4, and 5 requires a reference server and might require another server (referred to as the upgrade comparison server) to host upgraded applications. These additional servers do not have to be production quality, but they must have compatible software and a compatible database to hold referenced copies of the BMC software and database objects. The reference server and upgrade comparison server are temporary servers and are not needed after the entire upgrade process is complete.

Introduction 15

Required upgrade tools

Required upgrade tools If you are upgrading to version 7.6.04 SP2, familiarize yourself with the following BMC tools to help accelerate the upgrade process.

The following tools are required if overlays are not implemented in your system:

■ Best Practices Conversion Utility (BPCU): The BPCU helps identify platform and application customizations and convert them to overlays. For more information on the BPCU, see Chapter 7, “Creating overlays with the Best Practice Conversion Utility.”

■ BMC Remedy Migrator tool: The BMC Remedy Migrator tool helps you synchronize data among your BMC Remedy AR System development, staging, and production systems. For more information on the BMC Remedy Migrator Tool see the BMC Remedy Migrator Guide.

The following tool is needed to peform the staged upgrade, whether or not overlays are implemented:

■ Delta Data Migration tool: The Delta Data Migration (DDM) tool allows you to upload the data that changed on a production server during the time that a staging server was being upgraded. For more information on the Delta Data Migration tool see Chapter 9, “Delta Data Migration.”

The following tool is required for all upgrades:

■ BMC Remedy Developer Studio: The BMC Remedy Developer Studio is an integrated development environment (IDE) for BMC Remedy AR System applications. For more information on the BMC Remedy Developer Studio, see the Introduction to Application Development with BMC Remedy Developer Studio guide.

NOTE

BM

The upgrade process described in this document makes use of the BPCU and the BMC Remedy Migrator tool in working with overlays and custom objects. If you are very familiar with your application, you can choose to use the BMC Remedy Developer Studio to accomplish the same tasks.


C h a p t e r 2
2 Staging server setup
Use the information in this chapter to set up the staging server before running the upgrade process.

■ “Setup Overview”

■ “Setup Prerequisites”

■ “Accelerated Staging Server Setup”

■ “Duplicated Staging Server Setup”

Setup OverviewIf you are using the staged upgrade method, whether you already have overlays or not, you need to set up a staging server. There are two possible ways to set this up. The first way explained below is our recommended best practice method. It allows you to save time when upgrading, but it can only be used in certain circumstances. The second way requires more setup time, and is required for some specific types of upgrades.

■ Accelerated staging server setup: This staging server setup method accelerates the upgrade process, because it allows you to skip the product installation of your older AR System server and ITSM production applications. All you have to do is copy your production server database to the staging server before running the upgrade installer for AR System. This saves a lot of setup time. It does however, force you to go through all of the upgrade stages and complete the entire upgrade before you are left with a usable and/or testable system.

You cannot use this method unless you are upgrading all of the products installed on your server, or if you have BMC Service Impact Manager, Integration for BMC Remedy Service Desk, or BMC ProactiveNet Performance Management installed on your system.

Staging server setup 17

Setup Prerequisites

■ Duplicated staging server setup: This staging setup method takes longer because you need to create an exact duplicate of your production server, including installing the AR System server and all of the ITSM applications and components, as well as any other applications such as BMC Service Impact Manager, Integration for BMC Remedy Service Desk, or BMC ProactiveNet Performance Management before starting the upgrade.

If you setup the staging server this way, you can test your system after each upgrade step, because you are left with a working system at the end of each stage. And you can test the system after upgrading each of the individual ITSM applications and components.

Whether you use the accelerated staging server setup or the duplicated staging server setup, you’ll need to copy your entire production database to the staging server. At the end of the process, the staging server will become your new production server. Make sure that your staging server is at least hardware equivalent to your current production server. This is the recommended time to upgrade your hardware.

At the end of the staged upgrade process, before promoting the staging server to the new production server, run the Delta Data Migration tool. The Delta Data Migration tool moves data that was added or modified on the production server between the time you copied the database to the staging server and the completion of the upgrade process.

Setup PrerequisitesSet up your staging server so that it meets the software and hardware requirements listed in the BMC Remedy Action Request System 7.6.04 Installation Guide. Follow the instructions in the “Preparing your database” and “Pre-installation procedures” chapters, also in the BMC Remedy Action Request System 7.6.04 Installation Guide.


Accelerated Staging Server Setup

Accelerated Staging Server SetupYou can only use this method if you are upgrading all of the products installed on your server, or if you do not have BMC Service Impact Manager, Integration for BMC Remedy Service Desk, or BMC ProactiveNet Performance Management installed on your production system. The accelerated staging server method allows you to skip the installation of all the BMC software that matches versions the from your existing production server. With this method, you only need to copy the production server database onto the staging server, and then proceed directly to the installation of the AR System Server installation for version 7.6.04 SP2.

To configure the staging server for the accelerated staging server method, proceed to the “Duplicating the Production Server Database” on page 22, and follow the instructions for copying the production server database onto the staging server.


Duplicated Staging Server Setup

Duplicated Staging Server SetupUse Table 1and Table 2 (if applicable) to write down the exact version and patch level of the software that is installed on your production server.

Table 1 AR System and ITSM Product versions for your environment

Table 2 Non-ITSM Product versions for your environment

Ensure that you have backups of all versions listed. Download the product files from the Licensed Products tab of the BMC Software EPD web site (http://webapps.bmc.com/epd).

Install the required software

Follow the procedures below to install each product/application that you listed in Table 1 and Table 2 (if applicable) above.

Product Version Patch Level

BMC Remedy AR System and associated components

BMC Atrium Core

BMC Remedy ITSM Suite

BMC Service Level Management

BMC Service Request Management

BMC Remedy Knowledge Management

Product Version Patch Level

BMC Service Impact Manager

Integration for BMC Remedy Service Desk

BMC ProactiveNet Performance Management

NOTE This may require multiple downloads per product. For example, to upgrade to BMC Remedy ITSM Suite 7.03 Patch 009, you also need to download 7.03, 7.03 Patch 007, and 7.03 Patch 009. Version and product information can be found in the Shared Application Properties form.


Install the required software

1 Install all BMC Remedy AR System related components that match the versions previously identified on the production server. If you are using different locales, please select your target locales to install applicable language packs.

Ensure you use the exact same BMC Remedy AR System instance name, BMC Remedy AR System database administrator name (often ARAdmin) and password, and table space names, including temp space.

2 Install all required BMC Atrium Core related components.

3 Set the environment variables BMC_AR_LOADAPP_SKIP=TRUE and BMC_LOADAPP_SKIP=TRUE.

This enables the application installers to conduct only the operating system level installation without loading the application into the database.

4 Install all applicable BMC Remedy ITSM Suite components and the required version patch.

5 If applicable, install BMC SLM and the required version patch.

6 If applicable, install BMC Service Request Management. For 2.2.x, it is not required that you install the subsequent patches. Installing the base version is sufficient.

7 If applicable, install BMC Remedy Knowledge Management and the required version patch.

8 If applicable, install BMC Service Impact Manager and the required version patch.

9 If applicable, install the integration for BMC Remedy Service Desk and the required version patch.

NOTE If you have a version of BMC Remedy ITSM Suite that is earlier than 7.0.03, a version of BMC Remedy Knowledge Management that is earlier than 7.6.04 in your stack, then BMC Remedy ITSM Suite requires a full installation. You cannot use loadapp skip mode. These product versions do not support the loadapp skip mode option, as described in step 3 in the following procedure.

NOTE For the balance of the staging preparation steps, conducting English only installations is sufficient for BMC Remedy applications such as BMC Remedy ITSM, BMC Service Request Management, BMC Service Level Management, BMC Remedy Knowledge Management.


Duplicating the Production Server Database

10 If applicable, install BMC ProactiveNet Performance Management and the required version patch.

11 Remove the BMC_AR_LOADAPP_SKIP=TRUE and BMC_LOADAPP_SKIP=TRUE environment variables.

Proceed to the next section, “Duplicating the Production Server Database,” to copy the production server database onto the staging server.


This section describes how to copy the current production server database schema and data, onto the new staging server.

Back up the production server database

Work with your database administrator responsible for the production environment to create a full backup of the current production BMC Remedy AR System database.

Restore production database backup on the staging server

1 On the staging server, shut down BMC Remedy AR System server.

2 Work with the database administrator responsible for the production environment to restore the database onto the staging server database.

3 If you are running SQL Server, run the following command in your database:

sp_changedbowner "ARAdmin"

Substitute ARAdmin with the appropriate BMC Remedy AR Database Administrator Account.

NOTE The date and time of the backup for future reference. This information will be used in the Delta Data Migration step to determine which data needs to be migrated to the staging server at the end of the upgrade process. Use the table below to record this value.

Table 3 Production database backup information

Product database backup Time stamp



4 Change the BMC Remedy AR System server name to match the new host.

5 Restart the BMC Remedy AR System server and verify that the system is functional.

6 Work with the database administrator responsible for the production environment to back up the staging server database.

7 Run the AR System database consistency checker and run the health check in the BMC Atrium Core maintenance tool to verify that your system is running properly before the upgrade.

To run the AR System database consistency checker, see the Troubleshooting Techniques chapter in the BMC Remedy Action Request System Optimizing and Troubleshooting Guide.

To run the CMDB Check

1. Launch the BMC Atrium Core Maintenance Tool:

■ On Windows, go to the AtriumCoreInstallDir\atriumcore\ folder and double-click the AtriumCoreMaintenanceTool.cmd file.

■ On UNIX, go to AtriumCoreInstallDir/atriumcore/ directory and run AtriumCoreMaintenanceTool.sh.

2. Click the Health Check tab.

3. Follow the instructions in the Health Check tab.

After you set up your staging server, proceed to start the upgrade.

■ If overlays are implemented in your system, see Chapter 3, “Upgrade with overlays present.”

■ If you want to preserve customizations and implement overlays, see Chapter 4, “Upgrade without overlays present.”

NOTE You only perform the following two steps if you are using the duplicated staging server method. These steps are no necessary for the accelerated staging server setup

NOTE The CMDB health check was introduced in version 7.5, if your staging server is setup with a version earlier than that, you can skip this step.


C h a p t e r 3
3 Upgrade with overlays present
Perform the following stages in this chapter to upgrade if you have already implemented overlays:

■ “Stage 1 - Upgrade AR System server with overlays present”

■ “Stage 6 - Upgrade applications and adjust customizations”

■ “Stage 7 - Test and promote staging server to production”

This upgrade scenario uses a subset of the full staged process. See “Upgrade paths and stages” on page 11 for an overview of all stages.

Before performing the procedures in this section, make sure you have already setup your staging server as described in Chapter 2, “Staging server setup.” on page 17.

NOTE BMC recommends that you back up your staging server database before performing each stage of the upgrade process. BMC also recommends that you run a database consistency check after each stage. See “Using the -checkdb option” in the Optimizing and Troubleshooting Guide.

Upgrade with overlays present 25

Stage 1 - Upgrade AR System server with overlays present

Stage 1 - Upgrade AR System server with overlays present

Performing these steps produces an upgraded AR System server with your current applications and data. This enables you to upgrade the other applications and AR System components in subsequent stages.

This figure shows the components that are upgraded in stage 1.

To upgrade the AR System server

1 Use the AR System installer to perform the upgrade for the AR System server on StagingServer to version 7.6.04 SP2.

NOTE At this point, do not upgrade other AR System components such as BMC Remedy Approval Server, BMC Remedy Assignment Engine, or any of the other available installation items.




When you upgrade applications or system components, it is possible that some objects that you have overlaid will be deleted. This means your overlay will be deleted as well. To preserve any such overlays, you need to create a copy of your current staging server. This copy is called the upgrade comparison server (UpgradeComparisonServer).

Similarly, some of your customizations might interfere with upgraded behavior. You must adjust these customizations before using the application.


To upgrade applications and adjust customizations

1 Create an upgrade comparison server (UpgradComparisonServer), as follows.

A On the system that you are going to use as the upgrade comparison server, install AR System v7.6.04 SP2.

B Create a copy of the StagingServer database, which is already at version 7.6.04 SP2.



C Restore the copy of the StagingServer database over the existing database on UpgradeComparisonServer.

2 On StagingServer, upgrade the AR System components and applications (BMC Atrium CMDB, BMC Remedy ITSM, and so on) to version 7.6.04 SP2.

This will modify and possibly delete some of your overlaid objects. Modifications to these objects performed by the upgrade will not affect your overlays and custom objects, but deletions will.

3 If any of your customizations were deleted during the upgrade of StagingServer, you can use Developer Studio to restore them by creating custom objects on the staging server using the overlays still present on UpgradeComparisonServer.

Normally, an overlay that will be deleted should not be replaced by a custom object because it will not be used by the upgraded application. But if after looking at the upgraded functionality you have overlaid objects that should be preserved, you can do that by saving them as custom objects.

Perform steps A and B to create custom objects for any overlaid objects that were deleted during the upgrade that you want to preserve.

A Compare the overlaid objects on StagingServer against the same objects on UpgradeComparisonServer by performing the following steps:

1. In BMC Remedy Migrator, select Tools > Options.

2. In the BMC Remedy Migrator Options dialog box, expand Differences and select Display.

3. Select the Display all missing objects option and make sure that all the other options are deselected.

4. Open a new server window for StagingServer.

5. In the navigation pane, click StagingServer to display all the objects on this server in the object list.

NOTE A custom field on a deleted form is not preserved, because there is no form to contain the field.

NOTE Ensure that you have set your BMC Remedy Migrator configuration options before performing the following procedures. For details one setting the Migrator configuration options, see Appendix B, “Migrator configuration options.”



6. Sort the object list on the Customization Type column and select all objects with the value Overlay or Custom in this column.

7. Right-click and select Differences > UpgradeComparisonServer.

BMC Remedy Migrator generates a difference report. See the BMC Remedy Migrator Guide, “Difference reports,” page 125.

B For every overlaid object that exists on UpgradeComparisonServer, but not on StagingServer, decide whether you need the object. If you need it, use BMC Remedy Developer Studio to duplicate the overlay manually by saving it as a custom object on StagingServer.

4 If you have overlaid objects that were changed during the upgrade, you should examine your overlays to add functionality that was added to the overlaid objects, or to remove overlays containing customizations that you no longer want. Removing an overlay exposes the upgraded object's functionality.

To do this, you must compare each upgraded origin object that is overlaid on StagingServer to the same origin object on UpgradeComparisonServer, and you will compare each overlay and its overlaid origin object. You can then adjust the overlay to achieve the behavior that you want.

Perform the needed comparisons as follows:

A Enable the required masking options if you haven’t already done so in stage 4.

See “Setting Migrator difference mask options” on page 59.

B Use BMC Remedy Migrator to compare overlaid objects on StagingServer and UpgradeComparisonServer to identify which objects were changed and what changes were made by BMC between the versions, as follows:



3. Sort the object list on the Customization Type column and select all objects with the value Overlaid in this column.



The difference report provides a list of objects that have changed.



Keep this first instance of BMC Remedy Migrator open to examine objects in this report.

C Use a second instance of BMC Remedy Migrator to compare overlays to overlaid objects on UpgradeComparisonServer, as follows:

1. Open a new instance of BMC Remedy Migrator. Open a new server window for UpgradeComparisonServer.

2. In the navigation pane, click nameOfUpgradeComparisonServer to display all the objects on this server in the object list.

3. Sort the object list on the Customization Type column and select objects (in the previously created list) with the value Overlay in this column.


5. In the Source-Destination Mapping window, click Map Overlay To Base.

NOTE You need to have the BMC Remedy Migrator installed on a different computer to do this because you can only run one instance of Migrator on a single system.



6. This populates the Destination Object Name column with the corresponding overlaid object for each overlay object and then click OK to generate the difference report.

D For each object in the difference report from step B, use the first Migrator instance to identify differences resulting from the upgrade. Use the second instance to see differences between the overlay and the overlaid object.

Based on these differences, use BMC Remedy Developer Studio to either delete the overlay or modify it on StagingServer:

■ If you want to use the new features in the latest release, delete the overlay.

■ If you want to retain the customizations in your current production system when you upgrade to the latest release, merge the differences from the origin object into its overlay.


Stage 7 - Test and promote staging server to production


Performing the steps in stage 7 turns your staging server into an upgraded production server.

To test and promote your staging server to production

1 Test the functionality of the upgraded AR System components and applications.

2 Perform the following steps to promoate the server to production:

A Migrate data from your production server to the custom fields and custom forms that you created in step 4 on StagingServer. This will ensure that your custom data is preserved after the upgrade is complete. You may export your data in reports and use the Import tool, use Delta Data Migration, or create some temporary workflow to move the data.

B Use the Delta Data Migration tool to move data created or data that was changed after copying the production database from your production server to StagingServer. This will ensure that the staging server has copies of your latest data. If you created custom fields or forms in step 4, you can use Delta Data Migration to update move new data to those fields as well.

C Shut down the former production server and promote StagingServer to be the new production server.

For more complete information on using Delta Data Migration, see Chapter 9, “Delta Data Migration”.


C h a p t e r 4
4 Upgrade without overlays present
Perform the following stages in this chapter to upgrade and implement overlays.

■ “Stage 1 - Upgrade AR System server without overlays present”

■ “Stage 2 - Create overlays for existing customizations (optional but strongly recommended)”

■ “Stage 3 - Acquire origin objects (optional)”

■ “Stage 4 - Restore origin objects to the staging server (optional)”

■ “Stage 5 - Minimize overlays (optional)”

■ “Stage 6 - Upgrade applications and adjust customizations”

■ “Stage 7 - Test and promote staging server to production”

Before performing the procedures in this section, make sure you have already setup your staging server as described in Chapter 2, “Staging server setup.” on page 17.

NOTE BMC recommends that you back up your staging server database before performing each stage of the upgrade process. BMC also recommends that you run a database consistency check after each stage. See “Using the -checkdb option” in the Optimizing and Troubleshooting Guide.

Upgrade without overlays present 33

Stage 1 - Upgrade AR System server without overlays present

Stage 1 - Upgrade AR System server without overlays present

Performing the steps in this stage produces an upgraded AR System server with your current applications and data. This enables you to upgrade the other applications and AR System components in subsequent stages.


To upgrade the AR System server

1 If you have modified any system forms, export them to a .def file so that your changes can be migrated onto the upgraded forms.

See Appendix C, “This appendix provides a list of AR System server definitions that may be lost or overwritten when you upgrade from earlier versions of AR System server to version 7.6.04 SP2 (assuming that you only select AREA LDAP during installation). If you have modified any of these objects, you should save a copy and restore your changes after upgrading the server..”, for a list of system forms.

Specify the option to export the related objects.

2 Use the AR System installer to perform the upgrade for the AR System server on StagingServer to version 7.6.04 SP2. Follow the instructions in the AR System Installation Guide. The install program will automatically recognize the existing database and automatically install the software in upgrade mode.

3 Restore any customizations to the system forms that may have been removed by the server upgrade process.

NOTE At this point, do not upgrade other AR System components such as BMC Remedy Approval Server, BMC Remedy Assignment Engine, or any of the other available installation items.



On StagingServer, restore customizations that you made to the system forms as follows:

A Use BMC Remedy Migrator to compare the system forms on StagingServer to those in the .def file that you created in step 1.

B Using the information obtained from sub-step A, use BMC Remedy Developer Studio or BMC Remedy Migrator to restore any customizations that were overwritten during the AR System server upgrade.


Performing the steps in stage 2 copies your existing customizations into overlays and custom objects, allowing them to be preserved for future upgrades. This includes both AR System server customizations as well as all other applications and components.

This figure shows how the BPCU is used to create overlays and custom objects from your existing objects. If you customized workflow by copying and disabling an application object, you need to run BPCU twice as shown above. Otherwise, you only need to run it once. Object 1 is a customized version of workflow object 2, so object 1 is converted into an overlay of object 2. Because object 3 is a modified application object, object 7 (a new object), is created as an overlay of object 3. Object 6, which was created in the production environment is converted into a custom object.

■ The upper plane shows the overlay group, which contains overlays, custom objects and origin objects that have not been overlaid.

■ The lower plane shows the base group, which contains only origin objects.



To create overlays

1 Before upgrading applications or creating overlays, you need to find out what objects have been modified. In particular, you need to determine which objects have been modified in ways that are not permitted in overlays. For any such objects, this can prevent an application upgrade from succeeding, if the upgrade affects that object.

Running the BPCU in ReportDiff mode allows you to determine such modifications, and to make the necessary corrections before upgrading any applications. It compares the current objects to a set of base objects that are defined in an overlay hash file.

■ To obtain the hash file needed to run the BPCU in ReportDiff mode, see “Obtaining the hash files for analyzing and converting customizations” on page 108.

■ To obtain the BPCU, see “Creating overlays with the Best Practice Conversion Utility” on page 63, and to properly configure the BPCU to run on your system, make sure you follow the procedure listed in “Configuring your system for BPCU” on page 66.

To see the changed objects, run the BPCU in ReportDiff mode, to compare objects on StagingServer with those in the overlay hash file. This generates a BPCU difference report, as shown in the following example, which is run from a command prompt:

bpcu -x localhost -t serverport -u Demo -p “DemoPassword" -m D -f “hashFileLocation\OverlayHashFile.xml”

The BPCU difference report is an HML formatted file that displays a list of the extensions and customizations in your setup, and indicates whether they are permitted or non-permitted. Difference reports are called bpcu-diff-report_[date]_[timestamp].html and are located in the [utilityInstallDir]\Best_Practice_Conversion_Utility\output folder.

NOTE The BPCU command must be run from a command prompt and you must be in the BPCU installation folder: [utilityInstallDir]\Best_Practice_Conversion_Utility\



The BPCU also generates some migrator .xml instruction files that will be used in stage 4 of the upgrade process. See “Viewing differences between objects” on page 75 for an explanation of what those instruction files are used for.

For complete details on generating difference reports, see “Using BPCU to generate difference reports” on page 67.

2 Resolve all non-permitted modifications that can prevent the creation of overlays or the successful upgrade of applications.

You only need to do this if the BPCU difference report shows non-permitted customizations. If needed, perform the following:

A Install a reference server ReferenceServer that is the same version as your production AR System server, and install copies of all applications that are running on your production server. The installed applications must be the exact same version as the applications on your production server, including patches and hotfixes. The reference server will have only unmodified origin objects from the BMC released software, with no customizations.

B On both ReferenceServer and StagingServer, use the Migrator command line interface to create a .migrator file which contains only the objects with non-permitted customizations. Then, use migrator to compare the two files. For details on creating and comparing the .migrator files, See “Viewing differences between objects” on page 75.

C For each object that contains a non-permitted modification, perform the appropriate corrective action. For specific details on how to make these modifications, see “Fixing non-permitted modifications” on page 51.

D After fixing all non-permitted modifications, delete your migrator instruction files, and difference report from the \output folder. Then run the BPCU again in ReportDiff mode to generate a new, clean set of instruction files based on your server after you have removed all non-permitted customizations. See “Viewing differences between objects” on page 75 for details on running BPCU ion ReportDiff mode.

NOTE Ensure that you have set your BMC Remedy Migrator configuration options before performing the following procedures. For details one setting the Migrator configuration options, see Appendix B, “Migrator configuration options.”

NOTE The new, cleaner migrator instruction files created by this last run of the BPCU in comparison mode, are the migrator instruction files that you will use in stage 4 of the upgrade process.



These corrective actions either allow BPCU to preserve an object as a custom object that does not conflict with a BMC application object, or allow BPCU to create an overlay from the object.

3 You can create overlays or custom objects from your customizations, so that they will be preserved across an application upgrade. To do this, you need to run the BPCU again in Overlay mode to create overlays and custom objects.

In some cases, BMC application objects might have been copied and disabled, with modifications made to the enabled copy. Generally, such copies have names that are the original object name with a well known prefix or suffix.

In other cases, BMC application objects might have been modified directly or there may be a mixture of these methodologies.

If at least some of your customizations are in copies of origin objects with names which have well known prefixes or suffixes, perform the following steps:

A For each object, if its name contains both a prefix and a suffix, remove one or the other. Otherwise, the BPCU does not convert the object.

B If you created copies of origin objects but did not use prefixes or suffixes to identify them, rename those copies to include either a prefix or a suffix.

C Run BPCU in Overlay mode, with the -P and -S options.

bpcu -x localhost -t serverport -u Demo -p "DemoPassword" -m o-f "hashFileLocation\OverlayHashFile.xml"-P "prefix1,prefix2,..." -S "suffix1,suffix2,..."

See “Using BPCU to generate overlays for modified legacy objects” on page 69.

BPCU makes the following changes to active links, filters and escalations:

■ If the origin object is enabled, BPCU marks the copy as a custom object.

■ If the origin object is disabled, BPCU converts the copy into an overlay of the origin object.

The -P and -S switches allow BPCU to convert active links, filters, and escalations into overlays when they are copies of disabled origin objects.


Stage 3 - Acquire origin objects (optional)

D Run the BPCU in Overlay mode again, without the -P or -S option, as follows:

bpcu -x localhost -t serverport -u Demo -p "DemoPassword" -m o-f "hashFileLocation\OverlayHashFile.xml"

The BPCU generates overlays for directly changed origin objects.

If your customizations are only in modified origin objects that have not been copied and renamed, perform the following steps:

Run BPCU in Overlay mode without the -P or -S option, as follows:

bpcu -x localhost -t serverport -u Demo -p “DemoPassword" -m o -f “hashFileLocation\OverlayHashFile.xml”

The BPCU generates overlays for the modified objects and converts any user-created objects to custom objects.

Stage 3 - Acquire origin objects (optional) When you upgrade an application, its origin objects are modified. If you want to understand the effects of these modifications, you need to compare origin objects from the original application with origin objects from the upgraded application. Similarly, to understand the modifications captured in your overlays, you will need to compare them with origin objects from the original 7.6.04 SP2 software.

In stage 3 you acquire unmodified origin objects. After this done, you will be able to compare the overlays on your server to unmodified origin objects, allowing you to see exactly what has changed in any object.

To acquire origin objects

Set up a version 7.6.04 SP2 reference server (ReferenceServer) with unmodified versions of the same AR System components and applications that exist on your production server:

■ If you already created a reference server in stage 2 to use when fixing any non-permitted customizations, then you need to upgrade that reference server to AR System 7.6.04 SP2.

■ If you did not create a reference server in stage 2, then you need to setup a new reference server at this point. First install AR System version 7.6.04 SP2, then install out-of-the-box versions of all the applications that are running on your production server, including any patches and hotfixes.


Stage 4 - Restore origin objects to the staging server (optional)


If you want to view your objects in Base Development mode within Developer Studio, perform the steps in stage 4. This procedure replaces the origin objects on StagingServer with the unmodified origin objects from ReferenceServer. If the unmodified origin objects on StagingServer are preserved, you will not have to maintain the reference server with the objects. In addition you can:

■ Observe the customizations captured in your overlays by comparing the overlays to the origin objects in Developer Studio on a single server in Base Development mode.

■ Configure StagingServer so that your application uses your customizations, or so that it has only the original unmodified functionality.

You migrate your unmodified origin objects into a migrator file, and from there can selectively migrate them to StagingServer. Restoring the origin objects to StagingServer does not affect the overlays that you created.

This figure shows the replacement of modified application objects with their unmodified original versions. Note that overlays and custom objects are unaffected by this process.



To restore origin objects to the staging server

1 Ensure that you have set your BMC Remedy Migrator configuration options. For details one setting the Migrator configuration options, see Appendix B, “Migrator configuration options.”.

2 Migrate origin objects from ReferenceServer to a .migrator file, using the instruction file generated by the BPCU in stage 2 -step 1, with the migratorcli command as follows:

migratorcli.exe -m -s ReferenceServer -t serverport-d “destinationFilePath\fileName.migrator” -i “instructionFilePath\migrator-instruction_date_timestamp.xml” -u Demo -p "DemoPassword" -g “Migrator Configuration.xml” --level 4 --layout 1 --logfile logFileNameAndPath

3 Migrate objects from the .migrator file StagingServer. You can do this in either of two ways.

If you want to selectively migrate your objects, use the BMC Remedy Migrator application.

A Open the .migrator file in BMC Remedy Migrator and double-click the .migrator file name in the navigation pane.

B In the object list, select AR System server objects of the same type, right-click and select Migrate Selected Objects > StagingServer. Repeat this step until all your objects have been migrated from the .migrator file to StagingServer.

If you want to migrate all of the objects at once, you can use the Migrator CLI, as follows:

migratorcli.exe -m -s “sourceFilePath\fileName.migrator” -d StagingServer --dst_tcpport serverport-i “instructionFilePath\migrator-instruction_date_timestamp.xml” -u Demo -p "DemoPassword" -g “Migrator Configuration.xml” --level 4 --layout 1 --logfile logFileNameAndPath

This migrates all objects together from the .migrator file to StagingServer.

NOTE Before running this command, confirm that the AR System version installed on your reference server is 7.6.04 SP2.


Stage 5 - Minimize overlays (optional)

Stage 5 - Minimize overlays (optional) Performing the steps in stage 5 helps you to minimize the number of overlays. You should remove all overlays that are the same as the object that they overlay, and all overlays that contain changes that are no longer needed. This reduces the number of customizations that must be maintained during future application upgrades.

This figure shows the removal of an unneeded overlay, item 7. Note that removal of the overlay exposes the origin object.

TIP Overlays that are identical to their overlaid objects might exist if you converted any prefixed or suffixed objects in stage 2.



To minimize your overlays

1 If you performed the tasks in stage 4, then you can use BMC Remedy Migrator to compare overlaid object to their overlays directly on StagingServer, and then delete those objects which are identical. See “Comparing overlays to overlaid objects on the same server” on page 59.

If you did not perform the steps in stage 4, then the overlays and overlaid objects on StagingServer are identical, except for those that previously had prefixes or suffixes. Set Migrator difference mask options as described in “Setting Migrator difference mask options” on page 59, and use BMC Remedy Migrator to compare the overlaid objects on StagingServer to the same objects on ReferenceServer. If they are identical, then you can remove the overlay on StagingServer.

2 If you have any overlays that are not identical to the origin object, but which contain changes that you no longer want to keep, you should also delete those overlay objects.


If you proceeded directly from stage 1 to stage 6 and you did not have overlays before performing stage 1, you do not have customizations captured in overlays. You can perform steps 1 and 2 of this stage, and then reapply your customizations as needed before skipping to stage 7.

When you upgrade applications or system components, it is possible that some objects that you have overlaid will be deleted. This means your overlay will be deleted as well. To preserve any such overlays, you need to create a copy of your current staging server. This copy is called the upgrade comparison server (UpgradeComparisonServer).

Similarly, some of your customizations might interfere with upgraded behavior. You must adjust these customizations before using the application.

If you have performed stage 4 to migrate origin objects from ReferenceServerto your staging server, you no longer need the objects on ReferenceServer created in stage 3, so you can now employ that server as UpgradeComparisonServer.

NOTE Be careful when removing overlays of workflow objects. Disabled workflow objects are not identical to enabled ones, even if all other aspects are the same.



If you did not migrate your unmodified origin objects to your staging server, then you want to preserve them. In this case, you will need to employ a different server as UpgradeComparisonServer.


To upgrade applications and adjust customizations

1 If you completed stage 4 you can reuse ReferenceServer to be UpgradComparisonServer, as follows.

A Create a copy of the StagingServer database, which is at version 7.6.04 SP2.

B Restore the copy of the StagingServer database over the ReferenceServer database. ReferenceServer is now UpgradeComparisonServer.

2 On StagingServer, upgrade the AR System components and applications (BMC Atrium CMDB, BMC Remedy ITSM, and so on) to version 7.6.04 SP2.

NOTE If you did not complete stage 4, you will need to copy StagingServer database and install a new AR System server configured to use the copy. The new server will be UpgradeComparisonServer.



This will modify and possibly delete some of your overlaid objects. Modifications to these objects performed by the upgrade will not affect your overlays and custom objects, but deletions will.

3 If any of your customizations were deleted during the upgrade of StagingServer, you can use Developer Studio to restore them by creating custom objects on the staging server using the overlays still present on UpgradeComparisonServer.

Normally, an overlay that will be deleted should not be replaced by a custom object because it will not be used by the upgraded application. But if after looking at the upgraded functionality you have overlaid objects that should be preserved, you can do that by saving them as custom objects.

Perform steps A and B to create custom objects for any overlaid objects that were deleted during the upgrade that you want to preserve.

A Compare the overlaid objects on StagingServer against the same objects on UpgradeComparisonServer by performing the following steps:

1. In BMC Remedy Migrator, select Tools > Options.

2. In the BMC Remedy Migrator Options dialog box, expand Differences and select Display.

3. Select the Display all missing objects option and make sure that all the other options are deselected.



6. Sort the object list on the Customization Type column and select all objects with the value Overlay or Custom in this column.



NOTE A custom field on a deleted form is not preserved, because there is no form to contain the field.



B For every overlaid object that exists on UpgradeComparisonServer, but not on StagingServer, decide whether you need the object. If you need it, use BMC Remedy Developer Studio to duplicate the overlay manually by saving it as a custom object on StagingServer.

4 If you have overlaid objects that were changed during the upgrade, you should examine your overlays to add functionality that was added to the overlaid objects, or to remove overlays containing customizations that you no longer want. Removing an overlay exposes the upgraded object's functionality.

To do this, you must compare each upgraded origin object that is overlaid on StagingServer to the same origin object on UpgradeComparisonServer, and you will compare each overlay and its overlaid origin object. You can then adjust the overlay to achieve the behavior that you want.

Perform the needed comparisons as follows:

A Enable the required masking options if you haven’t already done so in stage 4.

See “Setting Migrator difference mask options” on page 59.

B Use BMC Remedy Migrator to compare overlaid objects on StagingServer and UpgradeComparisonServer to identify which objects were changed and what changes were made by BMC between the versions, as follows:



3. Sort the object list on the Customization Type column and select all objects with the value Overlaid in this column.



The difference report provides a list of objects that have changed.

Keep this first instance of BMC Remedy Migrator open to examine objects in this report.

C Use a second instance of BMC Remedy Migrator to compare overlays to overlaid objects on UpgradeComparisonServer, as follows:



1. Open a new instance of BMC Remedy Migrator. Open a new server window for UpgradeComparisonServer.

2. In the navigation pane, click nameOfUpgradeComparisonServer to display all the objects on this server in the object list.

3. Sort the object list on the Customization Type column and select objects (in the previously created list) with the value Overlay in this column.


5. In the Source-Destination Mapping window, click Map Overlay To Base.

NOTE You need to have the BMC Remedy Migrator installed on a different computer to do this because you can only run one instance of Migrator on a single system.



This populates the Destination Object Name column with the corresponding overlaid object for each overlay object and then click OK to generate the difference report.

D For each object in the difference report from step B, use the first Migrator instance to identify differences resulting from the upgrade. Use the second instance to see differences between the overlay and the overlaid object.

Based on these differences, use BMC Remedy Developer Studio to either delete the overlay or modify it on StagingServer:

■ If you want to use the new features in the latest release, delete the overlay.

■ If you want to retain the customizations in your current production system when you upgrade to the latest release, merge the differences from the origin object into its overlay.




Performing the steps in stage 7 turns your staging server into an upgraded production server.

To test and promote your staging server to production

1 Test the functionality of the upgraded AR System components and applications.

2 Perform the following steps to promote the server to production:

A Migrate data from your production server to the custom fields and custom forms that you created in step 4 on StagingServer. This will ensure that your custom data is preserved after the upgrade is complete. You may export your data in reports and use the Import tool, or use the Delta Data Migration tool, or create some temporary workflow to move the data.

B Use the Delta Data Migration tool to move data created or data that was changed after copying the production database from your production server to StagingServer. This will ensure that the staging server has copies of your latest data. If you created custom fields or forms in step 4, you can use the Delta Data Migration tool to update move new data to those fields as well.

For more complete information on using the Delta Data Migration tool, see Chapter 9, “Delta Data Migration,” on page 77.

C Shut down the former production server and promote StagingServer to be the new production server.


C h a p t e r 5
5 Fixing non-permitted modifications
This chapter describes how to fix non-permitted modifications that were discovered when the Best Practices Conversion Utility (BPCU) to compare objects on the staging server with an overlay hash file. Because some of the changes described here alter the functionality of an object; you might want to copy the object as a custom object before changing it. The BPCU is described in Chapter 7, “Creating overlays with the Best Practice Conversion Utility.”

This chapter contains the following sections and assumes there are modified objects on StagingServer and unmodified origin objects of the same version on ReferenceServer.

■ “Fixing non-permitted changes for objects that include __o in an object name”

■ “Fixing non-permitted modifications for forms”

■ “Fixing non-permitted modifications for fields”

Fixing non-permitted changes for objects that include __o in an object name

To rename an object to remove the __o string, perform the following steps:

1 On StagingServer, locate the object that contains __o in its name.

2 In the object list, select the object, and choose File > Rename.

NOTE Names that include underscore + zero (_0) are reserved by BMC.

Fixing non-permitted modifications 51

Fixing non-permitted modifications for forms

3 Rename the object so that it does not include __o in its name, and so that its name does not conflict with the name of any other object.

Fixing non-permitted modifications for formsThis section contains instructions for fixing non-permitted modifications to forms.

Changing the inclusion or exclusion of a form in a deployable application

1 On StagingServer, open the application in an editor.

2 On ReferenceServer, open the application.

3 On StagingServer, add or remove forms in the application to match those on ReferenceServer.

4 Save the application.

Changing unique indexes

1 On StagingServer, open the Regular form and the Form Properties dialog box, Indexes category.

2 In the Index List on ReferenceServer, open the Form Properties dialog box for the corresponding form.

3 On StagingServer, specify the same number and order of unique indexes in the Index List with the same number and order of indexed fields as those on ReferenceServer.

4 Remove any unique indexes that are not on ReferenceServer.

5 Save the form.


Changing Vendor form information for Table Name or Vendor Name

Changing Vendor form information for Table Name or Vendor Name

Perform the following steps:

1 On StagingServer, open the Vendor form and the Form Properties dialog box.

2 On ReferenceServer, open the Form Properties dialog box for the corresponding form.

3 On StagingServer, set the Vendor Name and Table Name properties to the same values as those of the form on ReferenceServer.

4 Save the form.

Changing Join form Information

This section provides instructions for changing to the following Join form information:

■ Swapping the primary and secondary forms■ Join Type■ Qualification■ Source of fields

To change join form information

1 On StagingServer, open the Join form and the Form Properties dialog box, Join Information category.

2 On ReferenceServer, open the Form Properties dialog box for the corresponding form.

3 On StagingServer, set the Join Type and Qualifier values to the same as that on ReferenceServer. If required, swap the Primary and Secondary forms.

4 Compare every field on the StagingServer Join form with its counterpart on the ReferenceServer Join form to verify that the values of their Form Name property match.

For each field where the values differ, perform the following tasks on the StagingServer Join form:


Changing View form information for Table name or Key field

A Delete the field.

B Right-click and choose Add Fields from formName, where formName matches the value on the ReferenceServer Join form.

5 Save the form.

Changing View form information for Table name or Key field

For each View form where these properties have been changed, set the values on StagingServer to match those on ReferenceServer.

To change properties for Label, Locale, or Name of a View

1 On StagingServer, open the form and the appropriate form view.

2 On ReferenceServer, open the corresponding form view.

3 On StagingServer, set the view’s Label, Locale, and Name properties to the same value as that of the field on ReferenceServer.

4 Save the form.

Fixing non-permitted modifications for fieldsThis section provides instructions for fixing non-permitted modifications to fields.

Changing the data type

If your field does not contain data that should be saved, delete the field on StagingServer and copy the corresponding field from ReferenceServer to StagingServer.

If the field does contain data that should be preserved, perform the following steps:

1 On StagingServer, rename the field.

2 Use the archgid utility to change the ID to the customer range.


Changing the Column properties on View and Vendor forms

For information on using the archgid utility, see the Form and Application Objects Guide, “AR System change ID utility,” page 407.

3 Copy the corresponding field from ReferenceServer to StagingServer.

4 Copy data to this field if the data is compatible.

5 Delete the field that you renamed in Step 1.

6 Save the form.

Changing the Column properties on View and Vendor forms

1 On StagingServer, open the View or Vendor form and the form view that contains the field, and select the field.

2 On ReferenceServer, select the corresponding field.

3 On StagingServer, set the field’s Column property to the same value as that of the field on ReferenceServer.

4 Save the form.

Changing the Name

1 On StagingServer, open the form and the form view that contains the field, and select the field.

2 On ReferenceServer, select the corresponding field.

3 On StagingServer, set the field’s Name property to the same value as that of the field on ReferenceServer.

4 Save the form.

Changing the Length Units property of Character fields

If your field does not contain data that should be saved then delete the field on the StagingServer and copy the corresponding field from the ReferenceServer to the StagingServer. If the field does contain data that should be preserved, perform the following steps:


Changing the Column field properties for Parent field ID, Data field ID and Data Source







6 Save the form.

Changing the Column field properties for Parent field ID, Data field ID and Data Source

For each field where these properties have been changed, set the values on StagingServer to match those on ReferenceServer.

Changing the Entry Mode —Display

If the out-of-the-box field’s Entry Mode was Display, and the StagingServer field is not, and your field does not contain data that should be saved then delete the field on StagingServer and copy the corresponding field from the ReferenceServer to StagingServer. If the field does contain data that should be preserved, perform the following steps:

1 On StagingServer rename the field.

2 Use archgid to change the ID to the customer range.


4 Save the form.


Changing the field type


If your field does not contain data that should be saved then delete the field on StagingServer and copy the corresponding field from ReferenceServer to the StagingServer. If the field does contain data that should be preserved, perform the following steps:







6 Save the form.


C h a p t e r 6
6 Comparing overlays to overlaid objects on the same server
Perform these optional steps and use BMC Remedy Migrator to compare objects on the same server if you are minimizing overlays in stage 5.

■ “Setting Migrator difference mask options”

■ “Comparing staging server objects”

See “Upgrade paths and stages” on page 11 for an overview of all stages.

Setting Migrator difference mask optionsBefore comparing overlays to overlaid objects, you must set certain difference mask options in addition to the default mask options so that BMC Remedy Migrator only compares differences that affect the operation of your application.

To set required difference mask options

1 In BMC Remedy Migrator, open a new server window for StagingServer.

2 Choose Tools > Options.

3 In the BMC Remedy Migrator Options dialog box, perform the following actions:

A Expand Differences, expand Masks, and set the following options to Disabled:

■ Forms—Name, Owner, and Property List

Comparing overlays to overlaid objects on the same server 59

Comparing staging server objects

■ Fields—Form Name, Owner, and Property List

■ Views—Form Name, Owner, and Property List

■ Active Links, Filters, Escalations, Containers (applications, web services, packing lists, active link guides, filter guides), Menus, and Images—Owner and Property List

B Click OK save the updated settings and close the dialog box.


To compare overlays to overlaid objects on the staging server

1 In BMC Remedy Migrator, open a new server window for StagingServer.

2 In the navigation pane, select the server name to view the list of all objects on this server in the object list view.

If you select an object type in the navigation pane, only those types of objects appear in the object list view.

3 In the object list view, select all the overlay objects.

Sort the object list on the Customization Type column and select objects in that column that have the value Overlay in that column.



4 Right-click and choose Differences > StagingServer.

5 In the Source - Destination Mapping dialog box, click Map Overlay to Base.

The Destination Object Name column with the overlaid objects that correspond to each overlay in the Source Object Name column.

6 Click OK to begin the comparison and generate a difference report.

The difference report indicates whether the overlay and overlaid objects differ and highlights the properties that differ.

Comparing overlays to overlaid objects on the same server 61

C h a p t e r 7
7 Creating overlays with the Best Practice Conversion Utility
This chapter describes how to use the Best Practice Conversion Utility (BPCU) in stage 2 before upgrading applications or creating overlays. In particular, you need to determine which objects have been modified in ways that are not permitted in overlays. It contains the following sections:

■ “Usage overview”

■ “Configuring your system for BPCU”

■ “Using BPCU to generate difference reports”

■ “Using BPCU to generate overlays for modified legacy objects”

See “Upgrade paths and stages” on page 11 for an overview of all upgrade stages.

Usage overviewTo preserve modified or user-created objects in applications installed on pre-7.6.04 AR System servers, use the command-line version BPCU before upgrading your applications or server components to version 7.6.04. BPCU enables you to analyze objects in your current environment with the out-of-the-box objects in 7.6.04, and convert them into overlays or custom objects.

BPCU does not save customizations to certain objects that are not meant to be customized and which can be replaced during an application installation or during the normal process of running an application. These are referred to as non-permitted customizations, that is customizations that are not permitted in overlays.

Creating overlays with the Best Practice Conversion Utility 63

Usage overview

BPCU helps preserve customizations when upgrading by converting objects in earlier versions of AR System components and applications as follows:

■ BMC-provided objects that you modified (customizations) are converted to overlays.

■ User-created objects that you added to your setup (extensions) are converted to custom objects.

Table 4 lists the BMC products in which the BPCU preserves customizations and the related exceptions.

Table 4 Customizations preserved by BPCU

BMC products Exceptions

AR System components

BMC Remedy Approval Server Filters that BMC Remedy Approval Server workflow creates at runtime, whose names begin with AP:Notify-0

BMC Remedy Assignment Engine None

BMC Remedy Email Engine None

AREA LDAP plug-ins None

ARDBC LDAP plug-ins None

BMC Atrium CMDB

BMC Atrium CMDB The BMC Atrium CMDB upgrade program takes care of preserving customizations made to forms and workflow objects. BPCU ignores the following forms and their related workflow objects and workflow guides:

Forms that belong to the BMC:Atrium CMDB application

Forms that do not belong to the BMC:Atrium CMDB application, but whose names are listed in the OBJSTR:Class form (<namespace>:<classname>)

AR System applications

BMC Remedy ITSM Suite Application forms that use BMC Atrium CMDB forms as self-join forms (MemberA and MemberB are the same)

BMC Service Level Management Filters with the zSLMGen: prefix that BMC Service Level Management workflow creates at runtime

Forms that BMC Service Level Management creates at runtime, whose names end with _SLA, and their related workflow objects and workflow guides

BMC Service Request Management Filters with the zAPR prefix that BMC Service Level Management workflow creates at runtime


Usage overview

The Best Practice Conversion Utility operates in the following modes:

■ ReportDiff—Generates a report of differences between the objects in an overlay hash file and the objects on a server. See “Using BPCU to generate difference reports” on page 67.

■ Overlay—Based on a differences report, converts customized AR System objects into overlays, and converts user-created objects into custom objects. See “Using BPCU to generate overlays for modified legacy objects” on page 69.

To obtain BPCU

1 Install only the 7.6.04 AR System server on StagingServer.

2 Updates to BPCU (bpcu<releasenumber>.zip) and the Overlay hash file (OverlayHashFile.zip) between patch releases are posted to BMC Developer Network Community website. Before running BPCU, always make sure to obtain the latest version of the utility and the hash file from this location.

3 Uncompress the OverlayHashFile.zip file and extract the OverlayHashFile.xml file to your development server.

4 Uncompress the bpcu7604.zip file, which is located in the ARSystemServerInstallDir folder.

By default, the BPCU files are extracted to the Best_Practice_Conversion_Utility folder.

WARNING The utility will not preserve customizations to forms and workflows installed with the AR System server unless customizations are present when the utility is run. See “Viewing differences between objects” on page 75.

Note that we recommend upgrading to version 7.6.04 of the AR System server before running BPCU; this upgrade will replace the system forms so we also recommend reapplying the customizations to system forms before running BPCU.

WARNING Do not install any AR System components or applications other than the AR System server. If you do, your customizations might be overwritten.


Configuring your system for BPCU

Configuring your system for BPCU Make sure that your CLASS path and Oracle Java Runtime Engine (JRE) are correctly configured to support BPCU.

To configure your system to run the BPCU

1 Grant yourself execute permission to the BPCI on UNIX, by typing the following command:

chmod +x bpcu.sh

2 Make sure the following files are in your CLASS path.

3 To produce the difference report generated by BPCU in XLSX format, make sure that the following files are in your CLASS path:

■ dom4j-1.6.1.jar■ ooxml-schemas-1.0.jar■ poi-3.5-FINAL-20090928.jar■ poi-ooxml-3.5-FINAL-20090928.jar■ xmlbeans-2.3.0.jar

4 To specify the JRE for the utility, add the following entry to the appropriate file:

set JAVA_HOME=fullPathToJRE

The Best Practice Conversion Utility uses the JRE specified by the JAVA_HOME environment variable in the following files:

■ Windows bpcu.bat■ UNIX bpcu.sh

■ activation.jar■ arapi7604.jar■ arutil7604.jar■ arcmnapp7604.jar■ bpcu.jar

■ commons-jxpath-1.3.jar■ jaxb-api.jar■ jaxb-impl.jar■ jsr173_1.0_api.jar■ log4j-1.2.14.jar


Using BPCU to generate difference reports

5 If you plan to run the BPCU on an AR System server that enforces encryption in its API, first add the following items to the JRE that the utility will use.

For more information about BMC Remedy Encryption Security products, see the BMC Remedy Encryption Security Guide.

Using BPCU to generate difference reportsRun BPCU in ReportDiff mode to compare objects between the overlay hash file and an AR System server, and generate difference reports.

To generate a difference report

1 At the command prompt, go to the following directory:

utilityInstallDir\Best_Practice_Conversion_Utility\

Table 5 Files and providers to add to BPCU JRE on encrypted servers

Add to this directory or file

On Oracle Solaris(UNIX and Windows)

On AIX and DB2(UNIX and Windows)

jre\lib\ext\ jsafeJCEFIPS.jar ■ jsafeJCEFIPS.jar■ bcprov-jdk15-133.jar

jre\lib\security\ ■ US_export_policy.jar■ local_policy.jar

These files should be from Oracle.

■ US_export_policy.jar■ local_policy.jar

These files should be from IBM.

jre\lib\security\java.security

security.provider.n+1=com.rsa.jsafe.provider.JsafeJCE

n can be the last number in the section.

security.provider.n+1=org.bouncycastle.jce.provider.BouncyCastleProvider

security.provider.n+2=com.rsa.jsafe.provider.JsafeJCE

n can be the last number in the section.

NOTE If you have installed a BMC Remedy Encryption Security product on a BMC Remedy Java client, such as BMC Remedy Developer Studio or BMC Remedy Data Import, you do not have to verify that your configuration matches the preceding specifications. Instead, simply use the same Oracle Java Developer’s Kit (JDK) and JRE used by the client for BPCU.


Using BPCU to generate difference reports

2 Run BPCU in ReportDiff mode by executing the following command with the appropriate arguments (see Table 6):

■ Windows bpcu.bat■ UNIX bpcu.sh

For an example of using the bpcu command to compare objects, see “Stage 2 - Create overlays” on page 17.

Table 6 Command-line options for ReportDiff mode

Argument Description

-x Name of the server on which to perform the operation.

-u User name.

-p User password.

-a (optional) User authentication string.

-t (optional) TCP port of the server on which to perform the operation.

-r (optional) RPC port of the server on which to perform the operation.

-f Absolute path to the overlay hash file (include full path and file name).

-c (optional) Full path to the XML file containing a list of objects to include in or to exclude from the operation.This option does not apply to ReportDiff mode when two overlay hash files are compared.

-e (optional) Comma-separated list of form names whose associated fields and views are the only objects processed by the operation. Do not use this option with the -s option.

-o (optional) File name and path of the difference report. Do not include a file extension.If you do not provide a file name, the following name is used:bpcu-diff-report-date_timestamp.htmlIf you do not provide a path, the utility places the report file in the installDir\Best_Practice_Conversion_Utility\output\ folder.

-T (optional) Format of the difference report. Values are:

■ 0— HTML (Default)■ 1—CSV■ 2—XLSX

-i (optional) Flag that specifies whether to include overlay and custom objects in the “extension” section of the difference report.This option applies only to file-to-server comparisons. Values are:

■ 0—Exclude from extension section (Default).■ 1—Include in extension section.

-m Utility mode. Values are D or d or diff.

-k (optional) Indicates whether to display or hide the list of objects that will be skipped in Overlay mode.

■ 0—Hide this list in the difference report (Default) .■ 1—Display this list in the difference report.


Using BPCU to generate overlays for modified legacy objects


In Overlay mode, BPCU compares objects in an overlay hash file with the objects on a server, generates a report of their differences, and performs the following tasks based on the contents of the report:

■ For permitted customizations, BPCU generates an overlay by creating a copy of each object, and sets its Overlay property to Overlay.

■ For permitted extensions, BPCU generates a custom object and sets the Overlay property to Custom

In Overlay mode, BPCU ignores all the overlay, overlaid, and custom objects on the server. Therefor, running BPCU multiple times in Overlay mode will not cause problems for such objects, including objects that are shared among applications.

To generate overlays for pre-7.6.04 objects

1 Generate a difference report, and fix all the non-permitted extensions and customizations that are identified.

See “Using BPCU to generate difference reports” on page 67.

If non-permitted extensions and customizations are found among the set of objects to be processed, BPCU does not run in Overlay mode.

2 At the command prompt, go to the following directory:

utilityInstallDir\Best_Practice_Conversion_Utility\

3 Run BPCU in Overlay mode by executing the following command with the appropriate arguments (see Table 7):

■ (Windows) bpcu.bat■ (UNIX) bpcu.sh

For an example of using the bpcu command to generate overlays, see “Stage 2 - Create overlays” on page 17.

Table 7 Command-line options for Overlay mode (part 1 of 2)


-x Name of the server on which to perform the operation.

-u User name.



-p User password.

-a (optional) User authentication string.

-t (optional) TCP port of the server on which to perform the operation.

-r (optional) RPC port of the server on which to perform the operation.

-f Absolute path to the overlay hash file provided by BMC (include full path and file name).

-c (optional) Full path to the XML file containing a list of objects to include in or to exclude from the operation.This option applies to all modes except when two overlay hash files are compared in ReportDiff mode.

-e (optional) Comma-separated list of form names whose associated fields and views are the only objects processed by the operation. Do not use this option with the -s option.

-o (optional) Name of the difference report. Do not include a file extension.

-T (optional) Format of the difference report. Values are■ 0—HTML (Default) ■ 1—CSV■ 2—XLSX

-m Utility mode. Values are o or overlay.

-k (optional) Indicates whether to display or hide the list of objects that are skipped during conversion.

■ 0—Hide this list in the difference report (Default) .■ 1—Display this list in the difference report.

-P Comma-separated list of prefixes in the names of user-created objects.All objects whose name begins with one of these prefixes are converted into overlays or custom objects.This option applies only to active links, active link guides, filters, filter guides, escalations, menus, and all types of containers. (Per BMC best practices, to modify such objects in pre-7.6.04 releases, you should make a copy of the origin object and add a prefix or suffix to its name.)You must ensure that the corresponding out-of-the-box object exists and is the same type in the 7.6.04 release.

-S Comma-separated list of suffixes in the names of user-created objects.All objects whose name ends with one of these suffixes are converted into overlays or custom objects.This option applies only to active links, active link guides, filters, filter guides, escalations, menus, and all types of containers. (Per BMC best practices, to modify such objects in pre-7.6.04 releases, you should make a copy of the origin object and add a prefix or suffix to its name.)You must ensure that the corresponding out-of-the-box object exists and is the same type in the 7.6.04 release.

-i (optional) Flag that specifies whether to include overlay and custom objects in the “addition” section of the difference report. Values are:

■ 0—Exclude from addition section (Default) ■ 1—Include in addition section

Table 7 Command-line options for Overlay mode (part 2 of 2)



Difference reports overview


BPCU generates a report that shows differences between the unmodified objects represented in an overlay hash file and objects on a server. It also shows which changed objects can be converted into overlays or custom objects, and which objects have been changed in a way that makes the conversion impossible.

Difference reports are produced in HTML, comma-separated values (CSV), or Microsoft Excel (XLSX) formats. By default, the report name uses the following format:

bpcu-diff-report_date_timestamp.extension

Difference reports are stored in this folder:

utilityInstallDir\Best_Practice_Conversion_Utility\output\

Table 8 describes the information that a difference report provides about objects and where you can find the information.

Table 8 Information in a difference report generated by BPCU (part 1 of 2)

Information XLSX report format HTML report format

Statistical information about all types of objects found on the server where BPCU was executed:

■ Total count of objects■ Number of new objects■ Number of changed objects■ Percentage customization■ Number of new and changed objects with nonpermitted

modifications

The following types of statistical information is displayed only when you use a certain execution parameter. See “Using BPCU to generate difference reports” on page 67.

■ Number of new objects that are not converted to custom objects when you execute BPCU in Overlay mode

■ Number of changed objects that are not converted to overlays when you execute BPCU in Overlay mode

Dashboard worksheet Dashboard tab

Whether an object on the server is new Difference Report worksheet, rows with the value Extension in the Customization Type column

Extensions tab



Whether an object on the server has been modified Difference Report worksheet, rows with the value Customization in the Customization Type column

Customizations tab

Whether modified objects in the server contain permitted or non-permitted modifications:

■ If an object contains non-permitted modifications, it is flagged as an object that cannot be converted into an overlay. All such objects must be fixed before running BPCU in Overlay mode.

■ If an object contains permitted modifications, it is flagged as an object that can be converted into an overlay.

For information about permitted and non-permitted modifications, see the Form and Application Objects Guide, “Permitted and non-permitted modifications on overlays,” page 129.

Note: When you run BPCU in ReportDiff mode with the -k option and its value as 1, the Customizations tab displays the Skipped During Conversion column. This column displays the value true for objects that are skipped during conversion whether they were modified in a permitted or non-permitted manner. Therefore, even if the Convertible to Overlay column for a particular object displays the value false, you do not need to fix any non-permitted modifications made on it.

Difference Report worksheet, rows with the value Customization in the Customization Type column

■ Permitted modifications:Convertible to Overlay = true

■ Nonpermitted modifications:Convertible to Overlay = false

Customizations tab, all panels

■ Permitted modifications:Convertible to Overlay = true

■ Nonpermitted modifications:Convertible to Overlay = false

■ Version of the utility that was executed to generate the report

■ Date and time when the report was generated■ Parameters supplied to the utility for the current

execution■ AR System applications installed in the execution

environment

Execution Information worksheet

Execution Information tab

NOTE BPCU does not include information in a difference report about objects that are unchanged.

Table 8 Information in a difference report generated by BPCU (part 2 of 2)

Information XLSX report format HTML report format



Figure 1 BPCU HTML report—Dashboard tab

Figure 2 BPCU HTML report—Extensions tab

Figure 3 Convertible to Overlay column in Customizations tab indicates whether the customization is permitted in overlays


BPCU log information

Figure 4 BPCU HTML report—Execution Information tab

BPCU log information

When the BPCU is first run on a server, it creates the BPCU-Log form. The form records information about each run of the utility, such as the run date, run mode, and return code. The form also stores the run’s log file and the difference report associated with the run as attachments.

By default, BPCU log file is

ARSystemServerInstallDir\Best_Practice_Conversion_Utility\bpcu.log

To change the log file name, modify the log4j.properties file.

Each time BPCU is run, the information in the bpcu.log file is overwritten. The previous version of the log is saved in the BPCU-Log form.

AR System application installation programs can use the bpcu.log file to determine whether BPCU was run and whether overlays were successfully created.


C h a p t e r 8
8 Viewing differences between objects
This chapter describes how to view details of differences between objects. It contains the following sections:

■ “Migrator Instruction Files and Difference Reports”

■ “Creating Difference Reports”

See “Upgrade paths and stages” on page 11 for an overview of all upgrade stages.

Migrator Instruction Files and Difference Reports

The Best Practice Conversion Utility (BPCU) generates a difference report that identifies objects that differ from the origin objects. However the differences are not described. BPCU also automatically generates the following instruction files for BMC Remedy Migrator when it is run in comparison mode (ReportDiff mode):

■ migrator-instruction_date_timestamp.xml—Lists all modified objects on the server, except specific views and fields that were modified.

■ migrator-npmod-instruction_date_timestamp.xml—Only lists objects with non-permitted modifications.

These files are located in the following folder:

utilityInstallDir\Best_Practice_Conversion_Utility\output\

Using these instruction files, the BMC Remedy Migrator command-line interface (CLI) creates .migrator files that contain the new and modified objects on a server. BMC Remedy Migrator can use these .migrator files to generate detailed difference reports.

Viewing differences between objects 75

Creating Difference Reports

Creating Difference Reports

To view details of differences between objects:

1 On StagingServer use the BMC Remedy Migrator instruction file that was generated in the last execution of the BPCU in comparison mode (from step D of stage 2), to create a .migrator file as follows:

migratorcli -m -s serverName -t serverport -u adminUserName -p password-g “Migrator Configuration.xml” -d migratorFileDestination -i instructionFileNameAndPath

See the BMC Remedy Migrator Guide, Appendix A, “Migrator command-line interface ” for details on using the Mirgator CLI commands.

2 From ReferenceServer, use the same BMC Remedy Migrator instruction file to create a second .migrator file.

3 In BMC Remedy Migrator, open the .migrator file created in step 1, and compare it with the .migrator file created in step 2.

4 Generate a report of the comparison and use it to view the details of differences between objects.

NOTE Ensure that you have set your BMC Remedy Migrator configuration options before performing the following procedures. For details one setting the Migrator configuration options, see Appendix B, “Migrator configuration options.”.


C h a p t e r 9
9 Delta Data Migration
This chapter describes Delta Data Migration, which is used in stage 7 to move data created or data that was changed after copying the production database from your production server to StagingServer. It contains the following sections:

■ “Delta Data Migration overview”

■ “Restrictions on product activities during the delta data period”

■ “Preparing the destination server for Delta Data Migration”

■ “Performing the Delta Data Migration”

■ “Extending Delta Data Migration to include customizations”

■ “Performing Delta Data Migration for server groups”

■ “Resolving post-Delta Data Migration issues for BMC Service Request Management”

Delta Data Migration overviewDelta Data Migration is a tool is used by the staged upgrade method to allow modified data from a production server to be synchronized with a staging server that is being upgraded. The staged upgrade method is designed to minimize server downtime, because the lengthy software upgrade process is not being run directly on the production server. Delta data refers to any data changes that have occurred on the production server during the upgrade of the staging server.

Using the staged upgrade method, a staging server is created, which is an exact copy of the production server at a specific point in time. Then, the active applications on the staging server can be upgraded to the target versions without affecting the current production server. While the staging server is being upgraded, the

Delta Data Migration 77

Restrictions on product activities during the delta data period

production server continues to run and changes to the current production database that occurred while the staging server was being upgraded are also applied. After validation, the staging server becomes the new production server. This greatly minimizes production server downtime, because the production server only needs to be taken offline long enough to perform the Delta Data Migration process to get the latest data onto the staging server.

Delta data refers to any data changes that have occurred on the production server during the upgrade of the staging server. By using a staging server that is a clone of the production environment, the active applications can be updated to the target versions without affecting the current production server. This includes applying customizations that were made to out-of-the-box BMC Remedy Action Request (AR) System application and server objects. Changes to the current production database that occurred while the staging server was being upgraded are also applied. After validation, the staging server becomes the new production server


The delta data period starts when you take the production database backup and ends when the Delta Data Migration is successfully completed.

Do not perform the activities listed in Table 9 during the delta data period.

Table 9 Tasks that should not be performed after backup.Product Restrictions

BMC Atrium Core(all versions)

Do not:

■ Create or modify classes

■ Create or modify any federation sources

BMC Service Level Management

Do not:

■ Create, modify, or delete service targets, contracts, agreements, and the data source section of configuration data

■ Create or modify approval chains for service requests

■ Make changes to the Request Catalog entries including service request definitions, process definition templates and application object templates



BMC Remedy ITSM Suite (when upgrading from 7.0.3 to 7.5.x or 7.6.x versions)

Do not create or update any of the following contracts:

■ Support

■ Warranty

■ Lease

■ Maintenance

■ Software License

■ License Management Exceptions

Do not create or update any of the following forms:

■ APR:Approver Lookup (approval mappings)

■ APR:SYS-Approval Definition (approval process definition)

BMC Service Request Management

Do not:

■ Make changes to any of the BMC Service Request Management configurations in the Application Administration Console, including changes to categories, approval mappings, or entitlements.

■ Create or modify approval chains for service requests.

■ Make changes to the Request Catalog entries including service request definitions, process definition templates and application object templates

Note: If you are upgrading BMC Service Request Management from a 2.2 version to a 7.6.02 or earlier version, then all service requests in the Waiting Approval state must be approved or rejected before you run the Delta Data Migration tool.

Product Restrictions


Preparing the destination server for Delta Data Migration

Preparing the destination server for Delta Data Migration

After the upgrade is complete and customizations are re-applied, the environment is ready for Delta Data Migration.

To disable DSO

The Distributed Server Option (DSO) must be disabled on all application servers before conducting the Delta Data Migration. For more information, see Administering BMC Remedy DSO for BMC Remedy AR System 7.6.04 and the BMC Remedy Distributed Server Option Guide for BMC Remedy AR System 7.6.04 on the Customer Support website.

To disable escalations

Escalations must be disabled on all application servers before conducting the Delta Data Migration. For more information, see the BMC Remedy Action Request System 7.6.04 Configuring on the Customer Support website.

To disable database triggers

All database triggers within the AR System schema must be disabled. Work with your database administrator to disable the triggers.

To fix backend data on the production server

The following known issues must be corrected by using SQL scripts on the production server before running the BMC Remedy Migrator scripts.


To fix backend data on the production server

Issues

■ On the TMS:Task form, the Seconds_before_Time_Out hidden field is designed to accept values between 0 and 2147483647. Occasionally, this field can be set inappropriately to negative values through workflow. When BMC Remedy Migrator utilizes the BMC Remedy AR System API to conduct its activities, the field definition violations are not allowed. This results in errors and data not being migrated.

■ On the TMS:Summary data form, the Task or Task Group Status field accepts values between 1000 and 7000. Occasionally, this field can be set inappropriately to values of 0 and 1 through workflow. When BMC Remedy Migrator utilizes the BMC Remedy AR System API to conduct its activities, the field definition violations are not allowed. This results in errors and data not being migrated.

■ On the CTM:People form, the Open Tasks field is designed to accept values between 0 and 2147483647. Occasionally, this field can be set inappropriately to negative values through workflow. When BMC Remedy Migrator utilizes the BMC Remedy AR System API to conduct its activities, the field definition violations are not allowed. This results in errors and data not being migrated.

Solution

1 From the package zip file, extract the tms_select.sql and tms_update.sql scripts.

2 Execute the tms_select.sql script.

3 If records are reported or found, execute the tms_update.sql script to correct the data.

Work with your database administrator to execute these ANSI SQL scripts on the database.

To set the Max Entries parameter in BMC Remedy AR System server

Check and fix server settings on the source and destination servers. The Max Entries Returned by GetList parameter should be set to 0, to cover all delta data in the forms.

NOTE These issues do not result in loss of functionality. These fixes are required to ensure that the Delta Data Migration does not produce errors.


Performing the Delta Data Migration

Performing the Delta Data MigrationThis section describes the Delta Data Migration tool package contents and how to perform the migration to load data that changed while the staging server was upgraded

The Delta Data Migration tool that is included with BMC Remedy Migrator consists of the following components:

■ Configuration.xml – This file is used by the DeltaMigration.exe executable to run the correct package versions from the Packages folder.

You must also add "C:\Program Files\BMC Software\migrator\migrator" to your environment Path variable in your computer settings.

■ DeltaMigration.exe – This is the executable that should be run to compare or migrate your data from the current production server to the staging server (new production server).

The Delta Data Migration tool consists of the following folders:

■ Packages folder–Contains the package, instruction XML files and the mapping files for all supported versions of BMC Remedy AR System, BMC Atrium, BMC Remedy ITSM, BMC Service Level Management, BMC Service Impact Manager, Integration for BMC Remedy Service Desk, BMC ProactiveNet Performance Management, BMC Service Request Management, and BMC Remedy Knowledge Management.

■ Utilities folder—Contains two utilities that can be used to find and package custom forms from your server. See “Appendix A. Extending the Delta Data Migration tool to include customizations

NOTE Update the Configuration.xml file with the migrator installed directory path. By default it is set as follows:migrator-dir="C:\Program Files\BMC Software\migrator\migrator"


To resolve issues before Delta Data Migration


Issue 1

If BMC Service Impact Manager or BMC ProactiveNet Performance Management applications are installed on your server, you must update the configuration XML file before you perform Delta Data Migration, because both applications have the same application GUID.

Solution 1

To resolve this issue:

1 Go to the folder where BMC Remedy Migration is installed: migratorInstallDirectory\DeltaDataMigration

2 Open the configuration XML file.

3 Do one of the following:

■ If BMC ProactiveNet Performance Management is installed, comment out the SIM code lines.

■ If BMC Service Impact Manager is installed, comment out the BPPM code lines.

NOTE Do not modify the contents of any folders, unless directed to do so by BMC.


For example, to comment out the BPPM code lines, insert  tags as follows:





Issue 2

BMC Service Impact Manager depends on BMC Atrium Core being installed. You cannot migrate BMC Service Impact Manager and BMC Atrium Core at the same time.

Solution 2

If you have installed BMC Service Impact Manager, you must perform the Delta Data Migration for BMC Atrium Core before you run the Delta Data Migration for BMC Service Impact Manager.

Issue 3

Integration for BMC Remedy Service Desk 7.1 is not registered in the SHARE:Application_Properties form and so the Delta Data Migration tool is unable to detect the Integration for BMC Remedy Service Desk 7.1 installation on the production server. A defect numbered SW00388960 has been opened to fix these issues in the next release.

NOTE This issue applies if you have installed version 7.1 of Integration for BMC Remedy Service Desk on your production server.


Solution 3

An entry for Integration for BMC Remedy Service Desk 7.1 should be created in the SHARE:Application_Properties form. Import the .arx file attached to the defect numbered SW00388960. If you do not have access to the defect, obtain the hotfix from Customer Support.

Issue 4

The default value of the Parent Linked field on the Task form was set to incactive and the task escalation deleted the migrated records. And, the field length for the field ID 8 on the CHG:CFG Ticket Num Generator form was changed to 100 from 128. Defects SW0409171 and SW00400766 have been opened to fix these issues in the next release.

Solution 4

To correct these issues, apply the fix in ITSM_App_issue_fix_pre_DDM_hotfix.zip, which is located in the <Migrator Install folder>\DeltaDataMigration\Utilities\pre_DDM\ folder. Follow the instructions in the readme.txt file.

Issue 5

Some data did not migrate due to change in selection field values in an upgrade for CTM:CFG-ApplicationPreferences form data. Defect number SW00409460 has been opened to fix this issue in the next release.

Solution 5

Apply the SQL fixes as directed in the file <Migrator Install folder>\DeltaDataMigration\Utilities\pre_DDM\Reademe_for_Ctm_App_Pref_Sql_Fix.txt .


To perform data migration


Observe the following guidelines when migrating data:

■ Use the same Admin user account to log in to both servers. The upgrade environment is a database restore of the production environment. BMC recommends that you use one user to do this migration, which will help to track and debug issues. If you use Demo, ensure that you have the same password for both servers for that Admin account.

■ You can run the Delta Data Migration tool once or multiple times. BMC recommends that you run the tool at least twice—once before you start your production outage, and then a final time right after the production outage begins. The first data migration moves all of the data that has been added or changed since you made the production backup. The second migration moves only the data that has changed since you started the first data migration. This ensures that the time required to do the data migration (your outage window) is as small as possible.

■ If you are using the multi-run approach to migration to minimize your downtime, ensure that the following check box is not selected:

Re-run applications with previous criteria & instructions

Use the Delta Data Migration tool to migrate data from the production server to the staging server as follows:

1 Go to the C:\Program Files\BMC Software\Migrator\migrator\DeltaDataMigration directory. This is the default path.

For more information on the package contents, see 6.1 Delta Data Migration tool package contents

2 Double-click the DeltaMigration.exe file.

The Delta Migrations screen displays.

3 Open the Server dialog by clicking the button to the right of the Source Server field.

The Server dialog displays the following fields:

■ Source Server— This is the source server name (production server).

■ User Name— This is the user name of the source server and destination servers. The user name should be the same.



■ Password— This is the password of the source server and destination servers. The password should be the same.

■ TCP Port— This is the default value used by the script. If no port is specified, the default is 0.

■ Fast/List Port— The default is 390635.

4 Input the source server information in the dialog and click OK.

5 Open the Server dialog again by clicking the button to the right of the Destination Server field.

6 Enter the destination server (staging server) information and click OK.

After you provide the source and destination server information, the Delta Data Migration tool validates the versions on your source and destination servers and provides a list of all supported BMC Remedy AR Server products and applications. Applications shown in red indicate that no appropriate package was found.



The Delta Migrations window contains the following:

■ Fetch Data/Objects Created/Modified After Date field—The timestamp from when you want to transfer the data. Data in the forms that are greater than or equal to this timestamp will be migrated.

■ Compare (optional) button—This button optionally creates a comparison result report. This report can be used to identify all data that has been created and/or updated during the delta time period.

■ Migrate button—This button starts the data migration. All delta data is transferred from the source server to the destination server.

■ Delete (optional) —This button is optionally used if any records were deleted from the database rather than only deleted from the applications during the delta period. Any orphan data is removed from the staging server.

■ Re-run applications with previous criteria & instructions check box—This check box is checked by default and should remain checked even if you are rerunning the migration after fixing any data issues.


To review the migration results

If the Re-run applications with previous criteria & instructions check box is unchecked, the Delta Data Migration will be based solely on the time stamp

7 Select all applications that are not marked in red and provide the date and time when you want to migrate the data.

8 If you are not migrating custom forms data, you can deselect the custom selection in the application name list.

9 Click Migrate or Compare.

The Delta Migration window displays and shows the parameters that will be used by the Migrator.

10 Click Yes to continue with the migration or comparison and launch the command prompt windows. One command window is launched for each application you are running. The windows close automatically when the process is done, or if there is an error. If you click No, the migration or comparison will be cancelled.

The command output will be available as an HTML log file as described in the following section.


This section describes how to review the Delta Data Migration tool log files and to validate the migration results.

Reviewing log files

The Delta Data Migration tool creates HTML-based log files by using the package names that have the .html suffix:

■ Migrate.html

NOTE If this is the first time you are running the migration, the timestamp that applies is when the production server backup was used to create the staging server. If this is a multiple-run scenario, the timestamp that applies is when you initiated the previous run.

NOTE If you want to re-run the migration or the comparison, you must wait for all of the command prompts windows to close before executing a new run.



■ Compare.html

■ Delete.html

Search the HTML log files for the following keywords:

■ ERROR – Lists the form information and data for a server, API, or SQL error.

■ WARNING or WARN – Describes warnings from BMC Remedy AR System that do not stop the package migration.

The Delta Data Migration tool also creates .mgrresult files and comparison output XML files:

■ Migrate script details:

The migrate script creates a .mgrresult file for each instruction with the instruction name and suffix _Migrate that includes the results of migrating all the form data (entries). This file should be opened with BMC Remedy Migrator. It lists the number of entries that were migrated for each form and includes the same error information (if any) that the HTML log file contains.

Examples of BMC Remedy Migrator output file names are:

■ ITSM_Package_Migrate.html – this is the migrator log file (you will have one of these for each package)

■ Remedy_Service_Request_Management_Migrate.mgrresult – this is the migrator result file (you will have one of these for each instruction file)

■ Compare script details:

Apart from the HTML log file, the comparison script will also create an .xml result file for each instruction with the instruction name and suffix _Compare. These files include all data entries that are either different or missing in the destination server.

Examples of compare output file names are:

■ ITSM_Package_Compare.html– this is the compare log file (you will have one of these for each package)

■ Remedy_Service_Request_Management_Compare.xml– this is the compare .xml result file (you will have one of these for each instruction file)

Validating the Delta Data Migration

Check the log files for errors and contact Customer Support as needed for assistance.



This section contains lists of known errors and warnings that may occur in your log files.

■ The following warning in the ITSM_Foundation_Migrate and ITSM_Foundation_Compare HTML files can be ignored if the forms are not on your source server:

■ The following errors in the BMC Remedy Task_Management_Migrate and Remedy Task_Management _Compare HTML files can be ignored if the forms are not on your source server:

■ The following errors in the BMC Remedy Foundation Elements_Migrate and BMC Remedy Foundation Element_Compare HTML files can be ignored if the forms are not on your source server:

If you run a compare report after a successful migration, then no data with “state=different” or missing data is expected. The compare report should not report any differences.

The Remedy_Contract_Management_<datetime>_compare.xml output file might report the following differences which can be ignored, because the source server does not have default value data for the fields listed. However, the destination server does have this data.

Keyword Error Description

ERROR Migrations An Error Occurred with Data 'AST:AssetAdvancedSearchCriteria

ERROR Migrations [4]-[303]-[Form does not exist on server AST:AssetAdvancedSearchCriteria

ERROR Migrations An Error Occurred with Data 'AST:CILifeCycleStatus’

ERROR Migrations [4]-[303]-[Form does not exist on server 'AST:CILifeCycleStatus'


ERROR Migrations An Error Occurred with Data 'TMS:RelationshipsInterface_Create'

ERROR Migrations [4]-[303]-[Form does not exist on server 'TMS:RelationshipsInterface_Create'


ERROR Migrations An Error Occurred with Data 'CFG:HTMLCatalog'

ERROR Migrations [4]-[303]-[Form does not exist on server 'CFG:HTMLCatalog'



<data destination-form="CTR:ContractBase" source-form="CTR:ContractBase" unique-field-id="179">

<entry entry-id="000000000000001" id="CO0050560C63F20vnfQwlG06AALAMA" state="different">

<field id="260600003" name="Purchase Cost" state="different" />

<field id="260600004" name="Renewal Cost" state="different" />

<field id="270002042" name="Cost per Asset" state="different" />

<field id="270002043" name="Cost per Component" state="different" />

■ If you are migrating data from BMC Remedy ITSM versions 7.0.02 or 7.0.03 with or without patches, you will see the following errors in the ITSM_Foundation_migrate_<datetime>.html file. This is a known issue that occurs because data migration in the APR:Approver Lookup and APR:SYS-Approval Definition forms is not supported.

For more information, see the BMC Remedy ITSM product restrictions in the Restrictions on product activities during the delta data period.

The following errors might appear for the APR:Approver Lookup form:

The following errors might appear for the APR:SYS-Approval Definition form:

■ If your source BMC Service Request Management version is 2.2 or 2.2 patch 1, you may see the following errors in the .html log file and these errors can be ignored as they are benign.


ERROR Migrations An Error Occurred with Data 'APR:Approver Lookup'

ERROR Migrations [4]-[986]-[Currency fields can not be used for grouping.]


ERROR Migrations An Error Occurred with Data 'APR:SYS-Approval Definition'

ERROR Migrations [4]-[985]-[No active Currency Code found on the Currency Code form.]


ERROR Migrations An Error Occurred with Data 'WOI:Associations'

ERROR Migrations [4]-[303]-[Form does not exist on server WOI:Associations]


Extending Delta Data Migration to include customizations

The SRD:AuditDisplay form is not to be updated during the delta data period, which means that the following errors can be ignored:

Applying the BMC Service Request Management hotfixes

If you have not already applied BMC Service Request Manage hotfixes, complete the steps in Appendix C and then resume the validation starting with the next section.

Running a sanity level validation

Conduct a sanity level validation by running SQL scripts available for all the products and versions supported by Delta Data Migration, which are available in the migratorInstallDirectory\DeltaDataMigration\Utilities folder. The scripts should be executed both on the current production and staging servers.

Backing up the staging server database

Following a successful migration, back up the staging server database.

Extending Delta Data Migration to include customizations

This section provides an overview of the application package contents. It explains how to add custom forms to the Delta Data Migration package so that you can also migrate the data in these custom forms. Instructions for updating a field mapping file to correct customer-defined fields in the BMC Remedy reserved range are also included.


ERROR Migrations An Error Occurred with Data 'SRD:AuditDisplay'

ERROR Migrations for this form does not match that in owning application SRD:AuditDisplay]

ERROR Migrations [4]-[9858]-[The application is not licensed Remedy Service Request and Catalog System]


Understanding the application package

Understanding the application package

Each application (BMC Remedy AR System, BMC Atrium Core, BMC Remedy ITSM Suite, BMC Service Request Management, and BMC Service Level Management consists of:

■ One package XML file – Lists the instruction files that need to be executed in order.

■ Many instruction XML files – Provide details for the forms that have data that is being migrated. Each package XML file references one or more of these instruction files.

■ arm files – These are the field mapping files. One or more instruction files refer to these .arm files.

The instruction files contain the following information specified for each form:

■ Source and destination form name

■ Unique field IDs

■ Qualification to be used to migrate the data:

‘3’ >= "<DATE>” OR ‘6’ >= "<DATE>”, which is Create Date or Last Modified Date

■ Migrate option is set to update, which will update existing records if the same record is already present and create new records if not present.

■ Option set to not trigger any workflow during the migration.

If no mapping files are referenced in the instruction files for a form, the migrator moves data from all fields in the production server to the staging server.

Mapping files are created in these situations:

■ For forms that need mappings for newly created fields in applications

■ For any field needs to be mapped to a different field in the destination server

Example instruction XML file:

<data enabled="true" source-form="FIN:ConfigRules" destination-form="FIN:ConfigRules" type="data" mode="search"merge-option="update" ignore-required-fields="true"ignore-pattern-matching="true" count="0" disable-related workflow="true">


Manually adding custom forms to the package

<qualification>PASS_QUALIFICATION</qualification> <unique-fields> <field id="270002020" /> <field id="1000000001" /> </unique-fields><ports enabled="true" list="LIST_PORT" fast="FAST_PORT" />

</data>

A package XML file is created that lists the instruction XML files and specifies their execution order.

Manually adding custom forms to the package

1 Open the Custom_Form_Instruction.xml instruction file, which is available in the migratorInstallDirectory\DeltaDataMigration\Custom folder. The file will contain information that is similar to the instructions XML example.

2 Provide your custom form name and the unique field IDs (unique index field IDs) in their respective tags. Follow the same process for all of the forms that you need to add. If there are no unique indexes for your form then specify field 1 as the unique index.

3 Open the Custom_Form_Package.xml package file, which is available in the migratorInstallDirectory\DeltaDataMigration\Custom folder.

4 Provide the instruction XML file names in the package XML file:

<instructions file="custom_forms_instruction.xml type="all" command="migrate" enabled="true"/>

<instruction name="CustomForms"/></instructions>

5 Once you have saved both your instruction and package XML files, you are ready to run the migrate, compare, and delete scripts for the custom package. The new package will run in parallel in a separate command window in the same way as the Delta Data Migration out-of-the-box package files.


Adding custom forms to the package by using the Customer Form Instruction Generation tool


Follow this procedure if you do not have the list of your custom (non-BMC) regular forms.

The following batch files must be executed:

■ The migratorFindCustomForms.bat utility will find all of your custom forms from the BMC Remedy AR System Server that are not recognized as BMC Software forms. The utility generates a CSV file that includes the list of all custom form names with their unique indexes.

■ The migratorCSV2Instructions.bat utility uses the generated CSV file as the input, and creates the Custom_Form_Instructions.xml file for the custom forms in the CSV file.

1 Navigate to the installation directory.

InstallDirectory\Migrator\migrator\DeltaDataMigration\Utilities\migratorUtilities.

2 Run the migratorFindCustomForms utility by using the following syntax:

migratorFindCustomForms.bat -s sourceARServerName -u adminUserID -p adminPassword -P ARServerPort -f filterFileName

For example:

migratorFindCustomForms.bat -s test.bmc.com -u Demo -p "" –P 2020 –f ExampleFiles\Examplefilter.dat

3 Open the CustomForms.csv output file in a text editor or spreadsheet application.

4 If any form that should not be migrated is included in the list, remove the entire line.

NOTE In this example, the Examplefilter.dat file contains the list of forms that should be excluded from migration.



Forms that are used for testing or to keep temporary data should not be included. If you are not sure, it is better to include the form in the migration. Migrating a form multiple times is permitted.

5 Save the changes you made to the CustomForms.csv file.

6 Run the migratorCSV2Instructions utility by using the following syntax:

migratorCSV2Instructions.bat -i CustomForms.csv -pk packageFileName

This utility generates an instruction file that will be read by BMC Remedy Migrator and used for the migration.

For example:

migratorCSV2Instructions.bat -i CustomForms.csv -pk Custom_Forms_Package.xml

7 Verify that the output file is CustomForms.xml.

8 Rename CustomForms.xml to Custom_Form_Instructions.xml.

9 Copy the Custom_Forms_Package.xml and Custom_Form_Instructions.xml files to the Packages\Custom directory and replace the same files in the directory by overwriting them.

10 Verify the new instruction files by running a comparison.

The comparison validates that the forms are present on both the source and destination servers.

NOTE You can save the names of forms to be excluded in a separate file, then you can use that file the next time you run migratorFindCustomForms.


Updating a field mapping file


If a field ID has been updated (by using the BMC Remedy AR System ARCHGID utility) to fix customer-defined fields in the BMC Remedy reserved range, the source and destination field mapping information must be added or updated in a field mapping .arm file.

To create or update an .arm file and update the reference in the instruction XML file, perform the following steps:

1 Under the packages folder, open the correct version folder.

The following figure shows the version folders for Atrium CMDB:

2 Open the instruction file that needs its form mapping information to be updated.

The following figure shows an example for BMC Atrium CMDB:

3 Create a mapping (.arm) file and map the custom source field ID to the destination field ID (which has a new ID after running the ARCHGID utility).



The following figure shows an example of a mapping file:

4 Add the mapping file name to the form reference in the instruction file, as shown in the following example:


Performing Delta Data Migration for server groups


To perform a Delta Data Migration for a server group:

1 Perform steps 1 though 6 of the Delta Data Migration process on the primary staging server defined earlier in this document. At this point, the outage window has begun and the final data migration is complete.

■ If you are using a load balancer in front of the mid tiers, make all mid tiers unavailable in the load balancer.

■ If you are using a load balancer between the mid tiers and the BMC Remedy AR System servers, make all BMC Remedy AR System servers unavailable in the load balancer.

2 Stop all BMC Remedy AR System servers in the server group.

3 Promote the staging server to the production server group.

A Rename the staging server to the same host name as the production administration server.

The staging server will replace the original administration server in the server group.

B Restart the BMC Remedy AR System server.

C Make the administration server available in the load balancer.

D Verify that you can connect to the administration server by using the BMC Remedy AR System server Virtual IP (VIP).

4 If you have not already done so, upgrade one of the mid tier servers.

A After the upgrade, flush the mid tier cache to update it for the 7.6.04 release.

B After the mid tier cache is refreshed, make the mid tier available in the load balancer.

NOTE Because the mid tier server is backwards compatible. the upgrade of the mid tier servers can be done before the BMC Remedy AR System server upgrades.



C Verify that you can connect to the BMC Remedy AR System server through the mid tier VIP.

At this point the production environment is running in a diminished capacity (there is one mid tier and one BMC Remedy AR System server).

5 Upgrade each one of the secondary BMC Remedy AR System servers in the server group.

A Point the database client to the newly-upgraded database instance that is set up on the staging server.

This is the new production database.

B If needed, update the BMC Remedy AR System server configuration file with the new database connection information.

C Upgrade each of the BMC Remedy components by following the upgrade instructions provided with each component.

Be sure to follow any special instructions related to server group environments.

Upgrade in the following order:

■ BMC Remedy AR System

■ BMC Atrium

■ BMC Remedy ITSM

■ BMC Service Level Management

■ BMC Service Request Management

■ BMC Remedy Knowledge Management

■ BMC Service Impact Manager

■ BMC ProactiveNet Performance Management

D Verify that you can connect directly to this BMC Remedy AR System server.

E Make each BMC Remedy AR System server available in the load balancer.


Resolving post-Delta Data Migration issues for BMC Service Request Management

6 Upgrade the remaining mid tier servers by following the procedure in step 5.

7 Review the server group managed services to ensure that the rankings for the services are set up correctly in the AR Server Group Operation Ranking form.

The production environment is now fully functional and at full capacity.

Resolving post-Delta Data Migration issues for BMC Service Request Management

The following information describes the post-Delta Data Migration procedure for BMC Service Request Management response data.

This procedure applies when the BMC Service Request Management source version is 2.2.00 Patch 1 (or earlier). For all other combinations, there is no need to complete the following procedure.

Issue

When the source version of BMC Service Request Management is 2.2.00 patch 1 or earlier and the target version for BMC Service Request Management is 2.2.00 patch 2 or later, then Delta Data Migration does not migrate the Service Request Question Response information, due to a data model change. A hotfix is available to migrate the question responses data.

NOTE This step should be done in parallel with the upgrade of the secondary BMC Remedy AR System server, or even before beginning the upgrade of the production server group.


Solution

Solution

1 Run the Delta Data Migration tool as usual to migrate data for all applications including BMC Service Request Management.

2 After the migration has completed, install the BMC Service Request Management post-Delta Data Migration bundle:

A Open a command window, and change to the Utilities\post_DDM\SRM\patches directory.

B Run the installer with the following command line options:

setup.bat destinationServer user password port

C Follow the prompts and wait for the installer to finish.

3 Check the logs located in the Utilities\post_DDM\SRM\Logs directory to ensure that the package installed correctly.

If there are any errors, correct them before re-installing the bundle.

4 Using the Windows User Tool, or mid tier, open the DDM:MigrationTasks form and search for the entry with ‘Task Tag’ = “DDM_MigrateSRM2200-2200p2.”


Solution

5 Edit the Delta Start Time to reflect the date and time when the Delta Data Migration snapshot was taken.

Only request response entries that are created or modified after that time will be migrated.

6 Set the Migrate Data field to Yes and save the entry.

This starts the migration process. At the end of the migration, the Migration Status field should display as “Successful.”


A p p e n d i x A
A Overlay hash files
This appendix describes the hash files provided by BMC. It contains the following sections:

■ “BMC product information”

■ “BMC integration information”

■ “Obtaining the hash files for analyzing and converting customizations”

An overlay hash file, also called a snapshot, is an XML file that contains keys of all the objects in a particular version of AR System or an AR System application:

■ For fields and views, the key is the object’s ID.

■ For all other objects, the key is the object’s name.

The Best Practice Conversion Utility (BPCU) compares objects in an overlay hash file with those in a customized AR System component or application. BPCU produces a difference report that contains the results of the comparison. See “Using BPCU to generate difference reports” on page 67.

BMC product informationIf you are upgrading from the following releases, you can use the BMC-provided overlay hash file (OverlayHashFile.xml) to compare the objects in your customized applications with the objects in the origin applications:

■ AR System and its components (including AR System server, BMC Remedy Approval Server, BMC Remedy Assignment Engine, BMC Remedy Email Engine, BMC Remedy Flashboards, AREALDAP plug-in, ARDBC plug-in, and Web Services) with the versions:

■ 6.3 and 6.3 patch 025


BMC product information

■ 7.0.01, 7.0.01 patch 007 through 7.0.01 patch 011

■ 7.1.00 patch 002 through 7.1.00 patch 011

■ 7.5.00 through 7.5.00 patch 007

■ 7.6.02

■ 7.6.03

■ 7.6.04

■ 7.6.04 SP 1

■ 7.6.04 SP 2

■ BMC Atrium CMDB versions:


■ 2.1.00 through 2.1.00 patch 006

■ 7.5.00 through 7.5.00 patch 005

■ 7.6.00 through 7.6.00 patch 002

■ 7.6.00 patch 200

■ 7.6.03

■ BMC Remedy Enterprise Integration Engine versions:

■ 7.1.00 and all its patches

■ 7.0.01 and all its patches

■ BMC Remedy ITSM Suite versions:


■ 7.0.03 IMSLM patch 9004

■ 7.0.03 patch 9005

■ 7.5.00

■ 7.5.01 through 7.5.01 patch 003

■ 7.6.00 through 7.6.00 patch 001

■ 7.6.02

■ 7.6.03

■ BMC Remedy Knowledge Management versions:


BMC integration information

■ 7.2.00 through 7.2.00 patch 004

■ 7.5.00 through 7.5.00 patch 001

■ 7.6.03

■ BMC Service Level Management versions:

■ 7.1.00 through 7.1.00 patch 003

■ 7.5.00 through 7.5.00 patch 001

■ 7.6.00 through 7.6.00 patch 001

■ 7.6.02

■ 7.6.03

■ BMC Service Request Management versions:

■ 2.2.00 through patch 004

■ 7.6. through patch 002

■ 7.6.02

■ 7.6.03

■ BMC Remedy OnDemand versions:

■ 2010.01 and its hotfixes

■ 2010.02 GA03

BMC integration informationThe overlay hash file contains data about the following BMC integration objects:

■ BMC Remedy Identity Management

■ BMC BladeLogic Client Automation for Clients

■ BMC BladeLogic Client Automation for Server

■ BMC BladeLogic Server Automation

■ Integration for BMC Remedy Service Desk

■ BMC Atrium Discovery and Dependency Mapping (versions 7.5.00 and 8.1.015)

■ Configuration Discovery extensions (versions 7.0.00, 7.0.02, 7.1.01, 7.1.02, 7.2.00, 7.2.01, 7.2.02, 7.5.00, 7.5.00 patch 001, 8.0.00, 8.1.00, 8.2.00) for CMDB


Obtaining the hash files for analyzing and converting customizations

■ BMC Topology Discovery 7.6.00

■ BMC IT Business Management

■ BMC Service Impact Manager (Extensions of versions 7.3.00, 7.3.01, 7.3.02 for BMC Atrium CMDB 2.1.00, and BMC Atrium CMDB 7.5.00 and 7.6.00)

■ BMC Remedy Mid Tier object list definition files for AR System 7.0.01, 7.1.00, 7.5.00, 7.6.02, and 7.6.03

■ Server group and DSO settings for AR System 7.0.01, 7.1.00, 7.5.00, 7.6.02, 7.6.03, and 7.6.04

Obtaining the hash files for analyzing and converting customizations

You need the following file:

■ Overlay hash file—OverlayHashFile.zip

To obtain the overlay hash file:

1 Download the latest version of the OverlayHashFile.zip file from the BMC Developer Network Community website.

2 Uncompress the .zip file and extract the OverlayHashFile.xml file to your development server.

NOTE Updates to the overlay hash file between patch releases are posted to BMC Developer Network Community website. Always make sure to download the latest version from this location.


A p p e n d i x B
B Migrator configuration options
This appendix describes how to set BMC Remedy Migrator configuration options on systems that are running the BMC Remedy Migrator utility.

To set BMC Remedy Migrator configuration options before migration

1 Open the migratorInstallDir\Migrator Configuration.xml file.

2 Update the <required> section as follows:

<required><param name=“MergeSharedWorkflow” enabled=“false”/><param name=“Menus” enabled=“false”/><param name=“TableFieldForms” enabled=“false”/><param name=“JoinFormMembers” enabled=“false”/><param name=“FlashboardVariables” enabled=“true”/><param name=“FlashboardDataSources” enabled=“true”/><param name=“MenuRelatedForms” enabled=“false”/><param name=“ApplicationStates” enabled=“true”/><param name=“ApplicationForms” enabled=“false”/></required>

3 Update the <removal...> section as follows:

Either add the entire <removal...> section shown below (if it does not exist), or add the lines for Fields and Views (listed below) to the existing section, or change the values for Fields and Views in the existing section to enabled="false").

<removal action="delete" type="specified"><object type="Fields" enabled="false"/> <object type="Views" enabled="false"/> </removal>

4 Save and close the configuration file.

Appendix B Migrator configuration options 109

A p p e n d i x C
C System objects that might be overwritten during upgrade
This appendix provides a list of AR System server definitions that may be lost or overwritten when you upgrade from earlier versions of AR System server to version 7.6.04 SP2 (assuming that you only select AREA LDAP during installation). If you have modified any of these objects, you should save a copy and restore your changes after upgrading the server.

Table C-1: System objects that may be overwritten during an upgrade

■ Alert Events ■ AR System Multi-Form Search■ Alert List ■ AR System Object Relationships■ Application Pending ■ AR System Orchestrator Configuration■ Application Statistics ■ AR System Report Console■ Application Statistics Configuration ■ AR System Report Designer■ AR Sample Application: Console ■ AR System Report Preview■ AR System Actor View ■ AR System Resource Definitions■ AR System Administration: Add Or Remove

Licenses■ AR System Searches Preference

■ AR System Administration: Console ■ AR System Skins■ AR System Administration: Display Form To

Collect User Decisions■ AR System Skins Properties

■ AR System Administration: License Review ■ AR System Skins: Color Picker■ AR System Administration: Manage User

Licenses■ Data Visualization Definition

■ AR System Administration: Prompt For Open Attachment

■ Data Visualization Module

■ AR System Administration: Server Information ■ Data Visualization System Files■ AR System Administration: Server

Information:Save Attachment■ Distributed Logical Mapping

■ AR System Administration: Support Form ■ Distributed Mapping■ AR System Administrator Preference ■ Distributed Pending■ AR System Alert Delivery Registration ■ Distributed Pending Errors


■ AR System Alert User Registration ■ Distributed Pool■ AR System Application State ■ FB:Alarm Events■ AR System Currency Codes ■ FB:Alarm Monitor■ AR System Currency Label Catalog ■ FB:Datasource■ AR System Currency Localized Labels ■ FB:DataSourceVariables■ AR System Currency Ratios ■ FB:Flashboards■ AR System Current License Usage ■ FB:History■ AR System Customizable Home Page ■ FB:History Summary■ AR System Form Field Info ■ FB:User Privilege■ AR System Historical License Usage ■ FB:Variable■ AR System Home Page Descriptor ■ FB:Variable Attributes■ AR System Home Page Layout ■ Group■ AR System Ignored Analyzer Results ■ Home Page■ AR System License: Save Produse Attachment ■ MFS:MultiFormSearch■ AR System Licenses ■ RD:Save As■ AR System Licenses Audit ■ Report■ AR System Licenses Console ■ Report Definition■ AR System Log: Alert ■ ReportCreator■ AR System Log: ALL ■ ReportSelection■ AR System Log: API ■ ReportType■ AR System Log: Escalation ■ Roles■ AR System Log: Filter ■ Sample:Cities■ AR System Log: FullText Index ■ Sample:ClassCentral■ AR System Log: Server Group ■ Sample:Classes■ AR System Log: SQL ■ Sample:DialogYesNo■ AR System Log: Thread ■ Sample:Enrollments■ AR System Log: User ■ Sample:GetWeather■ AR System Message Catalog ■ Server Events■ AR System Skins: Skinnable Properties ■ Server Statistics■ AR System Tags ■ SHARE:Application_Interface■ AR System User Application Actor ■ SHARE:Application_Properties■ AR System User Central File ■ User■ AR System User Preference ■ User Password Change■ AR System Version Control: Label ■ User Password Change Redirector■ AR System Version Control: Labeled Object ■ User Password Management Configuration■ AR System Version Control: Object Modification

Log■ Visualizer Module Images

■ AR System Version Control: Object Reservation ■ Visualizer Module Registration■ AR System Version Control: Task ■ Visualizer Type Information■ AR System Web Services Category ■ Visualizer Type Object Props■ AR System Web Services Registry ■ Visualizer Type Style Info■ AR System Web Services Registry Pending Delete ■ Data Visualization Definition



■ AR System Web Services Registry Query ■ Data Visualization Module■ AR System: Generate License Usage Report ■ Data Visualization System Files■ ARC:ConfirmDialog ■ Distributed Logical Mapping■ AREA LDAP Configuration ■ Distributed Mapping■ Business Segment-Entity Association ■ Distributed Pending■ Business Segment-Entity Association_Join ■ Distributed Pending Errors■ Business Time Holidays ■ Distributed Pool■ Business Time Segment ■ FB:Alarm Events■ Business Time Shared Entity ■ FB:Alarm Monitor■ Business Time Shared Entity-Entity

Association_Join_Join■ FB:Datasource

■ Business Time Workdays ■ FB:DataSourceVariables■ CHP:ConfirmDialog ■ FB:Flashboards■ Configuration ARDBC



*218771**218771**218771*

*218771*

7.6.04 sp2_upgrade tips.pdf

Documents

program files bmc software migrator migrator

themigratorinstalldirectory deltadatamigration custom folder

defect numbered sw00388960

previous criteria

health check tab

bmc atrium core

bppm code lines

database consistency check