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

Resolution

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.

• Upgrades are incremental.
  You may need to upgrade through multiple versions to be able to upgrade to the latest release, depending on your current version of Parallels Secure Workspace (formerly Awingu). These are defined in our release notes; there's also an overview at the end of this article
• Take a snapshot of the appliance(s) (and if applicable: external database) before EACH upgrade. 
  Before carrying out a version upgrade, it is always highly recommended to shut down the appliance(s) and take a snapshot/backup of the appliance(s). If applicable, do the same for the external database. Quite often, the appliances still need a reboot anyway
• If there are major issues during/after the upgrade:
  1. Contact the support team first for analysis, so the cause can hopefully be determined, and perhaps the failed upgrade can even be resolved. Without log files of the upgrade attempt, it's nearly impossible to determine the cause.
  2. Only if time is of the essence, try to keep a snapshot of each appliance in the Parallels Secure Workspace cluster when the upgrade seems to fail.
  3. In the worst case, the support team will recommend restoring these snapshots to restore accessibility to the appliance as quickly as possible.
• Download or Download & Upgrade. 
  When you are on the General Info page of the System Settings, there's an option to Download or Download & Upgrade (depending on which version).
  Download will download the update packages, ready to install later (the button will change when the packages are downloaded.
  Download & Upgrade will download the upgrade packages. When complete, the installation begins immediately.
• Service interruption. 
  When upgrading an environment, there will always be service disruption, a period where users cannot access/use the environment. This is also the case for a multi-node environment, so it's recommended to upgrade outside business hours.
• Service interruption period. 
  During an environment upgrade, the average estimated length can be calculated as about 15 minutes per appliance in the cluster.
  For example, if there are 3 nodes in the cluster, this will take approximately 45 minutes to upgrade. This is because Parallels Secure Workspace sequentially upgrades the nodes.However, in some situations, the upgrade can take a lot more time per appliance (see below matrix), depending on the disk and network speed.
• Do not refresh the System Settings page. 
  While the upgrade is in progress, do not refresh the System Settings page. When using the built-in admin account to do the upgrade, the account will be automatically logged out after 15 minutes. This is no problem, just log in and open the System Settings again.
• NEVER reboot the appliance(s) manually during an upgrade unless told so. 
  It is important to never reboot appliances while they are in an upgrading state because "it feels like the upgrade is taking too long" (check the matrix below for an estimate and maximum expected service interruption).

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 .

For the versions below, you 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.

Compatibility with the external database server

If you are 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 while the external database is using an outdated cryptographic protocol, the upgrade may fail.

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 still share files through the Workspace after backing up the environment, this data 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".
   • This does not include the external database (if you are using one). If you have one, make sure to have a proper backup as well.
   • 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 one 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.
   • Ensure this new node is assigned a unique IP address.
   • When using an external database, ensure the configuration no longer points to the original database, but to the copy.
5. Update this newly deployed node as usual, all the way to the desired version.
6. For a multi-node environment: Add new nodes as needed. The version of these nodes must match the current version of this fresh node in the step above.
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: Some data is lost if users are still temporarily working on the original environment.
Audit logs would be created on the original environment, and thus missing from the database backup you've already taken.