We know how crucial it is that your staff and students have continuous access to their applications. When designing the infrastructure that will run your services, we make the following recommendations for high availability.

In order to add a level of resilience and to share the workload it is necessary to load balance particular parts of the services that span multiple servers.

  • Provision a minimum of 2 servers for each service, or 3 servers for each service with a site license 

  • Ideally, these servers should sit in a high-availability server environment across multiple hypervisor hosts and data centers (where possible)

  • Use a redundant, high availability Microsoft SQL Server environment to host the database(s)

  • Use a third party load balancer (hardware or software), with a single DNS address for each service.

The only exception is the Cloudpaging Paging service.  This service does not require the use of a third party load balancer.  When a connection attempt is made by the Client (Cloudpaging Player), it will run a connection test on all known Paging services and use the one with the best connection results, regardless of the server locations.

Parallels provide a load balancer appliance for use with RAS (only).  This can be used if required and no other preferred solution is available.  However as mentioned this is only compatible with the Parallels RAS application/software only.  It cannot be used to load balancer the AppsAnywhere or Cloudpaging servers.


The following configuration templates and guides are available:

  1. Citrix Netscaler / ADC

  2. HAProxy

If you require further information or your load balancer is not listed above, the information below contains details of the required configuration.

Default Configuration

The following default configuration is required:

  1. A load balanced DNS record should be created (e.g. https://demo.appsanywhere.com)

    1. So, rather than pointing to one specific server to access the service, we point to the load balanced DNS which shares the load between servers.

    2. The load balancer should use equal weighting so all servers used

  2. Service health checks should be performed (every 30 seconds)

    1. Using the provided service health check URLs

    2. This is necessary as opposed to checking the server IP to determine whether or not the service is active. The server could be running while the service is not

  3. Persistence needs to be set so that the load balancer persists the session you have established on a server rather than opening a new session on another server

    1. We recommend a minimum 30 minute IP persistence

  4. Redirection should be setup so that http traffic is redirected to https

  5. Redirection should preserve the URI

  6. X-Forwarded-For should be enabled so the client IP is presented to AppsAnywhere

SSL Offloading

By default, we will apply certificates to AppsAnywhere, Cloudpaging and Parallels RAS Gateway servers where applicable.

SSL offloading can be used if you wish to manage the SSL certificate for the service via the load balancer. 

All traffic sent to the backend servers from the load balancer MUST be over HTTPS/443. 

AppsAnywhere uses Kerberos (Windows Integrated Authentication) to sign in the user automatically via the Windows Pass Through Single Sign On authentication method.  If the Kerberos request is modified by the decryption of the traffic and transmission over HTTP, it will invalidate the request and prevent the user from being signed in automatically.

Health checks

To ensure the load balancer can check the health of the backend servers, the following health check URL's are available:

  • AppsAnywhere: https://<Server_FQDN>/healthcheck
    Success message:


  • Cloudpaging Admin/License: https://<Server_FQDN>/jukeboxserver/do/license/token/renew.tok?msid=ping
    Success message:
    Token service is ready.

  • Parallels RAS Gateway: https://<Server_FQDN>/RASHTML5Gateway
    Success response:
    HTTP 200 (the portal page loads)

For legacy customers using the Cloudpaging Enterprise Portal:

  • Enterprise Portal:  https://<Server_FQDN>/jukeboxdrm/ping.do
    Success message:
    Enterprise service is ready.

Although load balancing is not required for the Cloudpaging paging service, you can use the following health check URL to monitor the service on each server if required:

  • Paging Service: http://<Server_FQDN>/jukeboxserver/stream/client.do?msid=ping
    Success message:
    Stream service is ready.

The response format for all health check URLs will be a HTTP response, e.g

  • HTTP 200 = Success

  • HTTP 403 = Forbidden

  • HTTP 500 = Internal Server Error

  • HTTP 503 = Unavailable

  • HTTP 303 = Redirected

If the server is down or offline a timeout will be returned.

Additional Considerations

In some situations we have seen that additional configuration is required for particular load balancers. 

Any additional considerations or configurations for load balancers that are listed in the templates section are included within the specific template documentation.