In this article, we present the recommended best practive for deploying the AppsAnywhere Client to managed devices.

In this article

Also in this section

There are no sub-sections to this page



Overview

The AppsAnywhere Client is required for all users who will be launching applications from AppsAnywhere on a Mac or Windows device. The client can be pre-installed by a system administrator, or installed upon first use by the end-user (as long as they have administrative rights).

Additionally, in order to launch applications using an integrated delivery method such as Cloudpaging, the relevant third party client e.g Cloudpaging Player must also be installed. If the AppsAnywhere Client is installed and detects that Cloudpaging Player is not, then it will facilitate the installation of the Cloudpaging Player on the user's behalf using the Administrative privileges that it retains (via the installed system service) from when it was first installed.

On un-managed machines, users will be able to install the AppsAnywhere client using an account on their device that has Administrative privileges and everything else will be managed for them from that point on, including the installation of any required third party clients e.g. Cloudpaging Player, and future updates to those clients and the AppsAnywhere client itself.

On managed machines, users will typically not have Administrative privileges, so a system administrator will need to ensure that the AppsAnywhere client is installed for them. In this article, we will detail the recommended best practice for managing the AppsAnywhere client installation on your managed estate, which basically falls into two categories. The approach you choose will entirely depend on how strictly you want to manage deployments of clients on your devices. 

Fully Managed Update Process

Even though the AppsAnywhere client has the ability to keep itself and Cloudpaging Player up to date, we expect that most of our customers will want to continue fully managing the deployment of these components using traditional deployment options such as Group Policy or SCCM and will subsequently want to disable all of the self-update functionality in AppsAnywhere altogether. 

When taking this approach, there are four things to consider:
  1. Deploy the AppsAnywhere Policy Template recommended settings
  2. Deploy Cloudpaging Player
  3. Deploy AppsAnywhere Client
  4. Create an upgrade plan


Note:If a user visits AppsAnywhere and does not have the minimum client versions as specified in Client Settings, they will still be installed or updated.

Deploy the AppsAnywhere Policy Template recommended settings

There are a number of areas where the behavior of the AppsAnywhere client can be modified on the target device. Take a look at the AppsAnywhere Policy Template and deploy the recommended settings.


Disable Automatic Updates

In order to stop the AppsAnywhere client upgrading itself or any third party clients, the following registry key will need to be deployed to managed machines by using the AppsAnywhere Policy Template.

Windows

Key: HKLM\SOFTWARE\Software2\DisableUpdateChecks

Key Type: Reg_SZ

Value:

Mac

File: /Library/Preferences/com.software2.appsanywhere.plist

Key: <key>disable-update-checks</key>

Value:<integer>1</integer>


Deploy Cloudpaging Player and AppsAnywhere Client

Download links are provided via the Latest News and Releases section of the Software2 Customer Support portal, which includes MSI and PKG packages.

Download the versions you want to deploy and setup a deployment task using your preferred deployment solution.

You need to ensure that the required clients are pre-installed on all of your managed devices, ready for when someone wishes to use AppsAnywhere.

Recommendations can be found on the Software2 Managed Deployment of AppsAnywhere Client and Cloudpaging Player article.


Create an upgrade plan

As you have chosen to fully manage the deployment of your client versions, you will need to construct a plan for how and when you will upgrade these as newer versions become available. 

Subscribe to the announcements

We strongly recommend that you ensure that at least two people within your organisation are registered with the Software2 Support Site and are following the Release Announcement section in order to receive notifications as and when new versions become available as this is essentially what will trigger the rest of your upgrade process. 

Internal Testing

Once a new version is available, we recommend you set up a local testing environment, or choose a small group of users to receive the new version and test it out in your environment. You should decide what tests need to be completed in order to reassure you that the new version meets the required standards and the time frame for completion of this testing. 

Your testing should probably also include testing the upgrade procedure itself, ideally through the mechanism you intend to use for full roll-out to identify any issues with the roll-out process itself.

Ultimately this process will result in a decision as to whether or not you wish to deploy this new version across the full estate. 

Deployment Schedule

Once you decide to upgrade your estate to a new version, you will need a plan for when you are going to roll it out and how users will receive the new version. Ideally this would be done out of hours so as not to impact the user while the system is being updated. 

Back-out plan

Providing you have followed the recommended steps, constructed a clear plan and tested the process thoroughly, there's little that could go wrong, but it's always best to have a documented back-out plan, just in case. We recommend having a job already set up to uninstall the new version and revert to the one you were using previously. You could even test this on the machines you used to test the new rollout, just to make sure. At least then you know if something does go wrong, you are ready to resolve it in the shortest time possible. 

Rollout

You've considered all possibilities, you've tested as much as possible, you and your test users are happy with the new version, all that is left to do is hit the button!

Confirmation

If you have the ability to monitor the results of the roll-out process using a tool like Nexthink, run a query to ensure that your devices were able to successfully install and are now running the new version. 

Using Automatic Update On-Site

Unlike the automatic update features in most software products, AppsAnywhere does actually allow Administrators to very closely control which versions of each component are pushed out to their devices and, perhaps more importantly, when, even when using automatic updates. 

Built into the update manager in the AppsAnywhere client is a call to Software2's central versioning API (api.software2.com). Each time the update process runs, AppsAnywhere contacts this API to see which versions of each component are available and it uses this information to determine whether or not an upgrade is required.

Each AppsAnywhere customer has a unique Institution ID which is generated when AppsAnywhere is installed. Each time a user logs into AppsAnywhere and validates their session, that Institution ID is saved into their local registry under HTLM\SOFTWARE\Software2. 

Useful Tip

If you have version 2.1 or later of AppsAnywhere, you can find your Institution ID by going to the About page in the admin section of AppsAnywhere

Once a user has validated on a particular device, the AppsAnywhere updater can then use that Institution ID when talking to the versioning API and receive a tailored response specific to that given institution as to which versions are "available".

If you don't want to fully manage your own deployments and are happy for the AppsAnywhere client to manage updates for you, then you can leave automatic updates enabled and simple let us know which versions you want it to install and as new versions become available, when you want us to roll them out to your devices. 

There is only one caveat to this feature that you must be aware of. When the user downloads the client and installs it through AppsAnywhere, or when they validate their device, the Institution ID gets set for that device. If however you are deploying the AppsAnywhere client initially through group policy or SCCM (for example) then your Institution ID will not yet be set the first time it launches and therefore the latest version of all components will be installed, regardless of your preference.

For this reason, we strongly recommend that you deploy your Institution ID to any managed machines that you are deploying the AppsAnywhere client to. To do this, simply add the following registry key alongside the client deployment job:

Key: HKLM\SOFTWARE\Software2\InstitutionId
Key Type:
 Reg_SZ
Value: Your Institution ID, as shown in the About page of AppsAnywhere




Some other articles you might find useful:


Written By: