Step1: Plan the CA SDM Upgrades

This article contains the following topics:
casm1401
This article contains the following topics:
General Considerations
  • CA SDM supports upgrade from r11.2, r12.0, r12.1, r12.5, r12.6, r12.7, and r12.9 for all supported platforms. For Windows, you can upgrade directly from r11.2, r12.0, r12.1, r12.5, r12.6, r12.7, and r12.9.
  • If you installed CA SDM on Linux or UNIX, the upgrade from versions prior to r12.5 requires multiple steps. If your installation is running on an older version of the product, such as r11.2, r12.0 and r12.1 on Linux/UNIX, you must run the automated upgrade script for CA SDM r12.5 and move CA SDM to a supported platform and database before running the automated upgrade script for the new release. If you have modifications, you only have to apply them once - after running the final automated upgrade script to the new release.
  • If you have an earlier version of the product, such as CA Service Desk Manager r6.0 or r11.1, you
    must
    upgrade to CA SDM r11.2 before upgrading.
  • You manually added a variable in the NX.env file or updated a variable value and want to retain these variables after the migration. Ensure that you add these variables to the NX.env template file before the configuration and migration.
  • CA SDM only supports ITIL. If you are upgrading from a non-ITIL system, the installation updates you to an ITIL environment. 
  • If you have a combined CA SDM r11.2 and CA CMDB r11.1 installation, you cannot upgrade directly. You
    must
    first upgrade CA CMDB to r11.2, and then run the upgrade. This process upgrades CA SDM r11.2 to r12.5, and also upgrades CA CMDB r11.2 to r12.5. CA CMDB r12.0 and r12.1 can also be upgraded directly.
    For more information about upgrading from an earlier version, see the
    CA SDM Implementation Guide r11.2.
    For upgrade patches and assistance, contact Technical Support at http://ca.com/support.
  • If you are planning to migrate from an earlier version of CA SDM to the current version, before migrating validate that the servlet path URL(in each Repository Server) is in the correct format. To validate, complete the following steps:
    1. Login to CA SDM.
    2. Navigate to
      Administration
      ,
      Attachment Library
      ,
      Repository
      .
    3. Edit each repository servlet path URL. Remove the Fully Qualified Domain Name (FQDN) from the servlet path and replace it with the hostname in the servlet URL.
      For example, change (http://myhostname.ca.com:8080/CAisd/UploadServlet) to (http://myhostname:8080/CAisd/UploadServlet)
      Ensure that the repository server functionality is intact and working.
  • UTF-8 locale must be installed on Linux/UNIX platforms.
  • On Linux/UNIX, CA SDM no longer uses the smtp_mail script to process outgoing mail notifications. If you are an existing customer using smtp_mail, and you upgrade to the current release, your administrator must configure the appropriate mail options using the Default Mailbox Detail page to enable the mail notification feature of CA SDM.
    Migration from an advanced availability environment is not possible using rolling maintenance. You must shutdown the CA SDM services in all the application and standby servers before starting the migration activity. You need to first migrate the background server and then verify whether the background server processes are running. Migrate the other servers only after ensuring that the background server processes are running.
  • Fresh CA SDM Release 14.1 installation does not install the copy_inactive web option in Options Manager. So the links to inactive objects are not copied. If you are upgrading from CA SDM r12.5 or r12.6, links to inactive objects are copied because migration installs the option.
  • If a previous version uses
    domsrvr:01
    , rename the server ID before starting the upgrade. Execute the
    pdm_edit.pl
     command and update the domsrvr ID from 01 to another ID value.
    The CA Service Desk Manager 14.1 enhances the
    pdm_edit
    command to provide an easier interface to configure the servers. As part of this enhancement, the
    domsrvr:01
    name for object manager is reserved and cannot be used by the custom configuration.
Database Considerations
  • Before you migrate from CA SDM Release 12.7 SP2, ensure that you run the following command:
    update mdb_schema_information set FileTimestamp='2012-04-23T09:19:09+0000'
      where FileName like 'doc_rep.xml'
  • Back up your existing database using your typical database backup procedures.
  • (Applicable for all non-windows machines) If the previous releases of CA SDM is configured with oracle 10gr2 database, install Oracle 11gr2 client before you upgrade.
    Before upgrading, change the Oracle home path to oracle11g r2 client path in the $NXROOT/NX.env file.
  • Archive the installation directory ($NX_ROOT) using your typical archive procedures. This action lowers the amount of data movement and saves disk space.
  • Run the appropriate script from a command prompt to identify any duplicate records on your database:
    Run this script on the secondary servers. If you want to run this script using SQL Query Analyzer, edit the
    SQLCheckr12UniqueIndexes.sql
    script and remove the EXIT argument before you run the command.
    • (Oracle) Run OracleCheckr12UniqueIndexes.sql, located in the \Migrate directory on the installation media.
    • (SQL Server)
      The database is named as "use mdb" by default.
       
      Before you run the script, update the database name manually to
      use <other_database_name>
      using the
      SQLCheckr12UniqueIndexes.sql
      file.
      1. Open a Command Prompt window and run
        SQLCheckr12UniqueIndexes.sql 
        as follows:
        cd $NX_ROOT\samples\views\SQLServer
      2. Enter the command:
Sqlcmd - E - e < SQLCheckr12UniqueIndexes.sql
After you upgrade, you can find these files at
$NX_ROOT/samples/views/SQLServer
or
$NX_ROOT/samples/views/Oracle
on the server.
These scripts identify your duplicate records. Delete identified duplicate records before you proceed with the migration.
  • For Windows, you can upgrade directly from r11.2, r12.0, r12.1, r12.5, r12.6, r12.7, and r12.9.
  • If you installed CA SDM on UNIX or Linux, you can upgrade from r12.5, r12.6, r12.7, and r12,9.
  • If your installation contains an earlier version of the product, such as CA SDM r11.2, r12.0, or r12.1 on a non-supported UNIX/Linux operating system and database, you must upgrade to CA SDM r12.5. Then, move CA SDM to a supported operating environment and database before you upgrade.
  • Upgrade your CA SDM r11.2 system to a supported database (SQL Server and Oracle). 
     For more information about supported database, see the
     
    Supportability Matrix.
  • Upgrade from CA Service Desk Manager r11.0 to CA SDM r11.2 before migrating your data to a supported database.
  • Special Windows characters, such as a long hyphen, in CA SDM or Knowledge Management on a non-Windows system, are not properly stored in the database.
  • Ingres
    -- If you are using an Ingres database, convert your data to Oracle or SQL Server before upgrading.
    For information about the conversion process, see your database documentation.
  • Oracle
    -- Oracle does not support case insensitive indexes for Configuration Item registration. Before you start the migration on Oracle, verify SQLPlus and Oracle DB are able to communicate using hostname. If communication fails, verify that Oracle is configured with loopback adaptor.
     When you migrate in a double-byte character environment with an Oracle database, increase the maximum open cursor limit to at least 500. For more information, view Oracle documents about ORA-01000 (maximum open cursor exceeded).
  • SQL Server
    -- For an SQL Server upgrade to the current release of CA SDM, the default database for the configured Database Userid must be CA MDB. If the default database is not CA MDB, the migration console fails and displays the following message:
    "The acctyp_v2 table does not exist on the MDB"
  • Tomcat
    -- (for CA Service Desk Manager r11.0, r11.1 or CA SDM r11.2) If you configured Tomcat for external authentication, manually reconfigure Tomcat for external authentication after upgrading to the current product release.
  • Table Updates
    -- Consider the following table updates that occur during migration:
    • Status Tables
      -- These tables are also updated with the appropriate status records when the same code values do not exist in your database. For example,
      Cr_Status
      is updated with the code
      AEUR
      (Awaiting End User Response).
    • Functional Areas
      -- For each role, migration automatically adds a row for each
      usp_functional_access
      record. Migration sets the access level to the same level for each CA SDM r12.0 and r12.1 functional area that the
      usp_role
      table includes. New functional areas are mapped using a reference field.
  • Foreign Keys
    -- Consider the following information:
    • Foreign keys (SRELs) that reference tables, in which the primary key is a UUID, change from integer type to UUID type (or BYTE 16).
    • If you dropped foreign key constraints in your previous CA SDM system to mass load data, recreate the foreign key constraints before you run the upgrade. The scripts that drop the constraints are found in the following locations:
      • Oracle
        $NX_ROOT/samples/views/Oracle/OracleDropConstraints.sql
      • SQL Server
        $NX_ROOT/samples/views/SQLServer/SQLDropConstraints.sql
      Reapply the dropped constraints by running the appropriate script
      OracleAddConstraints.sql
      or
      SQLServer/SQLAddConstraints.sql
      . These scripts are found in the same directory as the drop constraints and contain instructions within the files mentioned.
  • MDB
    -- The MDB provides a consistent database schema for various IT management data. During the development of the MDB, data elements from your previous CA SDM environment were incorporated into this schema. The size of the data elements can increase and, consequently, increase the overall database size.
When standard data elements extend beyond the column width defined for the MDB, the update process can truncate data in these elements. Messages alert you to any truncation that occurs during the upgrade.
  • Distributed Setup
    -- We recommend you upgrade your servers in the following order, depending on your CA SDM configuration:
    1. Conventional
      • Primary server
      • (Optional) One or more secondary servers
    2. Advanced Availability
      • Background server
      • One or more standby servers
      • One or more application servers
  • Remote Database
    -- If you are using a SQL Server MDB database, sqlcmd must be on the client computer before connecting to the remote MDB.
Knowledge Management Considerations
For customers upgrading from a previous release of CA SDM that used the FAST ESP search engine, you
must
change to the EBR search engine. The FAST ESP license expires in May 2013. To change to the EBR search engine, click Options Manager, Search Engine and edit ebr_version to specify KT Search Engine.
LREL Migration Considerations
A
List Relationship
(LREL) represents an association between two objects. An LREL has a left-hand side (lhs) and right-hand side (rhs) relationship. Each side of the relationship is an attribute of the majic object that contains the data relationship.
In previous releases of the product, .maj LREL statements and objects described many-to-many DBMS data relationships. Many-to-many relationships no longer use the LREL majic statement. Instead, individual tables store both sides of the relationship. Objects access the relationship with a standard BREL statement. For example, you can see the relationship between change orders and CIs by reviewing the new usp_lrel_asset_chgnr table and in the corresponding lrel_asset_chgnr object.
The LREL changes eliminate the need to store attribute names in the database. The two sides of the relationship are foreign key single relationships (SREL) that are easy to join and index. If necessary, the relationship can contain additional relational attributes.
During the upgrade, the following activities occur as LREL table data migrates to current release of CA SDM:
  • The system automatically migrates tables and objects with LREL relationships.
  • The system names new tables using the
    usp_lrel_lhsName_rhsName
    format.
    For example, the
    usp_lrel_asset_chgnr
    table has a left-hand relationship to assets and a right-hand relationship to change orders.
  • The system names the corresponding objects using the
    lrel_lhsName_rhsName
    .
    For example, the
    lrel_asset_chgnr
    object corresponds to the
    usp_lrel_asset_chgnr
    table.
  • Because of a database limitation, some names are abbreviated.
  • Your data is migrated from the old tables and all CA SDM code is modified to use the tables of the updated release.
  • The system no longer uses the old LREL database tables, such as
    bmlrel
    . However, for reference purposes, the old tables retain the data.
  • A backward relation (BREL) attribute to the new object replaces the original LREL attribute in each related majic object definition.
  • If you are using a supported API, such as the
    CreateLrelRelationship()
    web service method, the code works as expected.
  • If you added any custom LREL style relationships, CA SDM migrates them to the tables of the updated release.
  • Any site-defined code or reports that directly access the old LREL tables operate on old data because the system no longer uses those tables. We recommend that you update the code to use the tables of the updated release for the code and reports to run properly.
If your code directly accesses legacy LREL objects or tables, the code fails after migration. We recommend that you upgrade the code before migration. For example, if your code uses majic statements to establish LREL relationships, use the
createLrelRelationships()
method instead of directly populating a table.
We recommend that you verify site-defined code or reports that directly access the database or address the legacy LREL majic objects such as the lrel1 object to verify that they operate properly. You can update your code to use a supported interface, such as Web Services. You also update the necessary table names. For reports, you can also update the queries with the new DBMS table references.
Status Transition Considerations
Consider the following information if you plan to use Status Transitions after upgrading from CA SDM r11.2, r12.1, and r12.1:
  • Status transitions are inactive when you upgrade.
    All modified status code descriptions that appear on ticket forms are retained during the upgrade process.
  • The
    Status_Policy_Violations
    option is installed and set to Warn by default after you upgrade. This setting allows undefined transitions to occur, but logs a warning.
  • If you set the option to Allow, undefined transactions are not logged.
How to Upgrade CA EEM
The current version of CA SDM uses EEM 12.51 SDK which is not compatible with the EEM 8.4 server. To support the existing customers who are using EEM 8.4 server, EEM 8.4 SDK patch has to be applied on the CA SDM server. Find the patch details from the CA Support Online.
You install CA EEM separately.
When migrating, upgrade to at least CA EEM r8.4 SP4.
You can upgrade from CA EEM r8.1 directly to r8.4 SP4.
To upgrade CA EEM, perform the following tasks:
  1. Verify that you upgraded to the current version of CA SDM
  2. Insert the installation media into your drive.
  3. Install CA EEM.
After you install CA EEM, manually set the appropriate options in the Options Manager. Review the upgraded options carefully. The default Process Manager URL is no longer pmService.
The 
cawf_pm_url
 option has changed to a default of: 
http://<wf_hostname>:<wf_tomcat_port>/pm/service/pmService2
, so you 
must
 manually change "pmService" to "pmService2" for CAWF communication to remain functional.
After you upgrade CA EEM, set the
eiam_hostname
,
use_eiam_artifact
, and
use_eiam_authentication
options in Options Manager, Security if you previously used eIAM CA SDM user authentication.
CA Process Automation Integration
To ensure that CA SDM and CA Process Automation integration works properly, add the ServiceDesk user in CA EEM (if not already added) during the upgrade.