How to prevent duplication of scalability server in MDB when hardware is replaced.

Document ID : KB000022676
Last Modified Date : 07/03/2018
Show Technical Document Details

In order to prevent database duplication when replacing or virtualizing scalability server hardware, while retaining the original server host name and DNS extension, it's necessary to take some steps.

Client Automation (ITCM) -- any version

Method #1: Unregister and delete the old scalability server first. [Preferred Method]

1- Stop CAF on the scalability server being replaced.

2- Delete the scalability server from the database:

Using the DSM Explorer GUI:
- In the DSM Explorer tree, navigate to Control Panel -> Scalability Servers -> All Scalability Servers.
- Delete the scalability server getting replaced.
- In the DSM Explorer tree, navigate to Computer and Users -> All Computers.
- Delete the scalability server's agent.

Using the command line interface:
- From the scalability server command line: cserver unregister
- From the domain manager command line: cadsmcmd targetcomputer action=delete name=<computername>

3- Take the old scalability server offline and replace it with the new scalability server. The old scalability server and it's corresponding agent records have both been removed from the database. Now, after refreshing the hardware or virtualizing, no conflict/duplication will take place when replacing it with a new scalability server.

Important Note: When unregistering/deleting the scalability server from the database, all agents listed as registered to the scalability server will now show a blank scalability server address. This is expected as the agents are temporarily unlinked in the database from any known scalability server. After the scalability server is replaced, the affected agents will properly get relinked to the new scalability server once their next registration message is processed by the engine.

Method #2: Transfer the Host UUID from the old scalability server to the new one.

1- Stop CAF on the scalability server being replaced.

2- Backup the HostUUID registry key from the old scalability server being replaced:
On a 32-bit OS: HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\HostUUID
On a 64-bit OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ComputerAssociates\HostUUID

3- Replace the old scalability server. After installing the Client Automation scalability server, do not select the option to start the CAF service at the end of installation.

4- On the new scalability server, replace the HostUUID registry key with the backup taken from step #2 on the old scalability server. If the architecture of the OS has changed (i.e. 32-bit to 64-bit), manually adjust the backup of the registry key so it's restored to the proper location in the registry.

5- After replacing the HostUUID registry key, we now have to lock it from changes. To do this, add an additional String Value to the HostUUID registry key called, "LockHostUUID". Set the value of this string to be 1.

6- Start CAF on the new scalability server. It may be necessary to run the following registration commands:

cserver register -a
caf register all

Important Note: Using this second method, the domain manager will still list the staging server library as registered under the previous hardware. It's necessary to run the synchronize staging server library procedure in Software Delivery (as a procedure in the Scalability Server install package) to correct this and restage any necessary software packages again. Alternatively, if you migrated the staging server library when replacing the hardware, you can use sd_sscmd aregsw command to register the packages in the staging library.