Updating your Parallels Secure Workspace environment: What to expect from a version upgrade?

0 users found this article helpful


For instructions on upgrading your Parallels Secure Workspace environment, and details about the changes in the version, please take a look at our release notes.

This article contains important factors to keep in mind/to expect when planning to upgrade Parallels Secure Workspace to the latest version.


Upgrade paths

This is a summary of the upgrade paths.

Keep in mind that if you are using an external database, some requirements or supported versions may change between versions. Lower, you'll find a short matrix of supported database server versions as well.

Related info: No upgrades available / latest version not available .

From To Notes
5.5.1 5.6.0 (latest version)  
5.4.0, 5.4.2, 5.4.4 5.5.1  
5.3.3, 5.4.0, 5.4.2 5.4.4 The upgrade to 5.4 is a long one as it also upgrades the underlying OS.
For an estimate, take 60 minutes per appliance.

Because of this, when using an external database server, make sure it supports TLS 1.2. 
Otherwise, the upgrade will fail.
5.2.4, 5.2.5, 5.3.1, 5.3.2 5.3.3  


For the versions below, you will need to reach out to support for assistance. It will take several hours to upgrade to the latest version, even if everything goes smoothly. Consider deploying from scratch and manually reconfiguring.

From To Notes
5.1.1, 5.1.3, 5.2.0, 5.2.2, 5.2.3 5.2.5  
5.0.6, 5.1.1 5.1.3

Before upgrading to 5.1.3, it's necessary to migrate the audit logs. If still required, this is visible at the bottom of System Settings > Global > General info.

The upgrade to 5.1.3 is a long one as it also upgrades the underlying OS.
For an estimate, take 45 minutes per appliance.




Compatibility with the external database server

When using an external database, remember that the supported versions also change over time.

If you are using an unsupported version at some point, you may run into (upgrade) issues.

Also, note that as of Parallels Secure Workspace/ Awingu version 5.4, TLS 1.0 and TLS 1.1 are no longer supported.
If you upgrade from version 5.3 to 5.4 and are using an outdated cryptographic protocol, this may result in a failed upgrade.

  Microsoft SQL Server Microsoft Azure SQL PostgreSQL
Product version Minimum Maximum Minimum Minimum
Parallels Secure Workspace 5.6
Awingu 5.5
15.0 (2019) 16.0 (2022) 12.0 9.4
Awingu 5.4
Awingu 5.3
Awingu 5.2
Awingu 5.1
Awingu 5.0
13.0 (2016) 15.0 (2019)


High availability

Since upgrades can take a while, there are some alternative strategies that may work as well.

For example, as of version 5.3, this could be a strategy to minimize downtime. 

  1. Communicate to users that they should not take certain actions until the upgrade has been performed.
    • For example: if they would still share files through the Workspace after backing up the environment, this will not be present in the final environment. Once the upgrade is completed, each user would need to "update" their shares to make them work again.
  2. Create an "environment backup".
    • Mind that it does not include the external database, so this would need to be backed up manually. 
    • Mind that an environment backup has some limitations (see admin manual). For example, "shares" (files shared through the Workspace) are not backed up/restored. After restoring, users will still see their shares, but they will need to press the "Upgrade" button again.
  3. Deploy a new node - this must match the existing Parallels Secure Workspace version.
    • When working with an external database, deploy a copy (restore from backup) on the database server.
  4. During the initial configuration wizard, this environment backup can be imported.
    • Make sure to give this new node a new IP address.
    • When using an external database, make sure the configuration no longer points to the original database, but to the copy.
  5. Update this newly deployed node as usual.
  6. In case of a multi-node environment: add new nodes (same version).
  7. Update the applicable network infrastructure (DNS, firewall, load balancer, ...) to point to the IP address(es) of the new appliance(s).
  8. Communicate to users that everything is up and running again.
  9. Shut down the original nodes. Decommission once everything is confirmed to be working smoothly.

Note: there will be some missing audit logs etc. from between the moment of backing up the original database, and the go-live with the new environment.

Was this article helpful?

Tell us how we can improve it.