Overview

From version 2.9 onward, new releases of AppsAnywhere and Analytics are provided as a virtual appliances.

To upgrade, you simply need to import the latest version of the virtual appliance to create new servers.

Once your new servers are configured, Software2 will transfer service to the new servers during an agreed upgrade window.

Your existing servers remain operational until the upgrade window, at which point the new servers will take over delivery of your app portal.

Once service is transferred to your new servers, your old servers can be retired.

This process refers exclusively to AppsAnywhere and Analytics servers. Cloudpaging and Parallels RAS servers are upgraded in-situ.

Preparing to Upgrade

The current appliance is available to download from Latest Releases within the Software2 support portal.

You will need to create the same number of new servers, to match the number of existing AppsAnywhere servers that you currently have.

The high-level process is as follows:

  1. Deploy the latest virtual appliance, once for each server required.

  2. Complete first-time configuration for each new appliance based server.

  3. Ensure that the Network Requirements are in place. Newer versions of AppsAnywhere have additional requirements.

  4. Provide details of your new servers and remote access to Software2.

  5. Schedule the upgrade window with our support team.

Your existing database (and load balancing solution) will continue to be used. The database schema is updated by Software2 during the upgrade window.

If you are ready to upgrade to the latest version of AppsAnywhere or Analytics, please contact Software2 Support.

Our support team are also available to help with any questions about the upgrade process.

Planning your Upgrade Window

During the upgrade window your AppsAnywhere service will be temporarily unavailable for a short time.

Unfortunately this is unavoidable, so Software2 will make every effort to reduce the length of time that the service is offline.

Customers should notify service users of:

  • Service at Risk Period – number of AppsAnywhere servers x 20 minutes

  • Service Downtime – starting approximately 5 minutes in and lasting until 5 minutes from the end of the Service at Risk Period

As per our Service Level Agreement, AppsAnywhere upgrades will need to take place during our business hours of support.

However, we will work with you to schedule a suitable time, taking advantage of our support personnel in different timezones wherever possible.

Upgrading between virtual appliances is a faster upgrade process than ever before. During the upgrade window, your existing AppsAnywhere configuration is automatically transferred from your current servers to the new.

We are also working to make it possible for customers to carry out your own upgrades in future, providing greater flexibility for scheduling and less reliance on Software2.

Pre-upgrade Requirements

Customer Contacts

Most of the upgrade procedure will be carried out by Software2 Support.

However, the following customer personnel will need to be involved and available for the duration of migration window:

  • AppsAnywhere administrator

  • Load Balancer administrator

Contact details must be provided for at least one lead customer contact.

It is also advisable that the following customer personal can be contacted in case of any issues:

  • Hypervisor / server administrator

  • Database administrator

  • Network administrator

  • Active Directory administrator

Remote Access

Software2 Support will require remote access to all AppsAnywhere servers for the duration of the upgrade procedure, as noted under Network Requirements.

Test Machine

To confirm that migration is successful, Software2 Support will need a test user account and access to a test machine.

This is used to verify that single-sign on is working and that apps can be launched successfully.

Backups

A full backup of the AppsAnywhere database must be taken prior to upgrade. This backup can be done by Software2 Support if required, providing the relevant access and permissions are in place.

Your pre-existing AppsAnywhere servers will not be changed, though it is generally good practise to take server snapshots prior to upgrades.

Upgrade Procedure

Ahead of the upgrade Software2 Support will confirm that all prerequisites are in place.

We will also establish a line of communication with your AppsAnywhere administrator, to be maintained through the upgrade process.

Your AppsAnywhere administrator will need to coordinate to ensure that the customer actions noted in the below table are carried out promptly.

Step

Action

Performed By


SERVICE AT RISK WINDOW BEGINS

1

Backup the AppsAnywhere Database.

Customer or Software2

2

Configure your Load Balancer to point to a maintenance page, by draining and taking the AppsAnywhere rules offline.

Customer


SERVICE DOWNTIME BEGINS

3

Disable all services on the existing AppsAnywhere servers (the servers must remain online).

Software2

4

Initiate the automatic configuration transfer from your existing AppsAnywhere servers to the new servers.

Software2

5

Testing of each new AppsAnywhere server individually.

Software2

6

Configure your Load Balancer to remove the old servers, add the new servers, and bring the rules online.

Customer


SERVICE DOWNTIME ENDS

7

Testing of AppsAnywhere via the load balancer, and customer sign-off.

Software2 and Customer


SERVICE AT RISK WINDOW ENDS

Functionality Tests

During upgrades, services will be tested (including via the load balancer) to confirm functionality.

Tests will be performed from the designated test machine and include:

  1. Login (manual and SSO).

  2. Validation and basic portal functions.

  3. Launch of applications (including Cloudpaging and Parallels RAS where applicable).

  4. Access to the admin interface and confirmation of version numbers.

  5. Confirmation that Analytics Dashboards and Explores load

Issues During Upgrade

Software2 Support will keep you informed should there be any issues during the upgrade procedure.

The first action will be to review the deployment logs which detail each step of the process along with any errors that may have occurred.

In almost every case, the deployment logs provide enough information relating to a failure for the issue to be resolved and for the upgrade to be completed successfully.

  1. Review deployment logs for errors

  2. Correct cause of errors where possible

  3. Complete the upgrade procedure

If there is a problem during the upgrade window (and there is insufficient time remaining to investigate), Software2 Support will discuss this with you and ask for authorization to commence rollback procedures.

Rollback Procedure

There are two main scenarios in which a rollback is advisable:

  1. A significant problem is encountered during the upgrade procedure and the remaining window is unlikely to allow for investigation and resolution.

  2. Upgrade is completed but AppsAnywhere does not function as desired, as determined by the post-upgrade functionality tests.

In either of these cases, service can be reverted to your pre-existing AppsAnywhere servers, which remain unchanged.

Step

Action

Performed By

1

Configure your Load Balancer to point to a maintenance page, by draining and taking the AppsAnywhere rules offline (if not already done).

Customer

2

Disable the new AppsAnywhere servers.

Software2

3

Restore the backup of the AppsAnywhere Database.

Customer or Software2

4

Re-enable pre-existing AppsAnywhere server services.

Software2

5

Configure your Load Balancer, restoring rules for your pre-existing servers (and removing any rules for the new servers if applicable).

Customer


SERVICE RESTORED

Retiring Old Servers

Software2 recommend that you retain the database backup and pre-existing AppsAnywhere servers (e.g. as a backup or powered down) for 2 days following an upgrade.

In the unlikely event that a critical issue arises, you then have the option to rollback, or to investigate the previous service state.

Assuming there are no issues, you can then retire your old servers and delete previous backups.