CA Service Management - 17.1

17.3 17.2 17.1 14.1
English

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. 
casm171
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. 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 
SWING
 system 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
  1. 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). 
  2. 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.
  3. 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 complete
     site\mods
     directory from a CA SDM 17.1 environment that was properly tested. 
  4. 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: 
  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 and zip or compress it, 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 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 
#3
 in this article. 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 Microsoft SQL Server is already installed), run the MDB installer wizard from CA SDM 12.9 or later installation media.
  2. On 
    Swing-APP
     - install the SQL client and native client (workstation tools also)
  3. 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.
  4. 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 to 
    OVERWRITE entire database
     when restoring. For more information, see How to Move the CA MDB Data from the Source to the Target Systems.
  5. 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'
     
  6. Copy the 
    site\mods
     directory that you backed up from current production and put in place on 
    SWING-APP
     system.
  7. Copy the 
    site\attachments
     directory (or whichever attachments directory) you backed up from current production and place it on SWING-APP system.
  8. Execute the 
    pdm_configure command
    :
    1. Do not select 
      TO LOAD DEFAULT DATA
      .
    2. In the configuration wizard, click 
      Next
       at 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.
      Click 
      Yes
      .
  9. After 
    pdm_configure
     completes, start Web Screen Painter (also called WSP) and log in.
  10.  
    Navigate
     to 
    Tools, Schema Designer
    .
  11. Click on any table on the left pane.
  12. Enter 
    X 
    in the description field for the selected table.
  13. Navigate to 
    File
    , 
    Save.
     
  14. Close the Schema Designer window
  15. In the main Web Screen Painter window, click 
    File
    , 
    Save and Publish.
     
  16. Click 
    OK.
     
  17. 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 run 
    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 an expected error message as the restored MDB database already has columns shown in the error message.
    After 
    pdm_publish
     is executed, all data on custom tables is removed.
  18. Running pdm_publish drops and recreates the 
    ta
     custom tables. As a result, the data on the tables is removed. 
     You must load the data from the original MDB to the new one by running 
    pdm_extract/pdm_load
     commands. For more information, see Database Table Replacement.
  19. Run the 
    pdm_configure
     command once again as shown in
     step 8
     and
     
    DO NOT SELECT TO LOAD DEFAULT DATA
  20. After pdm_configure is complete, start the CA SDM services, if not started already. 
  21. 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:  
  1. 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.
  2. Launch the 
    CA Service Management
     17.1 installer.
  3. Select a language and click 
    Next
    .
    For example, select English and then click 
    Next
    .
  4. Select 
    CA Service Management
    .
  5. 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.
  6. Copy the 
    CA Service Management
     17.1 
    site\mods
     folder from previous test or development environment to this SWING system.
     
    Not
    e: If you are testing migration at this stage, you may skip 
    step 6
     as 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.
  7. Run the 
     
    pdm_configure
     
     command to ensure that all customizations are properly implemented.
  8. 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 your 
     
    site\mods
     
     directory on the SWING box and store it somewhere outside of this environment for use later (as described in 
    step 6 
    in 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 your 
    site\mods
     directory on the SWING box and store it somewhere outside of this environment for later use (as described in 
    step 8
     above).
  9. 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:
  1. 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.
  2. For more information, see Step 2: Prepare the Swing Environment and Replicate Production Swing and execute the succeeding 
    steps 4 to 7
     in this procedure.
  3. If you are using the Advance Availability configuration, complete the following steps or skip to 
    step 4
    :
    1. 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.
    2. From the DBCleanupUtility folder of the installer, run the following script:
      • (Windows) ResetSDMuspServers.bat
      • (UNIX) ResetSDMuspServers.sh
    1. Follow the steps that are provided in the script (it might need database credentials).This utility deactivates all the servers present in
       usp_servers
       table.
  4. If you are using the conventional configuration, add 
    NX_SWING_BOX_MIGRATE=Yes
     variable to NX.env file and run the 
    pdm_configure 
    command.
    1. Do not select 
      TO LOAD DEFAULT DATA
      .
    2. In the configuration wizard, click 
      Next
       at the database section. A message displays, stating that database was previously configured.
      This message indicates that you restored the MDB from a different environment.
    3. Click 
      Yes
      .
  5. After the configuration is complete, perform the following tasks:
    1. Start CA SDM services (if not started).
    2. 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.env
 file and set 
USE_EIAM_FOR_AUTH=No.
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.env
 file again to 
USE_EIAM_FOR_AUTH=Yes.
 
6. Recycle CA Service Desk Manager Services again.