VanDyke Software

Moving VShell® for Windows® to a Different Server

Index

Moving VShell for Windows to a Different Server

Moving VShell from one computer ("the old machine") to another computer ("the new machine") involves the following steps:

  1. Verify that the version of VShell you have is compatible with the new machine.
  2. Export the configuration settings from the old machine to an XML file.
  3. Install VShell on the new machine.
  4. Import the configuration settings to the new machine.
  5. Perform any migration steps that must be completed manually.
  6. Stop the VShell service(s) on the old machine.
  7. Start the VShell service(s) on the new machine.

Note: The license agreement for VShell allows you to create a backup server following these instructions as long as the backup server will only be available to receive incoming connections when the primary VShell server is unreachable. If you have any questions about VShell licensing, please contact sales@vandyke.com.

The following sections discuss each step.

1. Verify that the version of VShell you have is compatible with the new machine

  1. On the old machine, bring up the VShell Control Panel and select the About category.
  2. Note the version of VShell currently being used.
  3. Note the operating system of the new machine.
  4. Verify compatibility.
    • If you have the current version, verify that the OS of the new machine appears in the list of platforms listed on the VanDyke Software Product System Requirements page.
    • Otherwise, contact support@vandyke.com to ask about compatibility.

2. Export the configuration settings from the old machine to an XML file

See Exporting and Importing the VShell Configuration for instructions.

3. Install VShell on the new machine

  1. If your license permits, download the latest VShell installer from the VanDyke VShell Downloads page (if needed, installers for previous versions of VShell can be found on the VanDyke Previous Releases page).
  2. Double-click the VShell installer icon and follow the prompts to install VShell.
  3. If you have VShell configured to allow clients to connect using public-key authentication, you must ensure that the LSA module is selected as a feature during the installation (it is enabled by default); then, you must reboot the VShell server machine before clients will be able to connect using public-key authentication.

4. Import the configuration settings to the new machine

See Exporting and Importing the VShell Configuration for instructions.

5. Perform any migration steps that must be done manually

+ Access control

Domain accounts

If your VShell configuration references domain accounts for Access Control or Virtual Root configurations, ensure that the new VShell machine has the same domain membership and access as your existing VShell machine.

Local Windows accounts

If your VShell configuration referenced local Windows accounts for Access Control or Virtual Root configurations, you will need to recreate those same user accounts on the new VShell machine.

Alternatively, you may want to consider creating VShell User Database accounts instead.

VShell user database accounts

Internal VShell user database accounts are automatically migrated. 

It is necessary, however, to ensure the "System username" account associated with the VShell user database is available on the new VShell machine:

  • If it is a local Windows account on the old machine, make sure that same account with the same password exists on the new Windows machine.
  • If it is a domain account, make sure that the new VShell machine has the same trust relationship with the domain that the old VShell machine does.

+ Trigger scripts

Copy any trigger scripts from the old machine to the same location on the new machine.

If the location of any of the trigger scripts on the new machine will be different than they were before, the trigger scripts may need to be reconfigured to properly reference any different file locations.

+ X.509 certificates

If VShell is configured to use X.509 certificates, you will need to install the root CA certificate on the new machine as per instructions in the VShell Help under the "Use X.509 Certificates" topic.

  • Also, you must copy any existing certificate map files from the old machine to the new machine.

+ Listen Addresses

If VShell is configured with SFTP and/or FTPS Listen Addresses using specific IP addresses (e.g., 198.24.364.10) as opposed to the default configuration (e.g., 0.0.0.0) then the Listen Addresses must be updated with the IP address of the new machine.

+ Public keys

If your version of VShell is 4.1 or earlier, and you have VShell configured to use public-key authentication, you must copy the users' public-key files manually from the old machine to the new machine.

Starting with VShell 4.2, public-key files and folders are included in a complete export/import of the configuration, so no additional work is necessary.

+ Important note about host keys

Be aware that if the host name and IP address of the new machine are different than that of the old machine, clients connecting to VShell on the new machine will prompt the user to accept and save the host key. Even when the old host key is migrated to the new server (as it is when a complete export is done), the clients will still prompt because they have not yet made an association between the old host key and the new hostname / IP address. The only way to prevent the prompting is to force the hostname / IP address of the new machine to be the same as the one used for the old machine.

+ Important note about FTPS certificates

If clients are connecting using FTPS, and the host name and IP address of the new machine are different than that of the old machine, you will need to create a new FTPS certificate for the new machine and configure VShell to use it before clients will be able to authenticate to the new VShell server using FTPS. This can be done on the FTPS Listen Addresses page of the VShell Control Panel after VShell is migrated to the new machine.

6. Stop the VShell service(s) on the old machine

For VShell versions 3.5 and newer:

  1. Go to the Common page of the VShell Control Panel.
  2. In the Service control section, click the appropriate button(s) to stop the service(s) that are currently running.

For VShell version 3.0 and older:

  1. Stop the VShell using the Windows services control panel –or-
  2. Stop the VShell using the command line, e.g., net stop <service name>

7. Start the VShell service(s) on the new machine

  1. Go to the Common page of the VShell Control Panel.
  2. Click the Start SSH2 Service or Start FTPS Service button.
  3. At this point, VShell should be ready to use.

Questions?  Contact support@vandyke.com