Installing the master domain manager as a backup master domain manager

A fresh installation for the master domain manager and the backup master domain manager

Before beginning the installation, ensure you have completed the following steps:
  1. Converting default certificates
  2. Installing WebSphere Application Server Liberty
  3. Encrypting passwords (optional)
  4. Upgrading the database for the server components
  5. Creating the IBM Workload Scheduler administrative user

You install a master domain manager at the latest product version level configured as the new backup master domain manager by running the serverinst script. The installation process is able to detect the presence of an existing master domain manager and automatically configures this one as the backup master domain manager. The new backup master domain manager is configured to point to the existing database instance.

The IBM Workload Scheduler administrator installs the master domain manager as the backup. The following information is required:

Table 1. Required information

Required information for performing the installation

Command parameter Information type Provided in..
Database information
--rdbmstype database type Upgrading the database for the server components
--dbhostname database hostname
--dbport database port
--dbname database name
--dbuser database user name
--dbpassword database password
IBM Workload Scheduler information
--wauser IBM Workload Scheduler administrative user name Creating the IBM Workload Scheduler administrative user
--wapassword IBM Workload Scheduler administrative user password
WebSphere Application Server Liberty Base information
--wlpdir WebSphere Application Server Liberty Base installation directory Installing WebSphere Application Server Liberty
IBM Workload Scheduler installation directory
--inst_dir installation directory Current procedure
Security information
--sslkeysfolder location of converted certificates Converting default certificates
--sslpassword password of converted certificates Converting default certificates

You can run the serverinst command specifying a typical set of parameters. In this case, default values are used for all remaining parameters. For more information about all serverinst parameters and default values, see Server components installation - serverinst script.

A properties file named serverinst.properties is available if you do not want to type parameters in the command line. This is expecially useful if you need to specify many parameters or if you want to reuse the file for several installations. The file is located in image_location/TWS/interp_name.

You can specify values in the properties file, type them in the command line, or use both methods. If a parameter is specified both in the properties file and in the command line, the command line value takes precedence.

If you need to modify any of the default values, edit the serverinst.properties file, but do not modify the serverinst.template file located in the same path.

