This article describes the steps to migrate an existing installation of vSEC:CMS from one server to a new server.
Procedure on Current Server
This section describes the steps which need to be performed on the server where the current vSEC:CMS is running.
1. It is required to stop all work on the vSEC:CMS system, i.e. logout all operators and shutdown the vSEC:CMS service from Windows service control manager.
2. Make a copy of all the contents of the dat folder on the current server. The permissions of the dat folder must be changed. By default, the owner of the dat folder is set to local SYSTEM and to be able to copy the dat folder the ownership must be changed from SYSTEM to a different user account that has the rights to copy the folder. If the vSEC:CMS service is running under a dedicated Windows account then it is best to log onto the server with this account in order to be able to copy the contents of the dat folder.
Procedure on New Server
Depending on the credential that you are using it will be necessary to have the appropriate credential drivers installed on your host. Please check with the credential provider that you have the correct credential drivers installed.
From version 6.0 and above Microsoft .NET Framework 4.8 should be installed.
You can validate what version of Microsoft .NET Framework is installed on your host by running the Powershell command below to see the full version information:
1. On the new server you will need to install the vSEC:CMS.
2. After the installation, the vSEC:CMS service is started automatically. The service must be stopped (using Windows service control manager) to be able to replace the database files in dat folder.
3. If the vSEC:CMS service on the current server is running under a dedicated Windows account then you need to follow the instruction in the article Configure Dedicated Windows Service Account.
4. Copy the entire contents of the dat folder, including all the files, as described in the Procedure on Current Server step and place them on the new server.
5. Now start the vSEC:CMS service (from Windows service control manager) to complete the migration.
6. If the vSEC:CMS is configured to use key store then you will need to go to Options – Operators and select the key store operator and click the Activate button.
7. If the vSEC:CMS is configured to use self-service issuance and renewal then it will be necessary to configure an Enrollment Agent (EA) certificate server-side. It will be required to log onto the console on the server with the System Owner token to complete this task. From Options – Connections select your Microsoft CA connection and click Edit. In the Enrollment Agent section enable Sign server side. This will automatically grey out Proxy through server setting as we want all Operator console certificate issuances to be proxied through server. Click the Request button to start the issuance. If more than one EA certificate templates are configured on the CA a dialog will be presented from which the EA certificate template that is to be used should be selected. An EA certificate will then be issued to the local certificate store for the Windows account that the vSEC:CMS is running under. Click Save to save changes and close
The EA certificate will be issued to the Windows account that vSEC:CMS service is running under. The certificate template configured directly on the CA will need to have disabled the checkbox This number of authorized signatures from the Issuance Requirements tab on the CA template.
The dedicated Windows account that the vSEC:CMS service runs under will need to have the appropriate permissions on the CA template that it is using in order to connect to it. The permission in this case is Enroll which needs to be set from the Security tab of the template. This permission will need to be set on any CA template that the vSEC:CMS is using. Additionally, the Windows account that the vSEC:CMS service runs under will perform the revocation requests on the CA. Therefore, this user needs to have Issue and Manage Certificates permissions on the CA, which are configurable from the certsrv console on the CA.