Using the Swing-Box method for Upgrading/Migrating to a new version of CA Service Desk Manager

Document ID : KB000021143
Last Modified Date : 14/02/2018
Show Technical Document Details

Introduction:

This document serves to provide the steps to using what is known as the "Swing Box" method for upgrading/migrating CA Service Desk Manager.

Instruction:

INSTRUCTIONS TO MIGRATE SERVICE DESK FROM 11.2/12.x to 12.7 CA SDM - USING THE "SWING BOX" METHOD

Overview of this method:
The "SWING" Box Method is done by using a separate server (herein referred to as a SWING system) to replicate your current production system onto, and then run migration to 12.7 CA SDM, then move the migrated 12.7 CA SDM data and customizations over to a clean (never migrated) and install on new hardware. The advantages of using this method are that it will leave your current prod system fully in-tact in case of a Disaster Recovery issue or failed migration, and at the end of the process, you are running your new 12.7 CA SDM Service Desk install on a clean, never migrated, system - usually on new more powerful hardware, with an updated version of the OS and DBMS. An additional advantage would be added if you have the ability to use a VMware environment as the "SWING" system, as you can use the snapshot functionality to test the migration process multiple times, gathering data on timings and steps, ensuring a higher comfort level for the parties involved in the migration day project.

To use this method most efficiently, there are a few requirements. They are as follows:

  1. NO form, or schema (tables and columns) customizations or changes should be made to any system (11.2/12.x prod or 12.7 CA SDM dev, test, SWING etc.) once migration testing has been started. If you plan to add or modify additional tables or columns, it should be done either on 11.2/12.x and put into production prior to testing migration, OR during another outage planned after your PROD migration is complete and you are running Service Desk 12.7 CA SDM on the NEW PROD system.
  2. You have already done a test migration of a replica of your production system, and have already completed re-customizing any of your custom forms from 11.2/12.x that are incompatible with 12.7 CA SDM, and have a final customized and complete and site\mods directory from a 12.7 CA SDM environment where all proper testing was completed.
  3. You have replicated the most recent migrated 12.7 CA SDM test environment install onto your NEW PROD hardware including your customized forms built for 12.7 CA SDM. This will save you a lot of time on migration day.

PART 1 - GATHER FILES/DATA FROM CURRENT PROD SYSTEM

  1. Do a SQL Backup of the MDB - save as .bak file (usually a normal SQL backup)
  2. Make a copy of the "C:\Program Files\CA\Service Desk\site\mods\" directory - zip it up if possible.
  3. Make a copy of the "C:\Program Files\CA\Service Desk\site\attachments" (or whichever directory your repositories are configured to store your attachments in) and zip it up if possible.
  4. Copy above files to the SWING environment - but don't put them in place yet, simply copy them to a stand-by directory on that machine.

PART 2 - PREPARE THE SWING ENVIRONMENT & REPLICATE PROD SWING

NOTE: If your SWING environment has both the DB and Application running on the same box, then you may start at step #3 in this section.
**For reference, in this section we will refer to the database server as "SWING-DB" and the application server as "SWING-APP"**

  1. On SWING DB - (assuming SQL is already installed), run the MDB installer wizard (from the SD 11.2/12.x install media)
  2. On SWING-APP - install the SQL client and native client (workstation tools also)
  3. Install Service Desk 11.2/12.x on SWING-APP and run configuration so that you have a vanilla 11.2/12.x Service Desk Manager installation running.
  4. Have your DBA run the SQL Restore and restore the MDB from your current PROD that you backed up, onto the SWING-DB server - Set option to "OVERWRITE entire database" when restoring.
  5. After the SQL restore is complete you must run the stored procedure in SQL to fix the orphaned users - which are created when restoring a db from one SQL instance to another.

SHOULD BE SOMETHING LIKE THIS: sp_change_users_login 'AUTO_FIX','ServiceDesk'

  1. Run pdm_configure -DO NOT SELECT TO LOAD DEFAULT DATA **In the configuration wizard when you click "next" at the database section it will pop up a box saying that "this database was previously configured by ... are you sure you want to configure it" you will click "Yes" here - this is only because you restored the MDB from a different environment.
  2. After pdm_configure completes, start Web Screen Painter (also called WSP) and log in
  3. Go to Tools > Schema Designer
  4. Click on any table on the tree on the left
  5. Put an "X" in the description field for that table on the right
  6. Go to File > Save
  7. Close the Schema Designer window
  8. In the main WSP window, click File > "Save and Publish"
  9. Click OK on the dialog boxes
  10. Exit out of WSP and close all WSP windows and browser windows
  11. Run: pdm_halt -w (this stops all SD Services)
  12. Run: pdm_publish (this will merge the schema and load the correct schema files)

    NOTE: When running pdm_publish, the following error message or a similar one will appear on the Command Prompt.

    ERROR 2705 [Microsoft OLE DB Provider for SQL Server] [ SQL Code=2705 SQL Stat=42S21] Column names in each table must be unique. Column name 'zxxx_test' in table 'busmgt' is specified more than once.

    This is expected error message because the restored MDB database already have had the columns shown in the error message.

  13. After pdm_publish is completed, all data on custom tables will be removed.
    When running pdm_publish, it drops ta custom tables and recreate them. As a result, the data on the tables will be removed.
    You need to load the data from the original MDB to the new one by running pdm_extract/pdm_load commands.
    Please refer to TEC1822475 for more information.
  14. Copy the site\mods directory you backed up from current PROD and put in place on SWING-APP system
  15. Copy the site\attachments directory (or whichever attachments directory) you backed up from current PROD and put in place on SWING-APP system
  16. Run another pdm_configure - again DO NOT SELECT TO LOAD DEFAULT DATA
  17. After configuration is complete - start service desk services if not started, perform some testing of system functionality to make sure 11.2/12.x is running with your data, and customizations without issue, as a full replica of your production environment.

