Upgrading AppsAnywhere
AppsAnywhere 3.2+
This article describes the new In-place upgrade process which is available for when upgrading from AppsAnywhere 3.1 and above.
For upgrades from older versions please see Upgrading AppsAnywhere (Legacy Upgrade Process).
Overview
AppsAnywhere Appliance Upgrades
New releases of AppsAnywhere can be upgraded to in-place on existing virtual appliances without the need to deploy new VM images.
To complete an AppsAnywhere upgrade, customers need to:
Read the release notes.
Request the upgrade prerequisites from AppsAnywhere Support.
Provide the details of the prerequisites to the AppsAnywhere team and schedule a prerequisite check.
Once the prerequisites check is complete, an upgrade scheduling link will be provided to schedule a maintenance window.
AppsAnywhere Cloud Upgrades
Instances hosted on AppsAnywhere Cloud will be upgraded by AppsAnywhere.
Upgrades will be applied within 6 months of release.
A maintenance window will be scheduled, and AppsAnywhere Support will provide at least 2 weeks' notice in advance of an upgrade being applied.
Cloudpaging and Parallels RAS Server Upgrades
Please note that Cloudpaging and Parallels RAS servers are upgrade in-situ.
Planning an Upgrade Window
An upgrade window will be scheduled once all of the prerequisites have been confirmed.
During the upgrade window your AppsAnywhere service will be temporarily unavailable for a short time.
Unfortunately, this is unavoidable, so AppsAnywhere Support 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 approximately 30 minutes (until the first server in the pool has been upgraded)
The timing of an upgrade usually depends on whether downtime is required and your own institutional policy restrictions or procedural requirements. AppsAnywhere recommend that upgrades are undertaken during a period when usage is at a minimum, to minimize any impact to service users.
Upgrades can be scheduled at any time during AppsAnywhere Support business hours. You can also request that an upgrade take place outside of normal support hours in your region (taking advantage of our support personnel in different time zones) and we will aim to meet your request where staff availability permits.
On-premises upgrade dates cannot be confirmed until we've wrapped up all the necessary prep work and given it the green light from our AppsAnywhere Support team.
Once everything's good to go, we'll share a scheduling link with you. If you try to schedule upgrades before we finish the prep, we might need to reschedule, so it's best to wait until we give the all-clear. Thanks for your understanding!
Pre-upgrade Requirements
This section only applies to customers hosting AppsAnywhere on-premise
Customer Contacts
Most of the upgrade procedure will be carried out by AppsAnywhere 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
Your existing database (and load balancing solution) will continue to be used. The database schema is updated by the AppsAnywhere team during the upgrade window.
Remote Access
AppsAnywhere Support will require remote access to all AppsAnywhere servers for the duration of the upgrade procedure.
Test Machine
To confirm that migration is successful, AppsAnywhere 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
As existing servers will be changed during the upgrade, a backup/snapshot must be taken of:
The AppsAnywhere database
All existing AppsAnywhere Virtual Appliances
Upgrade Procedure
This section only applies to customers hosting AppsAnywhere on-premise
Ahead of the upgrade AppsAnywhere 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 |
2 | Backup or snapshot the AppsAnywhere virtual appliance. | Customer |
3 | Configure your Load Balancer to point to a maintenance page, by draining and taking the AppsAnywhere rules offline. | Customer |
SERVICE DOWNTIME BEGINS | ||
4 | Disable all services on the existing AppsAnywhere servers (the servers must remain online). | AppsAnywhere |
5 | Initiate the upgrade on all existing AppsAnywhere Virtual Appliances, transferring configuration updates between them as required. | AppsAnywhere |
6 | Testing of each upgraded AppsAnywhere Virtual Appliance individually. | AppsAnywhere |
7 | Configure your Load Balancer to restore the AppsAnywhere rules and bring the servers back online. | Customer |
SERVICE DOWNTIME ENDS | ||
8 | Testing of AppsAnywhere via the load balancer, and customer sign-off. | AppsAnywhere 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:
Login (manual and SSO).
Validation and basic portal functions.
Launch of applications (including Cloudpaging and Parallels RAS where applicable).
Access to the admin interface and confirmation of version numbers.
Confirmation that Analytics Dashboards and Explores load
Issues During Upgrade
AppsAnywhere 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.
Review deployment logs for errors
Correct cause of errors where possible
Complete the upgrade procedure
If there is a problem during the upgrade window (and there is insufficient time remaining to investigate), AppsAnywhere Support will discuss this with you and ask for authorization to commence rollback procedures.
Rollback Procedure
This section only applies to customers hosting AppsAnywhere on-premise
There are two main scenarios in which a rollback is advisable:
A significant problem is encountered during the upgrade procedure and the remaining window is unlikely to allow for investigation and resolution.
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. | AppsAnywhere |
3 | Restore to the backup of snapshot taken of the AppsAnywhere Virtual Appliance. | Customer |
3 | Restore the backup of the AppsAnywhere Database. | Customer |
4 | Re-enable pre-existing AppsAnywhere server services. | AppsAnywhere |
5 | Configure your Load Balancer to to restore the AppsAnywhere rules and bring the servers back online. | Customer |
SERVICE RESTORED | ||
Post upgrade
This section only applies to customers hosting AppsAnywhere on-premise
AppsAnywhere recommend that you retain the database backup and all server snapshots taken for at least 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 remove or store these backups inline with your policies and procedures.