Upgrade > Upgrade the platform components > Upgrade the Service Manager Server

Upgrade the Service Manager Server

Note If you have a horizontally-scaled system, you must upgrade all your server instances.

Upgrade from a version earlier than 9.60

To upgrade the Service Manager Server from a version earlier than 9.60 to version 9.61, you must first install Service Manager 9.60, and then upgrade to Service Manager 9.61. To do this, follow these steps:

  1. Before you install the Service Manager Server, make a backup of your existing Server installation folder.

    Note If you have a horizontally scaled system, be sure to back up the server installation folder for each server instance.

  2. Install the Service Manager 9.60 Server. For detailed steps, see Install the Service Manager Server.

  3. Restore your old Service Manager Server configuration files in the Server's RUN folder, including the sm.ini and sm.sfg files.
  4. Only if you are upgrading from ServiceCenter, perform the following additional configuration:

    1. Stop the Service Manager Server service if necessary.
    2. Open the initialization (sm.ini) file with a text editor.
    3. Review the following list of deleted parameters. Compare this list with the parameters in sm.ini and delete any parameters from this list that exist in your sm.ini file:
      • alterlog: Alert log entries are now placed in the sm.log file.
      • apiserver: Client listener processes now connect through dedicated HTTP and HTTPS ports.
      • clustername: You can set up a failover configuration by starting a second load balancer process on a separate system.
      • cstrace
      • debugdtevents
      • debugdtrecords
      • debugdttrace
      • debugdtworld
      • debuglog
      • debugrpc
      • debugtransport
      • immediateshadow: Use your RDBMS utilities for reporting or data backup.
      • keepalive
      • odbccharacterarray
      • scdebug: Contact customer support if you need to debug customized RAD applications from previous versions.
      • servletcontainer: You no longer need this parameter to start client listener processes.
      • sqldetect: The database dictionary automatically detects changes to RDBMS tables and columns.
      • sqlidentify
      • sqllogintime
      • sqlmodcount: The database dictionary automatically detects changes to RDBMS tables and columns.
      • validateodbcfieldnames
    4. If necessary, make the required changes for each of the following parameters:

      Old name New name Required change
      autopass_dir licensefile The default path to the license file is now in the server’s RUN directory. If you want to retain your previous license file path, you must specify it with the new licensefile parameter.
      cacertpem truststoreFile Move your CA certificate from a PEM file to a Java keystore and provide the path to this keystore with the truststoreFile parameter.
      certpem keystoreFile Move your server certificate from a PREM file to a Java keystore and provide the path to this keystore with the keystoreFile parameter.
      dhpem keystoreFile This parameter is obsolete. You can set DH encryption properties when you create your Java keystore.
      pkpem keystoreFile Move your server private key from a PEM file to a Java keystore and provide the path to this keystore with the keystoreFile parameter.
      pkpempass keystorePass Move your server private key from a PEM file to a Java keystore and provide the password to this keystore with the keystorePass parameter.
      sccluster group Use the new parameter to shut down your virtual group.
      scclusterbindaddress groupbindaddress Use this parameter to specify which IP Service Manager should bind to when your system has multiple IP addresses available from multiple network interfaces.
      scclustermcastaddress groupmcastaddress Use this parameter to define your horizontally scaled system.
      scclustername groupname Use the new parameter to define your server group name.
      scclusterport groupport Use the new parameter to define your server group port.
      scemail emailout Use the new parameter to process outbound e-mail from Service Manager.
      schost host Use the new parameter to shut down or standby your system
      sctimeramount heartbeatinterval Use the new parameter to keep client connections open.
      soapaccepttimeout sessiontimeout Web services client connections now use the client time out limits.
      soapreceivetimeout sessiontimeout Web services client connections now use the client time out limits.
      ssl_trustedClientspem trustedclientsJKS Move your list of trusted clients from a PEM file to a Java keystore and provide the path to this keystore with the trustedclientJKS parameter.
      timeoutlimit sessiontimeout Use the new parameter to set your client’s session time out.
    5. Save and close the sm.ini file.
  5. If you have configured SSL or single sign-on, you must copy the following files from the previous installation folder to the new installation folder (your own keystore file names may differ):

    • <SM_install>\Server\RUN\cacerts
    • <SM_install>\Server\RUN\server.keystore
    • <SM_install>\Server\RUN\trustedclients.keystore
  6. Restart the Service Manager server.
  7. Follow the steps in the Upgrade to Service Manager 9.61 from version 9.60 or later section to upgrade the Server to version 9.61.

Upgrade to Service Manager 9.61 from version 9.60 or later

Upgrade the server by using the server patch installation tool

To upgrade the Service Manager server from version 9.60 to version 9.61, follow these steps:

  1. Stop all Service Manager clients.
  2. Stop the Service Manager Server.
  3. Extract the Server patch (sm9.61.xxxx_Windows_Server.zip or sm9.61.xxxx_Linux-x86.tar) to a directory on the Server host, and then run the PatchSetup.bat file on Windows, or the PatchSetup.sh file on Linux (the file is located in the Service Manager 9.61 Server patch directory).

    Note Running these tools will overwrite the configuration files (such as the LWSSO configuration file and XML files for Jgroups) in the RUN directory in the Service Manager server installation directory. Remember to reapply any changes that you have made to these files after you run the patch installation or uninstallation tool.

  4. When prompted, enter the full path of the current Service Manager server installation directory and the full path of the Service Manager server backup directory.
  5. Wait for the tool to run. When it has run successfully, the message "Finished applying the SM Server patch" is displayed. If the tool cannot run successfully, an error message is displayed and the details are recorded in the PatchSetup.log file.
  6. If you have made any customizations or changes to the original RUN/tomcat folder, restore them in the new RUN/tomcat folder.
  7. Your old schemastub.xml file (in the <SM_Server_Home>\RUN\km\styles\ directory) has been updated to a newer version. Either keep your old file by copying it back or keep the updated version (a full reindex for the knowledgebases is then required).

  8. Run the sm -unlockdatabase command.

    Note This step is required only the first time you upgrade to 9.30p4 or later; it is also required whenever you change the server’s IP address after your upgrade to 9.30p4 or later. The purpose of this step is to prevent stale license information from being kept in the system. In a scaling implementation, you can run this command from any one of your servers.

  9. Restart the Service Manager server.
  10. Restart the Service Manager clients.
  11. Verify the server version by using either of the following methods:

    • From the Windows client, click Help > About Service Manager Server.

    • From the server's RUN folder, run the sm -version command.

Upgrade the sever manually

Instead of running the server patch installation tool, you may still follow the manual steps used to upgrade earlier versions of Service Manager. However, if you perform the upgrade manually, you will not be able to use the server patch uninstallation tool to back out the patch.

Follow these steps to upgrade the server manually:

  1. Stop the Service Manager server.
  2. Backup the Server folder.
  3. Delete the RUN/tomcat directory.
  4. Delete the RUN/lib directory.
  5. (For Windows platforms only) Delete the RUN/jre directory.

    Note This is to avoid conflicts between the old JRE and the new JRE.

  6. Extract the compressed files for your operating system to the main Service Manager directory on the server.
  7. (For UNIX servers only) Set the file permissions for all Service Manager files to "755."
  8. If you have made any customizations or changes to the original RUN/tomcat folder, restore them in the new RUN/tomcat folder.