NOTE: If you are running your SWING environment on VMware, its best to take a snapshot at this point which you can then use later on your actual migration day. See the note in the next section for details.

PART 3 - UPGRADE & MIGRATE TO SERVICE DESK 12.7 CA SDM ON THE SWING SYSTEM

This section is geared towards the testing process of first testing the migration so that you will be familiar with the process and what issues you may run into while migrating your production system on your actual migration day. If your SWING box is on a VMware environment, then its best to take a snapshot here first if you have not done so already, as you can simply roll back to that snapshot on your actual migration day, then simply take your production system down, do another SQL backup on Production, restore it to the SWING environment, and run the steps in this section again. This allows you to leave your 11.2/12.x production environment in tact just in case something goes wrong with your migration - all you would have to do is bring your 11.2/12.x production system back up and start services. You can then retest migration on the SWING environment again, and schedule it for another time once any bugs are worked out for your specific migration.

IMPORTANT NOTE: If your DB and Application are on separate servers, then you will first need to run the MDB installer for 12.7 CA SDM from the 12.7 CA SDM install media on the SWING DB Server, which will upgrade the MDB on SWING from 11.2/12.x to 12.7 CA SDM's format. Then once that is complete, you can start the next set of steps here to upgrade the application and migrate the data. Note that the MDB installer does NOT migrate the data, but rather only upgrades the MDB to the right version in preparation for a migration.

  1. Mount the 12.7 CA SDM install media from a local folder, or run the setup.exe from the local folder where the install media is being stored.

IMPORTANT NOTE: If you are extracting an ISO of the install media, it should be stored in a path and folder that has no spaces in its name such as "SD127Setup" - and should be run locally from the same drive volume that you plan to install 12.7 CA SDM onto. Never run the installer from a network drive or mounted share as this has been known to cause install and even post install problems to occur.

  1. Click on "Installations"
  2. Click on " Service Desk"
  3. Follow the prompts to perform this upgrade to 11.2/12.x from 12.7 CA SDM
  4. After the install is complete - the Migration Wizard will kick off
  5. Follow the migration wizard prompts and enter any necessary information when prompted
  6. This part may take a long time depending on the size of your 11.2/12.x database.
  7. **(see note below) - copy 12.7 CA SDM site\mods folder from previous test/dev environment to this SWING box and run a pdm_configure to ensure all customizations are properly implemented.

**NOTE: If you are testing migration at this stage, you may skip this step as you would not have any 12.7 CA SDM customizations at this point. However, if this is your production migration day, at this point, it is assumed that you have done a test migration on the SWING environment before doing this production migration, and you have already completed any re-customization or customization work to the forms on the SWING environment. If so, then follow this step as you should already have a copy of those customizations backed up.

  1. Now, fully test this migrated, and customized 12.7 CA SDM SWING system for integrity and functionality.

NOTE: At this point, if this is your test run on the SWING environment, you will need to re-build your form customizations using the 12.7 CA SDM forms delivered with the product as your previously customized 11.2/12.x versions will not work in 12.7 CA SDM. Once you have completed the rebuilding of your customizations, please take a backup of your site\mods directory on the SWING box and store it somewhere outside of this environment for use later (as described in step 8 above).

  1. If all tests are successfully completed, you may now start the process of moving your migrated data, and customizations to the NEW PROD hardware.

PART 4 - MOVE MIGRATED SWING BOX INSTALL TO NEW PRODUCTION HARDWARE

**As noted at the beginning of this document - your NEW PRODUCTION hardware should already be running a clean install of 12.7 CA SDM with your tested 12.7 CA SDM customizations in place.

Since the NEW PROD hardware is already running a clean install of 12.7 CA SDM with your customizations in place (from your finalized 12.7 CA SDM testing environment) - all you will need to actually do here is simply do a SQL Backup on the SWING system, and have your dba do a SQL Restore onto the SQL instance that your NEW PROD system is using, and follow these few steps:

  1. After the SQL restore is complete you must run the stored procedure in SQL to fix the orphaned users - which are created when restoring a db from one SQL instance to another.

**SHOULD BE SOMETHING LIKE THIS: sp_change_users_login 'AUTO_FIX','ServiceDesk'

  1. Run pdm_configure - again DO NOT SELECT TO LOAD DEFAULT DATA **In the configuration wizard when you click "next" at the database section it will pop up a box saying that "this database was previously configured by ... are you sure you want to configure it" you will click "Yes" here - this is only because you restored the MDB from a different environment.
  2. After configuration is complete - start service desk services if not started, perform FULL testing of system functionality to make sure your NEW PRODUCTION Service Desk 12.7 CA SDM system is running with your data, and customizations and all functionality is in working correctly.

Congratulations!!
You may now go live to your user community with your new Service Desk R12.7 CA SDM installation - and get some well-deserved rest!

 

Additional Information:

- TEC1822475: After running pdm_publish, the data on custom tables disappear

- TEC1756396: When running pdm_publish, an error "...Column names in each table must be unique..." appears.