Use the Swing Box Method to Upgrade to CA SDM 17.1
The SWING Box method is performed by using a separate server, referred to as a SWING system to replicate your current production system and then, upgrade to CA SDM 17.1.
SWING Boxmethod is performed by using a separate server, referred to as a
SWINGsystem to replicate your current production system and then, upgrade to CA SDM 17.1. Move the upgraded CA SDM data and customization over to a clean server (never before upgraded) and install on a new hardware. This method leaves your current production system fully in-tact in case of a Disaster Recovery issue or failed migration. An additional advantage is that with a VMware environment as the
SWINGsystem you can use the snapshot functionality to test the migration process multiple times, and gather data on timings and steps.
This article contains the following topics:
Prerequisites for using the Swing Box Method
Ensure that you consider the following prerequisites before using the Swing Box upgrade method. This activity saves lot of time while upgradi
- No form, or schema (tables and columns) customization, or changes must be made to any system once upgrade testing is started (CA SDM 17.1 production, development, test, SWING, and so on).
- If you plan to add or modify additional tables or columns, it must be done on CA SDM 17.1 . Replicate the same in your production system prior to testing upgrade. This can be done after your production upgrade is complete and when you are planning for another outage using CA Service Desk 17.1 on a new production system.
- You have already done a test upgrade of a replica of your production system. Completed re-customizing any of your custom forms from CA SDM 17.1 versions that are incompatible with CA SDM 17.1. You have a final customized and completesite\modsdirectory from a CA SDM 17.1 environment that was properly tested.
- You have replicated the most recent migrated CA SDM 17.1 test environment install into your new production hardware including your customized forms built for CA SDM 17.1.
Step 1: Collect Files/Data from your Current Production System
Perform the following steps:
- Do a SQL Backup of the MDB - save as.bakfile (usually a normal SQL backup).
- Make a copy of the "C:\Program Files\CA\Service Desk\site\mods\" directory and zip or compress it, if possible.
- 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.
- Copy the above files to the Swing environment to a stand-by directory on that machine and do not not place them in this location for now.
Step 2: Prepare the Swing Environment and Replicate Production to Swing
If your Swing environment has both Database and Application running on the same system, you may skip to step
#3in this article. For reference, in this section we will refer to the database server as "
Swing-DB" and the application server as "
- OnSwing DB- (assuming Microsoft SQL Server is already installed), run the MDB installer wizard from CA SDM 12.9 or later installation media.
- OnSwing-APP- install the SQL client and native client (workstation tools also)
- Install Service Desk 17.1 on SWING-APP and run configuration so that you have a vanilla (without customizations) Service Desk Manager 17.1 installation running.
- As the database administrator, execute the Microsoft SQL Restore and restore the MDB from your current production that you backed up, to the SWING-DB server. Set option toOVERWRITE entire databasewhen restoring. For more information, see How to Move the CA MDB Data from the Source to the Target Systems.
- After Microsoft SQL Server restore is complete, execute the stored procedure in SQL to fix the orphaned users which are created when restoring a database from one Microsoft SQL Server instance to another.For Example:sp_change_users_login 'AUTO_FIX','mdbadmin'
- Copy thesite\modsdirectory that you backed up from current production and put in place onSWING-APPsystem.
- Copy thesite\attachmentsdirectory (or whichever attachments directory) you backed up from current production and place it on SWING-APP system.
- Execute thepdm_configure command:
- Do not selectTO LOAD DEFAULT DATA.
- In the configuration wizard, clickNextat the database section.A message displays, stating that database was previously configured. This message indicates that you have restored the MDB from a different environment.ClickYes.
- Afterpdm_configurecompletes, start Web Screen Painter (also called WSP) and log in.
- NavigatetoTools, Schema Designer.
- Click on any table on the left pane.
- EnterXin the description field for the selected table.
- Navigate toFile,Save.
- Close the Schema Designer window
- In the main Web Screen Painter window, clickFile,Save and Publish.
- Exit Web Screen Painter and close all browser windows.Execute the following commands:pdm_halt -w (this stops all SD Services)pdm_publish (this will merge the schema and load the correct schema files)When you runpdm_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.Afterpdm_publishis executed, all data on custom tables is removed.
- Running pdm_publish drops and recreates thetacustom tables. As a result, the data on the tables is removed.
- Run thepdm_configurecommand once again as shown instep 8and
- After pdm_configure is complete, start the CA SDM services, if not started already.
- Verify and test system functionality to make sure CA SDM 12.9 or later is running with customization seamlessly as a full replica of your production environment.
Step 3: Upgrade to CA SDM 17.1 on the SWING System
Test the migration and become familiar with the processes and issues that you may encounter while migrating your production system. If your SWING system is on a VMware environment, take a snapshot. You can roll back to that snapshot when you take down your production system for maintenance or other purposes. Perform a Microsoft SQL Server backup on the production system. Restore it to the SWING environment and complete the steps mentioned in this section. In case migration fails, you can bring the CA SDM 17.1 production system back again and start the services. You can retest migration on the SWING environment again and schedule it for another time.
Perform the following steps:
- Mount the CA SDM install media or run the setup.exe from the local folder where you have copied the CA SDM installer.If you are extracting an ISO of the install media, it should be stored in a path and folder that has no spaces in the name, for example: SD171Setup. Also, run locally from the same drive volume where you plan to install CA SDM 17.1. Do not 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.
- Launch theCA Service Management17.1 installer.
- Select a language and clickNext.For example, select English and then clickNext.
- SelectCA Service Management.
- Follow the prompts to perform this upgrade.This process may take some time to complete depending upon the size of the CA SDM 12.9 or later database that you are upgrading/migrating.
- Copy theCA Service Management17.1site\modsfolder from previous test or development environment to this SWING system.Note: If you are testing migration at this stage, you may skipstep 6as at this point you will not have any CA SDM 17.1 customizations. However, if this is your production migration day 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 on the CA SDM forms on the SWING environment. If so, you can perform this step as you will already have a copy of these customizations backed up.
- Run thepdm_configure
- Test the migrated, and customized CA SDM 17.1 SWING system for integrity and functionality.If this is your test run on the SWING environment, then e-build your form customizations using the 17.1 forms that are delivered with the product as your previously customized CA SDM 12.9 or later versions are incompatible with CA SDM 17.1 . Once you have completed the rebuilding of your customizations, take a backup of yoursite\modsstep 6in this section).At this point, if this is your test run on the SWING environment, you will need to re-build your form customizations using the CA SDM 17.1 form delivered with the installer as the earlier customized CA SDM 12.9 or later forms will not work. Once you have completed the rebuilding of your customizations, take a backup of yoursite\modsdirectory on the SWING box and store it somewhere outside of this environment for later use (as described instep 8above).
- If all tests are successfully completed, you might now start the process of moving your migrated data, and customizations to the new production hardware.
Step 4: Move Upgraded SWING Box Install to New Production Hardware
Your new production hardware must already be up and running a clean install of CA SDM 17.1 with tested CA SDM 17.1 customizations in place.
Since the new production hardware is already running a clean install of CA SDM 17.1 with your customizations in place (from your finalized CA SDM 17.1 testing environment). Perform a Microsoft SQL Server backup on the SWING system and have your database administrator perform a Microsoft SQL Server Restore onto the SQL database instance that your new production system is using.
Perform the following steps:
- Create a Microsoft SQL Server backup on the SWING system, and let your database administrator perform an SQL Restore onto the SQL instance that your new production system is using.
- For more information, see Step 2: Prepare the Swing Environment and Replicate Production Swing and execute the succeedingsteps 4 to 7in this procedure.
- If you are using the Advance Availability configuration, complete the following steps or skip tostep 4:
- Ensure that you have installed the following components:
- (Oracle) database client is installed and net service name is configured to connect with the new database server.
- (MS SQL) MS SQL database client is installed.
- From the DBCleanupUtility folder of the installer, run the following script:
- (Windows) ResetSDMuspServers.bat
- (UNIX) ResetSDMuspServers.sh
- Follow the steps that are provided in the script (it might need database credentials).This utility deactivates all the servers present inusp_serverstable.
- If you are using the conventional configuration, addNX_SWING_BOX_MIGRATE=Yesvariable to NX.env file and run thepdm_configurecommand.
- Do not selectTO LOAD DEFAULT DATA.
- In the configuration wizard, clickNextat the database section. A message displays, stating that database was previously configured.This message indicates that you restored the MDB from a different environment.
- After the configuration is complete, perform the following tasks:
- Start CA SDM services (if not started).
- Test the system functionality to ensure the new production environment with CA Service Desk 17.1 is running with your data, and customizations and all functionality is in working correctly.
Reconfigure CA EEM
If you are using CA EEM for authentication on the source or originating CA SDM environment, and that original CA EEM server is not accessible by the Swing Box environment, perform the following steps to reconfigure CA EEM options as follows:
1. Edit the
NX.envfile and set
2. Recycle CA Service Desk Manager services.
3. Log into CA Service Desk Manager using the admin account.
4. Go to
Options Manager, and re-configure all CA EEM options to point to the appropriate CA EEM server, along with proper credentials and configurations for that server.
5. Edit the
NX.envfile again to
6. Recycle CA Service Desk Manager Services again.