Overview

AppsAnywhere provides your end-users with easy access to their software applications by integrating a variety of new and existing app delivery methods.

As software delivery is generally a business critical service, it is important that your service is resilient, both in terms of redundancy and security.

In addition, when using Cloudpaging to deliver Windows apps, end-user devices will require ongoing access to AppsAnywhere to validate and record usage.

Your end-users will also need to access your AppsAnywhere Portal both on and off-site, from any location.

We recommend that you make your AppsAnywhere servers private, and configure a load balancer with health checks to act as the gateway for all external (and internal) traffic.

The following information is covered within this page:

Load Balancing

In order to ensure service continuity during upgrades (and in case of server outage), a load balancer with health checks is required.

All connections to AppsAnywhere should be made via the load balanced address, which will be the service URL that you advertise.

As the AppsAnywhere name and logo appears throughout the user experience and in all Software2 provided documentation, we recommend that you adopt the format:

  • https://appsanywhere.uni.edu

Configuration

It is the customer's responsibility to select and configure a suitable hardware or software load balancer.

If you do not have an existing load balancing solution, Software2 can advise on solutions in use by other customers.

Please setup your load balancer as follows:

  • Redirection should be configured so that http traffic is redirected to https
  • Forward all web traffic to your AppsAnywhere server on port 443.
  • Configure service health checks every 30 seconds.
  • Ensure that session persistence is enabled. IP persistence is recommended.
  • Redirection must preserve the URI.

Optional: If your load balancer supports SSL offloading then this functionality can be used.  If you wish to use SSL offloading, then complete the following additional steps:

  • Apply an SSL certificate to your load balancer.
  • Terminate SSL on the load balancer
  • Forward traffic to the backend servers over HTTPS/443

In order for kerberos based SSO to function correctly traffic to the AppsAnywhere servers from the load balancer must be forwarded over HTTPS/443, even if SSL offloading is configured.

Service Health Checks

The following health check URL is available for AppsAnywhere servers:

Service

AppsAnywhere

Health Check URL

https://<serverFQDN>/healthcheck

Success Response

OK

Failure Response

All other responses

Additional configuration may be required depending on the load balancer used. Please refer to your vendor for support.

Once you are live with AppsAnywhere, do not add additional servers to your load balancer until instructed to do so by Software2. Adding new servers before Software2 configuration will likely cause an outage.

Software2 Remote Access

Software2 will require SSH access to your virtual appliance in order to complete the initial configuration, and to provide you with ongoing support.

You may chose only to permit SSH access over your VPN connection, to provide access via one of your Windows servers, or provision a Test Machine which can act as a jump host.

We recommend that you configure your network and firewall rules to only permit SSH from the necessary IP addresses or IP ranges.

For security reasons, SSH access is disabled by default in the virtual appliance.

Once the necessary firewall rules are in place, you will also need to Configure SSH Access via the Appliance Configuration Console.

Connectivity Requirements (Firewall Rules)

You will need to ensure that your network and firewalls are configured to permit the required traffic to and from your AppsAnywhere servers.

The following tables detail the connectivity required, grouped according to the origin of the network traffic. All traffic will be bi-directional.

Internal Destinations should be amended to match your internal servers and services.

You do not need to configure any firewall rules on the AppsAnywhere server itself, as the virtual appliance is preconfigured with the required firewall rules.

Inbound Traffic (Internal and External)

SourcesInternal DestinationPortUsage
Client Devicesappsanywhere01.uni.edu443 TCPUser access to AppsAnywhere (e.g. via your load balancer)
Jump Hostappsanywhere01.uni.edu22 TCPSoftware2 SSH access for administration (usually via a Windows jump host)
AppsAnywhereappsanywhere01.uni.edu80 TCPTransfer of AppsAnywhere Client installers from other internal AppsAnywhere servers

Outbound Traffic (Internal)

