Upgrading from a previous version
Upgrading. If you have an older version of Bitvise SSH Server (or an even older WinSSHD) and wish to upgrade to the latest one, download the new installer from our website and execute it on the machine where your previous SSH server version is installed. The installer will detect an existing installation and will automatically remove it before installing the new one.
During upgrade, your server host keys and settings will be preserved.
In case you must downgrade. During a downgrade, your SSH Server settings will be reset. Unless this feature is disabled, recent Bitvise SSH Server versions automatically create backups of your settings when they are modified. You can revert to one of these backups if you decide to downgrade. The backups are located in the Config subdirectory of your SSH Server installation directory.
Older WinSSHD versions (e.g. 4.xx) do not maintain backups. Before upgrading from such a version, you should use the WinSSHD Control Panel to export your settings to a file in case you later decide to downgrade.
Activation. Any existing activation code you have will work for the new version only if the new version was released prior to the upgrade expiry date embedded in the activation code. If your existing activation code is not valid for the upgraded-to version, the new version will install without a hitch, but will drop into time-limited evaluation. If your upgrade access has expired, log into your License Overview to purchase an upgrade extension and apply a new activation code.
If the purchasing process in your organization is slow, we recommend that you initiate the upgrade extension process before you plan to upgrade to a version not covered by your current upgrade access.
Upgrading Bitvise SSH Server when it provides exclusive access
Sometimes, Bitvise SSH Server is installed on machines where it provides exclusive access to those machines, and no other ports are open. In such situations, bringing the SSH server down for maintenance or an upgrade can render the machine inaccessible if something goes wrong.
In such situations, we recommend installing an additional SSH server installation as a named instance. The additional SSH server installation should accept connections on a different port than the primary installation. This port should be accessible through any routers and firewalls. When maintenance or upgrade is needed on the primary installation, access the server through the alternate installation, and vice versa.
Note that multiple Bitvise SSH Server installations running directly on the same OS installation do not constitute an additional machine, and are covered by the same license. Therefore, no additional purchase is necessary for the maintenance installation.
Unattended upgrade
It is possible to upgrade Bitvise SSH Server in unattended mode, without having to explicitly remove the previous version. This can be done by executing the Bitvise SSH Server installer with command line parameters:
BvSshServer-Inst.exe -defaultInstance
Alternately, if upgrading a named instance:
BvSshServer-Inst.exe -instance="Bitvise SSH Server - InstanceName"
Or by specifying the installation directory:
BvSshServer-Inst.exe -installDir="C:\Program Files\Bitvise SSH Server - InstanceName"
You will also need to supply the -acceptEula parameter to indicate acceptance of the Bitvise SSH Server End User License Agreement.
The installer will automatically stop the SSH Server service and the SSH Server Control Panel, and restart them after if they were running before the upgrade.
Discovering installed instances
Bitvise SSH Server can be installed multiple times on the same computer. Separate instances can use different SSH Server versions. Each instance must have a name which is unique on that computer, for example Bitvise SSH Server - InstanceName. There may or may not be a default (unnamed) instance. A default instance is named simply Bitvise SSH Server, with no additional instance name.
For any unattended upgrade, it is important to know the names of the target instances.
If you only need to check one or a few computers, discovering installed SSH Server instances is easiest using the Apps & features interface in the Windows Control Panel.
If you need to check many computers, you can automate the process using the following PowerShell script:
This can be run directly or called from a PowerShell script. It returns (or if run directly, displays) a PowerShell object enumerating the installed SSH Server instances and their properties such as versions and installation directories.
Unattended activation code update
From time to time, you might extend upgrade access for your licenses and receive a new activation code. You might need to update to a new SSH Server version which requires a higher upgrade access expiry date than your current activation code permits.
If you are administering a small number of SSH Server installations, it may be easiest to apply the new activation code using the SSH Server Control Panel. This can be done either before or after updating to the new SSH Server version. If you plan to apply the new activation code after upgrading, the main risk is that you may forget. In this case, the SSH Server will continue to run with full functionality for up to 30 days. If no new activation code is applied during that time, it will revert to a state of expired evaluation.
If you are administering a large number of SSH Server installations, there are multiple ways to apply a new activation code unattended:
It may be most practical to apply the new activation code at the exact time it is needed - during installation of a new version that requires it. To do so, run the installer as follows:
BvSshServer-Inst -defaultInstance -activationCode=...
Since SSH Server versions 8.xx, an activation code can be applied from the command line using the BssCfg utility:
BssCfg actCode set ...
Since SSH Server versions 8.xx, an activation code can also be applied using a PowerShell script. Example for versions 9.xx:
$cfg = new-object -com "Bitvise.BssCfg" $cfg.actState.SetActCode("...")
In this case, $cfg.actState can also be used to inspect the current activation state. For more information, run:
$cfg.actState.help
In each of these cases, the activation code must be supplied as a single string, after concatenating both lines (no line breaks).
If there are multiple concurrent SSH Server instances, the same activation state applies to all instances on the computer.