Introduction
This document will describe how to migrate an already functional Load Balanced (LB) environment to a new environment. This document will describe in detail how you can move your existing LB environment to a new LB environment. All steps in this document need to be followed one-by-one to ensure that the migration will be performed without any issues.
It is expected that the reader of this document has already setup and/or is familiar with the current LB environment in place. Additionally, it is expected that the reader is familiar with the concept of LB, networking and SSL/TLS.
It is expected that the MS SQL database used when migrating is the same MS SQL database that is used in the current LB environment.
It is required to have the MS SQL native client version provider installed on the new master and slave(s) on which the vSEC:CMS is to be installed. Version information is provided in the table below.
|
SQL Native Client Version |
MS SQL Server Version |
|
11.0 (SQLNCLI11) |
2012, 2014, 2016, 2017, Azure SQL |
Step 1 – Make Note of Current Configuration
On the current master and one of the current slaves open the vSEC:CMS console application. From Options – Connections make a screenshot capture of what you have configured for each of the SOAP services connections configured, i.e. User Self-Service, RSDM Service, Operator Console Service and API Service. For example, make a screenshot of the connection details for User Self-Service and do the same for the other connections and store this information to be used later.
Step 2 – Stop vSEC:CMS Services Slave(s)
On each of the current slave(s) stop ALL of the vSEC:CMS services that maybe running from the Windows services console, i.e. vSEC:CMS Service, vSEC:CMS - User Self Service, vSEC:CMS - RSDM Service, vSEC:CMS - Operator Console Service and vSEC:CMS – API Service. Ensure that all of the services have shutdown. You can verify this from the Details tab of Windows Task Manager on the server and ensure that AdmServer.exe, ApiServer.exe, CmsService.exe and UssServer.exe are not running. If any of these are running you should select them and click End task from Task Manager to stop them.
It is recommended as best practice to make a complete backup copy of the entire installation folder where the current vSEC:CMS is installed in case it is required to roll back and/or it is required when troubleshooting issues that may occur in the future. This is normally located here: C:\Program Files (x86)\Versasec\vSEC_CMS S-Series.
Step 3 – Stop vSEC:CMS Services Master
On the current master stop ALL of the vSEC:CMS services that maybe running from the Windows services console, i.e. vSEC:CMS Service, vSEC:CMS - User Self Service, vSEC:CMS - RSDM Service, vSEC:CMS - Operator Console Service and vSEC:CMS – API Service. Ensure that all of the services have shutdown. You can verify this from the Details tab of Windows Task Manager on the server and ensure that AdmServer.exe, ApiServer.exe, CmsService.exe and UssServer.exe are not running. If any of these are running you should select them and click End task from Task Manager to stop them.
It is recommended as best practice to make a complete backup copy of the entire installation folder where the current vSEC:CMS is installed in case it is required to roll back and/or it is required when troubleshooting issues that may occur in the future. This is normally located here: C:\Program Files (x86)\Versasec\vSEC_CMS S-Series.
Step 4 – Install vSEC:CMS Master
On the new master server install the version of vSEC:CMS that you wish to run using the installer GUI wizard. Once complete stop the vSEC:CMS Service from the Windows services console.
Step 5 – Install vSEC:CMS Slave(s)
On the new slave(s) server(s) install the same version of vSEC:CMS that was installed on master using the installer GUI wizard. Once complete stop the vSEC:CMS Service from the Windows services console.
Step 6 – Change Service Account
On the new master and new slave(s) change the vSEC:CMS Service to run under the same Windows user account as was configured on the current master and slave(s). This should be changed in the Windows services console.
Step 7 – Copy DAT Contents
Copy ALL files from the current dat folder of the master to the dat folder on the new master replacing any files in the new master. The dat folder is located in the root folder of the vSEC:CMS server. You will need to make sure that the Windows user account that the vSEC:CMS service runs under, as configured in Step 6, has full permission on the dat folder on the new master.
Similarly, copy ALL files from the current dat folder of the slave to the dat folder on the new slave replacing any files in the new slave. The dat folder is located in the root folder of the vSEC:CMS server. You will need to make sure that the Windows user account that the vSEC:CMS service runs under, as configured in Step 6, has full permission on the dat folder on the new slave. If you have more than one slave in your environment it is recommended to copy the contents from current slave1 to new slave1 and so on for as many slaves as you have in your environment.
Step 8 – Copy LB_config.xml
From the current master copy the file LB_config.xml to the new master. The LB_config.xml is located in the root of the vSEC:CMS installation which is normally located here: C:\Program Files (x86)\Versasec\vSEC_CMS S-Series.
From the current slave(s) copy the file LB_config.xml to the new slave(s). The LB_config.xml is located in the root of the vSEC:CMS installation which is normally located here: C:\Program Files (x86)\Versasec\vSEC_CMS S-Series. If you have 2 or more slaves make a copy of the file on current slave1 as indicated above and copy this file to the new slave1. Continue the same procedure on any other slaves you may have.
Step 9 – Start vSEC:CMS Master Service
On the new master start the vSEC:CMS Service. Depending on the size of your database it may take some time for the service to fully load. You can monitor this from the Details tab in Task manager and look at the CmsService.exe. Once you see that the CmsService.exe CPU is constant at 0-2% then start the other vSEC:CMS services that you had running on the current master.
Log onto the vSEC:CMS console application on the new master to confirm that this can be done successfully.
Navigate to Options – Operators and select the Service key store operator, as indicated by Type in the table, and click the Activate button to activate the key store operator.
It will also be necessary to configure an Enrollment Agent certificate for the Service key store operator on the new master. Follow the instructions in the document Configure-User-Self-Service in the section Step 3 - Configure Request Signing Settings to complete that setup.
Step 10 – Export Registry Settings Slaves
On each of the current slave(s) make an export of registry key located below and save this as a file:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T]
Copy this file to each of the slave(s) and apply it. For example, if you have 2 slaves make a copy of current slave1 registry as indicated above and copy this file to the new slave1 and apply the registry key on the new slave. Continue the same procedure on any other slaves you may have.
Presuming that the master server is a new server and therefore a different host name, you need to make sure that the new slave(s) point correctly to the new master server. When setting up your original LB environment as documented in the document Configure Load Balancing, you would have configured URLs in registry on each of the slave(s) to point to the master. Therefore, it is important that if the new master server has a different host name then make sure to correctly point each slave to the new master.
These URLs are configured in registry below on each of the slave(s):
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
Look at the DWORD entries soap.adm.lb.url, soap.rsdm.lb.url and soap.uss.lb.url and make sure these point to the master correctly.
If SSL/TLS is used it is important that you have similar certificates available on the slave(s) and master as was configured when setting up the original LB environment. This is out of scope for vSEC:CMS.
Step 11 - Start vSEC:CMS Slave(s) Service
On the new slave start the vSEC:CMS Service. Depending on the size of your database it may take some time for the service to fully load. You can monitor this from the Details tab in Task manager and look at the CmsService.exe. Once you see that the CmsService.exe CPU is constant at 0-2% then start the other vSEC:CMS services that you had running on the current slaves.
Perform the same as described above on any other slaves you may have deployed.
Log onto the vSEC:CMS console application on the new slave(s) to confirm that this can be done successfully.
Configuration changes/updates to the LB to manage the traffic to the new slave(s) are not in scope for vSEC:CMS and is the responsibility of the end customer/user to ensure that this is properly configured.
Step 12 – Validation
Now with all components in place you should perform a task from a client to ensure that the new LB environment is functioning as expected. A suggestion is to perform a full end-to-end credential token issuance to make sure everything is functional as expected.