7.6.04 SP2 - Upgrade Tips PDF

BMC Remedy IT Service Management Suite 7.6.
04 Service Pack 2 Upgrade Procedures and Guidelines

White Paper
Supporting
BMC Remedy Action Request System BMC Remedy IT Service Management Suite 7.6.04 SP 2
October 2011
www.bmc.com
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 INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 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 legend

U.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.
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 customer_support@bmc.com. (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
BMC Remedy Action Request System 7.6.04 Service Pack 2 Upgrade Procedures and Guidelines
Contents
Chapter 1 Introduction 9 Supported upgrade paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 The role of overlays in an upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Upgrade paths and stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Servers used in the staged upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Required upgrade tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Chapter 2 Staging server setup 17 17 18 19 20 20 22 25
Setup Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setup Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accelerated Staging Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Duplicated Staging Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Install the required software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Duplicating the Production Server Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3 Upgrade with overlays present
Stage 1 - Upgrade AR System server with overlays present . . . . . . . . . . . . . . . . . . . . . 26 Stage 6 - Upgrade applications and adjust customizations . . . . . . . . . . . . . . . . . . . . . . 27 Stage 7 - Test and promote staging server to production . . . . . . . . . . . . . . . . . . . . . . . 32 Chapter 4 Upgrade without overlays present 33 34 35 39 40 42 43 49 51 51 52 52 52 53 53 54 54 54 55 55
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 . . . . . . . . . . . . . . . . . . . . . . . Chapter 5 Fixing non-permitted modifications
Fixing non-permitted changes for objects that include __o in an object name . . . . . . Fixing non-permitted modifications for forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the inclusion or exclusion of a form in a deployable application . . . . Changing unique indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Vendor form information for Table Name or Vendor Name . . . . . . . . Changing Join form Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing View form information for Table name or Key field . . . . . . . . . . . . . . . Fixing non-permitted modifications for fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Column properties on View and Vendor forms . . . . . . . . . . . . . . . Changing the Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Changing the Length Units property of Character fields . . . . . . . . . . . . . . . . . . . . 55 Changing the Column field properties for Parent field ID, Data field ID and Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Changing the Entry Mode Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Changing the field type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Chapter 6 Comparing overlays to overlaid objects on the same server 59
Setting Migrator difference mask options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Comparing staging server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Chapter 7 Creating overlays with the Best Practice Conversion Utility 63
Usage overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Configuring your system for BPCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Using BPCU to generate difference reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Using BPCU to generate overlays for modified legacy objects . . . . . . . . . . . . . . . . . . . 69 Difference reports overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 BPCU log information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Chapter 8 Viewing differences between objects 75
Migrator Instruction Files and Difference Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Creating Difference Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Chapter 9 Delta Data Migration 77
Delta Data Migration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Restrictions on product activities during the delta data period . . . . . . . . . . . . . . . . . . 78 Preparing the destination server for Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . 80 To disable DSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 To disable escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 To disable database triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 To fix backend data on the production server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Performing the Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 To resolve issues before Delta Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 To perform data migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 To review the migration results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Extending Delta Data Migration to include customizations . . . . . . . . . . . . . . . . . . . . . 93 Understanding the application package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Manually adding custom forms to the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Adding custom forms to the package by using the Customer Form Instruction Generation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Updating a field mapping file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Performing Delta Data Migration for server groups. . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Resolving post-Delta Data Migration issues for BMC Service Request Management . . 102 Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 BMC integration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Obtaining the hash files for analyzing and converting customizations . . . . . . . . . . 108 Appendix B Appendix C Migrator configuration options System objects that might be overwritten during upgrade 109 111
Contents
Chapter
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 paths

Version 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 upgrade

In 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.
10
Upgrade paths and stages

To 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.
Table1: Upgrade stages Overlays already Without present overlays X X X X X X X X X X
Upgrade stage Stage 1 - Upgrade AR System server Stage 2 - Create overlays for existing customizations (optional but strongly recommended) Stage 3 - Acquire origin objects (optional) Stage 4 - Restore origin objects on staging server (optional) Stage 5 - Minimize overlays (optional) Stage 6 - Upgrade applications and adjust customizations Stage 7 - Test and Promote staging server to production
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.
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.
12 BMC Remedy IT Service Management Suite 7.6.04 Service Pack 2 Step-by-Step Upgrade Guide
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.
14
Servers used in the staged upgrade process
Servers used in the staged upgrade process

The 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
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.
BM
16
Chapter
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 Overview
If 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.
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, youll 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 Prerequisites
Set 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.
18
Accelerated Staging Server Setup
Accelerated Staging Server Setup

You 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.
19
Duplicated Staging Server Setup
Duplicated Staging Server Setup

Use 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
Product 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
AR System and ITSM Product versions for your environment

Version Patch Level
Table 2
Product
Non-ITSM Product versions for your environment

Version Patch Level
BMC Service Impact Manager Integration for BMC Remedy Service Desk BMC ProactiveNet Performance Management
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).
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