To install the master domain manager as a backup, perform the following steps:

  1. Log in to the workstation where you plan to install the master domain manager.
  2. Browse to the folder where the serverinst command is located in image_location/TWS/interp_name.
  3. Start the installation specifying a typical set of parameters. In this case, default values are used for all remaining parameters:
    On Windows operating systems
    cscript serverinst.vbs --acceptlicense yes --rdbmstype <db_type>
    --dbhostname <db_hostname> --dbport <db_port> --dbname <db_name>
    --dbuser <db_user> --dbpassword <db_password> --wauser <wa_user>
    --wapassword <wa_password> --wlpdir <Liberty_installation_dir>\wlp
    --sslkeysfolder <certificate_files_path> --sslpassword <keystore_truststore_password> 
    --inst_dir <installation_dir>
    
    On UNIX operating systems
    ./serverinst.sh --acceptlicense yes --rdbmstype <db_type>
    --dbhostname <db_hostname> --dbport <db_port> --dbname <db_name>
    --dbuser <db_user> --dbpassword <db_password> --wauser <wa_user>
    --wapassword <wa_password> --wlpdir <Liberty_installation_dir>/wlp
    --sslkeysfolder <certificate_files_path> --sslpassword <keystore_truststore_password> 
    --inst_dir <installation_dir>
    
    where
    --acceptlicense
    Specify yes to accept the product license.
    --rdbmstype|-r rdbms_type
    The database type. Supported databases are:
    • DB2
    • ORACLE This value applies to Oracle and Amazon RDS for Oracle
    • MSSQL This value applies to MSSQL and MSSQL cloud-based databases.
    • POSTGRESQL
    This parameter is required and has no default value.
    --dbhostname db_hostname
    The host name or IP address of database server.
    --dbport db_port
    The port of the database server.
    --dbname db_name
    The name of the IBM Workload Scheduler database.
    --dbuser db_user
    The database user that has been granted access to the IBM Workload Scheduler tables on the database server.
    --dbpassword db_password
    The password for the user that has been granted access to the IBM Workload Scheduler tables on the database server. Special characters are not supported.
    --wauser user_name
    The user for which you are installing IBM Workload Scheduler.
    --wapassword wauser_password
    The password of the user for which you are installing IBM Workload Scheduler.
    On Windows operating systems
    Supported characters for the password are alphanumeric, dash (-), underscore (_) characters, and ()|?*~+.@!^
    On UNIX operating systems
    Supported characters for the password are any alphanumeric, dash (-), underscore (_) characters, and ()|?=*~+.
    --wlpdir
    The path where WebSphere Application Server Liberty Base is installed.
    --sslkeysfolder keystore_truststore_folder
    The name and path of the folder containing certificates in .PEM format. The installation program automatically processes the keystore and truststore files using the password you specify with the --sslpassword parameter. The folder must contain the following files:
    • ca.crt
      The Certificate Authority (CA) public certificate. Note that if certificates being installed are part of a chain consisting of 3 or more certificates (one Root CA, followed by one or more Intermediate CAs, followed by the end user certificate), then this file must contain the Root CA certificate only. Any Intermediate CA certificates must be stored in the additionalCAs subfolder, which therefore becomes a mandatory subfolder. Each Intermediate CA must be stored in the additionalCAs subfolder in its own file.
      Note: From V10.2.3, if certificates being installed are part of a chain, the ca.crt can contain also the intermediate CAs. In this case, it must begin with one or more intermediate CA certificates and end with the Root ca.
    • tls.key
      The private key of the end user certificate for the instance to be installed.
    • tls.crt
      The public part of the previous key, that is the end user certificate.

    For UNIX systems, ensure that all the files have the ownership of the user who installed the master domain manager and the correct permissions (644).

    You can optionally create a subfolder to contain one or more *.crt files to be added to the server truststore as trusted CA, whose name must be additionalCAs. This can be used for example to add to the list of trusted CAs the certificate of the LDAP server or DB2 server. Additionally, you can store here any intermediate CA certificate to be added to the truststore. The subfolder must be named additionalCAs. Note that if the end user certificate being installed in the instance is part of a chain consisting of 3 or more certificates (one Root CA, followed by one or more Intermediate CAs, followed by the end user certificate), then the Intermediate CAs certificates must be stored in the additionalCAs subfolder, which therefore becomes a mandatory subfolder. Each Intermediate CA must be stored in the additionalCAs subfolder in its own file.

    For further information about how to generate custom certificates, see Managing certificates using Certman.

    --sslpassword ssl_password

    The password for the custom certificates and the path to the folder containing certificates in .PEM format with the sslkeysfolder parameter.

    For more information, see sslkeysfolder.

    You can optionally encrypt the password using the secure script. For more information, see Optional password encryption - secure script.
    --inst_dir installation_dir
    The directory of the IBM Workload Scheduler installation.
    Note: The values for the following parameters must match the values you provided when creating and populating the database:
    • --rdbmstype
    • --dbhostname
    • --dbport
    • --dbname
    • --dbuser
    • --dbpassword
    Note: Before starting the deployment of a new master domain manager or backup master domain manager on an already used database, be sure that no failed plan creation/extension has been performed. If a failed plan creation or extension has been performed, resolve the failure before attempting the new deployment or unlock the database by running the planman unlock db command.
  4. If you are installing a backup master domain manager, it is crucial to use the same encryption keys as those on the master domain manager, to ensure it can correctly decrypt encrypted files, such as the Symphony file. To achieve this, perform the following steps:
    1. Backup the files located in the TWA_DATA_DIR\ssl\aes folder on the backup master domain manager.
    2. Copy the files from the TWA_DATA_DIR\ssl\aes folder on the master domain manager to the TWA_DATA_DIR\ssl\aes folder on the backup master domain manager.
  5. To verify that the installation completed successfully, browse to the directory where you installed the master domain manager and type the following commands:
    On UNIX operating systems
     . ./tws_env.sh
    On Windows operating systems
    tws_env.cmd
    optman ls

    This command lists the IBM Workload Scheduler configurations settings and confirms that IBM Workload Scheduler installed correctly.

    You can also optionally run JnextPlan -for 0000 to extend by 0 hours and 0 minutes the production plan and add into the production plan (Symphony) the newly-created workstation, or wait for the FINAL job stream to complete, then run composer list cpu=server_workstation_name to ensure the agents have registered. You can also run a test job to ensure everything is working correctly.

You have now successfully installed the master domain manager as the backup master domain manager.

You can now proceed to Switching the master domain manager to the new backup master.