SourcesInternal DestinationPortUsage
AppsAnywhereMSSQL.uni.edu1433 TCPConnection to your SQL database
AppsAnywhereMSSQL.uni.edu1434 UDPConnection to your SQL database
AppsAnywhereAD.uni.edu636 TCPConnection via LDAPS to your Active Directory
AppsAnywhereAD.uni.edu88 UDPConnection via Kerberos to your Active Directory
AppsAnywhereappsanywhere02.uni.edu80 TCPTransfer of AppsAnywhere Client installers to other internal AppsAnywhere servers
AppsAnywherecloudpaging.uni.edu443 TCPConnection to your Cloudpaging service (if applicable)
AppsAnywhereparallels.uni.edu443 TCPConnection to your Parallels service (if applicable)
AppsAnywhereanalytics.uni.edu19999 TCPConnection to your Analytics Appliance (if applicable)
AppsAnywheremyfileshare.uni.edu445 TCPAppsAnywhere Service access to the Secure Download UNC path

Outbound Traffic (External)

SourcePortUsage
AppsAnywhere123 UDPCentOS (Chrony) Time Service
AppsAnywhere80 TCPSoftware2 Icon Library and CentOS updates
AppsAnywhere443 TCPSoftware2 APIs, libraries and CentOS updates
AppsAnywhere587 TCPEmail alerts via SMTP

External Destinations

Optionally, you may wish to apply more specific firewall rules for outbound connections from your AppsAnywhere server(s).

The following table provides details of all the outbound destinations that AppsAnywhere requires access to during normal operation.

SourceExternal DestinationPortUsage
AppsAnywhere0.centos.pool.ntp.org123 UDPCentOS Time Service
AppsAnywhere1.centos.pool.ntp.org123 UDPCentOS Time Service
AppsAnywhere2.centos.pool.ntp.org123 UDPCentOS Time Service
AppsAnywhere3.centos.pool.ntp.org123 UDPCentOS Time Service
AppsAnywhereapi.appsanywhere.com80 TCP

Software2 Icon Library

AppsAnywhereapi.software2.com443 TCPAppsAnywhere Server Registration
AppsAnywhereb12228822d08f4925072-e23aef5ecad0f6168507017a4f5869f1.ssl.cf3.rackcdn.com443 TCPSoftware2 Icon Library
AppsAnywheremirrorlist.centos.org80 TCPCentOS Update Repository
AppsAnywherecdn.remirepo.net80 TCPCentOS Update Repository
AppsAnywheremirrors.fedoraproject.org443 TCPCentOS Update Repository
AppsAnywhererpms.remirepo.net443 TCPCentOS Update Repository
AppsAnywherepackages.microsoft.com443 TCPCentOS Update Repository

AppsAnywhere

rpm.nodesource.com ADDED 2.11

443 TCPNode.js Update Repository
AppsAnywhereappsanywhereresources.blob.core.windows.net443 TCPAppliance Configuration Console
AppsAnywhere1bdb4cc9b0722bc205a377fabbc4511a62a47f7610ad5c7c4e62.ssl.cf3.rackcdn.com443 TCPSoftware2 Client Management
AppsAnywhere

*.s2public.blob.core.windows.net

443 TCPSoftware2 Client Management
AppsAnywheresoftware2-public.azureedge.net443 TCPSoftware2 Patch Management
AppsAnywhereajax.googleapis.com443 TCPjQuery & Google Fonts
AppsAnywheregithub.com443 TCPOther Software2 Libraries
AppsAnywheresmtp.sendgrid.net587 TCPEmail alerts via SMTP

Software2 Support

During the initial deployment of AppsAnywhere, Software2 will provide full details of all required firewall rules for inter-server communications with other components such as Numecent Cloudpaging and AppAnywhere Analytics.

If you would like us to provide further advice, or details of all required firewall rules for your existing AppsAnywhere infrastructure, please contact Support2 Support.