Follow the procedures below to install each product/application that you listed in Table 1 and Table 2 (if applicable) above.
20
Install the required software
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.
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.
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.
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.
21
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.
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

Time stamp
Product database backup
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.
22
4 Change the BMC Remedy AR System server name to match the new host. 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
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.
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.
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.
23
24
Chapter
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.
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.
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.
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.
26

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. This figure shows the components that are upgraded in stage 6.
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.
27
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.
NOTE
A custom field on a deleted form is not preserved, because there is no form to contain the field.
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:
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.
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.
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 havent 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:
1. Open a new server window for StagingServer. 2. In the navigation pane, click StagingServer to display all the objects on this server in the object list. 3. Sort the object list on the Customization Type column and select all objects with the value Overlaid in this column. 4. Right-click and select Differences > UpgradeComparisonServer. BMC Remedy Migrator generates a difference report. See the BMC Remedy Migrator Guide, Difference reports, page 125. The difference report provides a list of objects that have changed.
29
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:
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.
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. 4. Right-click and select Differences > UpgradeComparisonServer.
5. In the Source-Destination Mapping window, click Map Overlay To Base.
30
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.
31
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.
32
Chapter
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
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.
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.
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. This figure shows the components that are upgraded in stage 1.
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.
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.
3 Restore any customizations to the system forms that may have been removed by
the server upgrade process.
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.
35
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
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 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-diffreport_[date]_[timestamp].html and are located in the [utilityInstallDir]\Best_Practice_Conversion_Utility\output folder.
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:
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.
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 nonpermitted 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
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.
37
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 B C
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. 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. 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.
38
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 usercreated objects to custom objects.

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 nonpermitted 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.
39
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.
40
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:
NOTE
Before running this command, confirm that the AR System version installed on your reference server is 7.6.04 SP2.
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.
41

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.
TIP
Overlays that are identical to their overlaid objects might exist if you converted any prefixed or suffixed objects in stage 2.
This figure shows the removal of an unneeded overlay, item 7. Note that removal of the overlay exposes the origin object.
42
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.
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.
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.
43
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. This figure shows the components that are upgraded in stage 6.
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.
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.
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.
44
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.
NOTE
A custom field on a deleted form is not preserved, because there is no form to contain the field.
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. 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.
45
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 havent 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: 1. Open a new server window for StagingServer. 2. In the navigation pane, click StagingServer to display all the objects on this server in the object list. 3. Sort the object list on the Customization Type column and select all objects with the value Overlaid in this column. 4. Right-click and select Differences > UpgradeComparisonServer. BMC Remedy Migrator generates a difference report. See the BMC Remedy Migrator Guide, Difference reports, page 125. 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:
46
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.
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. 4. Right-click and select Differences > UpgradeComparisonServer.
5. In the Source-Destination Mapping window, click Map Overlay To Base.
47
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.
48

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.
49
50
Chapter
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
NOTE
Names that include underscore + zero (_0) are reserved by BMC.
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.
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 forms

This 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.
52
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:
53
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 views 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 fields

This 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.
54
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 fields 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 fields 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:
Fixing non-permitted modifications 55
Changing the Column field properties for Parent field ID, Data field ID and Data Source
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 fields 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. 3 Copy the corresponding field from ReferenceServer to StagingServer. 4 Save the form.
56
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:
57
58
Chapter
Comparing overlays to overlaid objects on the same server

6
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 options

Before 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:
FormsName, Owner, and Property List
59
Comparing staging server objects
FieldsForm Name, Owner, and Property List ViewsForm Name, Owner, and Property List Active Links, Filters, Escalations, Containers (applications, web services, packing lists, active link guides, filter guides), Menus, and ImagesOwner 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.
61
62
Chapter
Creating overlays with the Best Practice Conversion Utility

