Splitting server configurations

Splitting server configurations is not generally recommended. However, it may be appropriate to split a server configuration if, for example, its size or number of active users has outgrown its hardware or OS platform, or if your company process dictates that data must be moved from production systems to archival storage.

Please visit the Support portal at https://www.microfocus.com/support regarding any performance or scalability concerns before making a decision to split your StarTeam server configuration. In many cases, problems can be resolved without splitting the server configuration.

Before splitting a server configuration, consider the following implications:

Irreversibility Once split server configurations have begun to evolve independently, there is no way to merge them back together.
Data Traceability Shares, links, and floating item configurations between the moved and unmoved projects will be lost.
Administration Initially, a new server configuration will have the same set of configuration settings, users, and groups as the original configuration. Going forward, you must manage each server configuration individually, as changes will no longer be propagated between them.
Licensing Please contact your sales representative to discuss potential licensing issues that may arise from splitting a server configuration. To ensure compliance with the license agreement, you should use licenses managed in a license server, preferably FLEXlm, rather than native licenses.

To split a server configuration:

  1. Copy the original server configuration (Server 1) to a separate machine.
  2. Remove the unwanted projects from the original server configuration.
  3. Remap the Microsoft SQL Server logins for the new server configuration (Server 2).
  4. Change the server GUID on the new server configuration (Server 2).
  5. Remove the unwanted projects from the new server configuration (Server 2).

    Note: In this example, we will assume that the original server configuration (Server 1) has three projects named Project A, Project B, and Project C. The plan is to split the server configuration so that Project A and Project B will remain on Server 1, and Project C will reside on the new server configuration (Server 2).

  6. Copy the Server 1 configuration to a separate machine:
    1. Make a full database and Vault backups of the Server 1 configuration.
    2. Restore the database and Vault on a secondary system.

      Caution: The database backup must be restored as a different database. Do not reuse the database location, Microsoft SQL Server database user, or Oracle schema user of the original server configuration.

      Once you complete the copy process, you should have two identical copies of your original server configuration running on two sets of hardware (server and database).

  7. Remove the unwanted projects from the Server 1 configuration:
    1. Make full database and Vault backups of the Server 1 configuration.
    2. Start the Server 1 configuration.
    3. Use the Cross-Platform Client to connect to Server 1 and delete Project C.
    4. Shut down the Server 1 configuration.
    5. Run Purge on the Server 1 configuration to physically remove the deleted data.
    6. Use the Vault Verify utility to verify the integrity of the configuration data.
    7. If necessary, make full database and Vault backups of the Server 1 configuration.
    8. Restore the database and Vault backups of the Server 1 configuration from step 1 on Server 2.
    9. If using a different Vault location, configure the files hive-index.xml and starteam-server-configs.xml to point to the new location.
  8. Remap the Microsoft SQL Server logins for the Server 2 configuration:
    1. Connect to the database using sa or windows authentication and change the database context to the restored database.
    2. Run command sp_change_users_login 'REPORT'. This command will print the orphaned user name.

      Note: The following steps assume that the orphaned user is starteam. Use the appropriate orphaned user as reported by the command sp_change_users_login 'REPORT'.

    3. Run the following commands in SQL Query Analyzer: 
      sp_addlogin starteam
EXEC sp_change_users_login 'Update_One', 'starteam', 'starteam'
    4. Copy the contents of the script set-owner-to-dbo.sql and run it against the database.

      Note: This script can be found in the DBScripts folder under the StarTeam Server installation location.

    5. As sa user, execute the script by running the command exec change_db_ownership 'starteam'.

      Note: Warnings generated from this command are safe to ignore.

    6. Go to SQL Enterprise Manager or Microsoft SQL Server Management Studio for Microsoft SQL Server and delete user starteam from the database. Select Yes to also delete the schema.

      Note: This action deletes the database user starteam, not the Microsoft SQL Server Login starteam. Deleting the schema deletes all the database objects owned by this database user, which is required in order to delete a database user. This step is essential because, while there can be many users with dbo privileges, there can be only one database owner. StarTeam Server must be run by the database owner.

    7. Run the command sp_changedbowner starteam.
    8. Log into the database as user starteam (the password is blank by default) and run the SQL statement select * from s0.
    9. Ensure that one row is returned.
  9. Change the server GUID on the new server configuration (Server 2):
    1. In the file starteam-server-configs.xml, update the option ServerGuid with a different GUID value for the new configuration name. For example: <option name="ServerGuid" value="n"/>, where n is the new server GUID value.
    2. Depending on whether it's a Microsoft SQL Server or Oracle database, perform one of the following steps to update the Server Settings table with the new server GUID value.
      • For Microsoft SQL Server, open a database connection using Microsoft SQL Server Management Studio or Studio Express, change the database context to the new database, and run the SQL statement update s0 set f3 = n, where n is the new server GUID value.
      • For Oracle, open a database connection to the new schema using SQL*Worksheet/SQL*Plus and run the following SQL statement, where n is the new server GUID value. 
      update  s0 set f3 = n;
commit;
  10. Remove the unwanted projects from the new server configuration (Server 2):
    1. Configure a database connection for the restored server configuration.
    2. Start the Server 2 configuration.
    3. Use the Cross-Platform Client to connect to Server 2 and delete Project A and Project B.
    4. Shut down the Server 2 configuration.
    5. Run Purge on the Server 2 configuration to physically remove the deleted data.
    6. Use the Vault Verify utility to verify the integrity of the configuration data.
    7. If necessary, make full database and Vault backups of the Server 2 configuration.

Back to top