7
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 overview
To 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.
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
Exceptions Filters that BMC Remedy Approval Server workflow creates at runtime, whose names begin with AP:Notify-0 None None None None 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 BMC Service Level Management Application forms that use BMC Atrium CMDB forms as self-join forms (MemberA and MemberB are the same) 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
BMC products AR System components BMC Remedy Approval Server BMC Remedy Assignment Engine BMC Remedy Email Engine AREA LDAP plug-ins ARDBC LDAP plug-ins BMC Atrium CMDB BMC Atrium CMDB
64
Usage overview
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.
The Best Practice Conversion Utility operates in the following modes:
ReportDiffGenerates 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. OverlayBased 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. WARNING
Do not install any AR System components or applications other than the AR System server. If you do, your customizations might be overwritten.
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.
65
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.

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
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
66
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. Table 5 Files and providers to add to BPCU JRE on encrypted servers
On Oracle Solaris (UNIX and Windows) jsafeJCEFIPS.jar

Add to this directory or file

jre\lib\ext\ jre\lib\security\
On AIX and DB2 (UNIX and Windows)

jsafeJCEFIPS.jar bcprov-jdk15-133.jar US_export_policy.jar local_policy.jar
US_export_policy.jar local_policy.jar
These files should be from Oracle.

jre\lib\security\j security.provider.n+1=com.rsa. ava.security jsafe.provider.JsafeJCE n can be the last number in the section.
These files should be from IBM. 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 Developers Kit (JDK) and JRE used by the client for BPCU.
For more information about BMC Remedy Encryption Security products, see the BMC Remedy Encryption Security Guide.

Run 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\
67
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
Argument -x -u -p -a -t -r -f -c
Command-line options for ReportDiff mode

Description Name of the server on which to perform the operation. User name. User password. (optional) User authentication string. (optional) TCP port of the server on which to perform the operation. (optional) RPC port of the server on which to perform the operation. Absolute path to the overlay hash file (include full path and file name). (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. (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. (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.html If you do not provide a path, the utility places the report file in the installDir\Best_Practice_Conversion_Utility\output\ folder. (optional) Format of the difference report. Values are:

-e
-o
-T
0 HTML (Default) 1CSV 2XLSX
-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:

0Exclude from extension section (Default). 1Include in extension section.
-m -k
Utility mode. Values are D or d or diff. (optional) Indicates whether to display or hide the list of objects that will be skipped in Overlay mode.

0Hide this list in the difference report (Default) . 1Display this list in the difference report.
68
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
Argument -x -u
Command-line options for Overlay mode (part 1 of 2)

Description Name of the server on which to perform the operation. User name.
69
Table 7
Argument -p -a -t -r -f -c
Command-line options for Overlay mode (part 2 of 2)

Description User password. (optional) User authentication string. (optional) TCP port of the server on which to perform the operation. (optional) RPC port of the server on which to perform the operation. Absolute path to the overlay hash file provided by BMC (include full path and file name). (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. (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. (optional) Name of the difference report. Do not include a file extension. (optional) Format of the difference report. Values are 0HTML (Default) 1CSV 2XLSX Utility mode. Values are o or overlay. (optional) Indicates whether to display or hide the list of objects that are skipped during conversion. 0Hide this list in the difference report (Default) . 1Display this list in the difference report. 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. 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. (optional) Flag that specifies whether to include overlay and custom objects in the addition section of the difference report. Values are: 0Exclude from addition section (Default) 1Include in addition section
-e
-o -T
-m -k
-P
-S
-i
70
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)
XLSX report format Dashboard worksheet HTML report format Dashboard tab
Information 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 Difference Report worksheet, rows with the value Extension in the Customization Type column Extensions tab
Whether an object on the server is new
71
Table 8
Information in a difference report generated by BPCU (part 2 of 2)

XLSX report format Difference Report worksheet, rows with the value Customization in the Customization Type column HTML report format Customizations tab
Information Whether an object on the server has been modified
Whether modified objects in the server contain permitted or Difference Report Customizations tab, all worksheet, rows with panels non-permitted modifications: the value Customization in If an object contains non-permitted modifications, it is the Customization flagged as an object that cannot be converted into an Permitted overlay. All such objects must be fixed before running Type column modifications: BPCU in Overlay mode. Convertible to If an object contains permitted modifications, it is Permitted Overlay = true flagged as an object that can be converted into an modifications: overlay. Convertible to Nonpermitted Overlay = true modifications: For information about permitted and non-permitted Convertible to modifications, see the Form and Application Objects Guide, Nonpermitted Overlay = Permitted and non-permitted modifications on overlays, modifications: false page 129. Convertible to Overlay = Note: When you run BPCU in ReportDiff mode with the -k false 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.

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 Execution Information worksheet tab
NOTE
BPCU does not include information in a difference report about objects that are unchanged.
72
Figure 1
BPCU HTML reportDashboard tab
Figure 2
BPCU HTML reportExtensions tab
Figure 3
Convertible to Overlay column in Customizations tab indicates whether the customization is permitted in overlays
73
BPCU log information
Figure 4
BPCU HTML reportExecution 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 runs 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.
74
Chapter
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.xmlLists all modified objects on the server, except specific views and fields that were modified. migrator-npmod-instruction_date_timestamp.xmlOnly 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: 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..
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.
76
Chapter
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 overview

Delta 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
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
Product BMC Atrium Core (all versions)
Tasks that should not be performed after backup.

Restrictions 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
78
Product
Restrictions
BMC Remedy ITSM Suite Do not create or update any of the following contracts: (when upgrading from 7.0.3 to 7.5.x or 7.6.x versions) 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.
79
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.
80
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.
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.
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.
81
Performing the Delta Data Migration
Performing the Delta Data Migration

This 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.
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" 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 folderContains 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 folderContains 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
82
To resolve issues before Delta Data Migration
NOTE
Do not modify the contents of any folders, unless directed to do so by BMC.

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.
83
For example, to comment out the BPPM code lines, insert  tags as follows:
 <!-<application name="BMC_PN: Service Management Data" dir=".\Packages\BPPM" file="BPPM_Package.xml" enabled="true" custom="false"> <guid>OS-129D647E3DD74A26AAACFD3BA1358C94</guid> <package src-version="8.5.00" src-patch=""/> </application> -->
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
NOTE
This issue applies if you have installed version 7.1 of Integration for BMC Remedy Service Desk on your production server.
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.
84
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.t xt .
85
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 twiceonce 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.
86
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.
87
The Delta Migrations window contains the following:
Fetch Data/Objects Created/Modified After Date fieldThe 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) buttonThis 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 buttonThis 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 boxThis check box is checked by default and should remain checked even if you are rerunning the migration after fixing any data issues.
88
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.
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.
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.
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.
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
89
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.
90
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:
Error Migrations Migrations Migrations Migrations Description An Error Occurred with Data 'AST:AssetAdvancedSearchCriteria [4]-[303]-[Form does not exist on server AST:AssetAdvancedSearchCriteria An Error Occurred with Data 'AST:CILifeCycleStatus [4]-[303]-[Form does not exist on server 'AST:CILifeCycleStatus'
Keyword ERROR ERROR ERROR ERROR
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:
Error Migrations Migrations Description An Error Occurred with Data 'TMS:RelationshipsInterface_Create' [4]-[303]-[Form does not exist on server 'TMS:RelationshipsInterface_Create'
Keyword ERROR ERROR
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:
Error Migrations Migrations Description An Error Occurred with Data 'CFG:HTMLCatalog' [4]-[303]-[Form does not exist on server 'CFG:HTMLCatalog'
Keyword ERROR ERROR
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.
91
<data destination-form="CTR:ContractBase" sourceform="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:SYSApproval 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:
Keyword ERROR ERROR Error Migrations Migrations Description An Error Occurred with Data 'APR:Approver Lookup' [4]-[986]-[Currency fields can not be used for grouping.]
The following errors might appear for the APR:SYS-Approval Definition form:
Keyword ERROR ERROR Error Migrations Migrations Description An Error Occurred with Data 'APR:SYS-Approval Definition' [4]-[985]-[No active Currency Code found on the Currency Code 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 Migrations Description An Error Occurred with Data 'WOI:Associations' [4]-[303]-[Form does not exist on server WOI:Associations]
Keyword ERROR ERROR
92
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:
Keyword ERROR ERROR ERROR Error Migrations Migrations Migrations Description An Error Occurred with Data 'SRD:AuditDisplay' for this form does not match that in owning application SRD:AuditDisplay] [4]-[9858]-[The application is not licensed Remedy Service Request and Catalog System]
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.
93
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">
94
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 enabled="true"/> <instruction name="CustomForms"/> </instructions> type="all" command="migrate"
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.
95
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\migratorUti lities.
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
NOTE
In this example, the Examplefilter.dat file contains the list of forms that should be excluded from migration.
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.
96
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.
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.
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 packageFileName -pk
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 Custom_Forms_Package.xml -pk
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.
97
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).
98
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:
99
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. 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.
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.
100
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.
101
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. 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.
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.
102
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.
103
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.
104
Appendix
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 objects ID. For all other objects, the key is the objects 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 information

If 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

Appendix A Overlay hash files 105
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.0.01 patch 004 through 2.0.01 patch 009 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 patch 007 through 7.0.03 patch 010 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:
106
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 information

The 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
Appendix A Overlay hash files 107
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 fileOverlayHashFile.zip
To obtain the overlay hash file: 1 Download the latest version of the OverlayHashFile.zip file from the BMC
Developer Network Community website.
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.
2 Uncompress the .zip file and extract the OverlayHashFile.xml file to your
development server.
108
Appendix
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
110
Appendix
System objects that might be overwritten during upgrade

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.
Table C-1: System objects that may be overwritten during an upgrade

Alert Events Alert List Application Pending Application Statistics Application Statistics Configuration AR Sample Application: Console AR System Actor View AR System Administration: Add Or Remove Licenses AR System Administration: Console AR System Administration: Display Form To Collect User Decisions AR System Administration: License Review AR System Administration: Manage User Licenses AR System Administration: Prompt For Open Attachment AR System Administration: Server Information AR System Administration: Server Information:Save Attachment AR System Administration: Support Form AR System Administrator Preference AR System Alert Delivery Registration
AR System Multi-Form Search AR System Object Relationships AR System Orchestrator Configuration AR System Report Console AR System Report Designer AR System Report Preview AR System Resource Definitions AR System Searches Preference AR System Skins AR System Skins Properties AR System Skins: Color Picker Data Visualization Definition Data Visualization Module Data Visualization System Files Distributed Logical Mapping Distributed Mapping Distributed Pending Distributed Pending Errors
Appendix C System objects that might be overwritten during upgrade
111

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

AR System Web Services Registry Query AR System: Generate License Usage Report ARC:ConfirmDialog AREA LDAP Configuration Business Segment-Entity Association Business Segment-Entity Association_Join Business Time Holidays Business Time Segment Business Time Shared Entity Business Time Shared Entity-Entity Association_Join_Join Business Time Workdays CHP:ConfirmDialog Configuration ARDBC
Data Visualization Module Data Visualization System Files Distributed Logical Mapping Distributed Mapping Distributed Pending Distributed Pending Errors Distributed Pool FB:Alarm Events FB:Alarm Monitor FB:Datasource FB:DataSourceVariables FB:Flashboards
Appendix C System objects that might be overwritten during upgrade
113
114
*218771* *218771* *218771*

*218771*

7.6.04 SP2 - Upgrade Tips PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

7.6.04 SP2 - Upgrade Tips PDF

Transféré par

Droits d'auteur :

Formats disponibles

BMC Remedy IT Service Management Suite 7.6.

04 Service Pack 2 Upgrade Procedures and Guidelines

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

Overlay hash files

Supported upgrade paths

The role of overlays in an upgrade

The role of overlays in an upgrade

Upgrade paths and stages

Upgrade paths and stages

Table1: Upgrade stages Overlays already Without present overlays X X X X X X X X X X

Upgrade paths and stages

Stage 1 - Upgrade AR System server

Upgrade paths and stages

Stage 3 - Acquire origin objects (optional)

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

Stage 5 - Minimize overlays (optional)

Upgrade paths and stages

Stage 6 - Upgrade applications and adjust customizations

Stage 7 - Test and Promote staging server to production

Servers used in the staged upgrade process

Servers used in the staged upgrade process

Required upgrade tools

Required upgrade tools

The following tool is required for all upgrades:

Staging server setup

Staging server setup

Accelerated Staging Server Setup

Accelerated Staging Server Setup

Staging server setup

Duplicated Staging Server Setup

Duplicated Staging Server Setup

AR System and ITSM Product versions for your environment

Non-ITSM Product versions for your environment

Install the required software

Install the required software

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

Staging server setup

Duplicating the Production Server Database

10 If applicable, install BMC ProactiveNet Performance Management and the

11 Remove the BMC_AR_LOADAPP_SKIP=TRUE and

Duplicating the Production Server Database

Back up the production server database

Production database backup information

Product database backup

Restore production database backup on the staging server

Duplicating the Production Server Database

To run the CMDB Check

Staging server setup

Duplicating the Production Server Database

Upgrade with overlays present

Upgrade with overlays present

Stage 1 - Upgrade AR System server with overlays present

Stage 1 - Upgrade AR System server with overlays present

Stage 6 - Upgrade applications and adjust customizations

Stage 6 - Upgrade applications and adjust customizations

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

Upgrade with overlays present

Stage 6 - Upgrade applications and adjust customizations