Making software available to students/staff off-campus with AppsAnywhere

Make your campus lab software and your academic applications available to access by students and staff off-campus, by setting-up AppsAnywhere for external access.

We've put together this guide for customers looking to enable AppsAnywhere for external access. This gives your students and staff a way to access applications from home via the internet. 

With AppsAnywhere's licensing controls, your university can set who, where and how specific software apps can be accessed. You can also choose the delivery methods for each application, to ensure you can deliver as many of your apps off campus as possible.

Note to customers: Typically, off-site access isn't available to customers who are using AppsAnywhere on a 'device license'. However, throughout the COVID-19 pandemic we're looking to help all customers deliver their apps off campus. Please contact your AppsAnywhere account manager to discuss how we can help at this time.

Planning for off-campus access

The key to succesful off-campus delivery is in the planning phase. This doesn't need to be a complex or time-consuming process, so we've put together three simple steps. We recommend taking these three steps in your approach to making AppsAnywhere available off-site:

1. Review your current apps, provisions and delivery methods to ensure license compliance
2. Notify our suppor team so we can give you a new Cloudpaging license (if required)
3. Make the required infrastructure changes to enable students and staff to access off-site

These simple steps can normally be completed within a day or two.

Adding access restrictions for your apps

If you haven't previously enabled off-campus access, you'll need to quickly review your software titles and provisions to ensure that any license-restricted apps don't all of a sudden become accessible off-site.

At the same time, you might also find it useful to check for any apps that cannot be made available for BYOD. Both of these restrictions are quick and easy to apply to via AppsAnywhere.

Generally, we recommend to apply these restrictions to 'Delivery Methods' rather than 'Provisions'. If a student isn't able to launch software in their present location, they'll still see the app but as unavailable. You can then add further delivery methods, such as web links, to signpost students and staff to where they can get the app.

We recommend the following steps: 

1. Check that your on-site IP ranges have been configured correctly in AppsAnywhere
2. Make a list of any apps that need to be restricted
3. Check each of the Cloudpaging Delivery Methods for those apps, and apply the matching restrictions (e.g. On-Domain or On-site only)
   
4. Optional: add an External Website delivery method* to link users to further information if they cannot access an application off-site or for BYOD. Download links can also be added in a similar way.

*If an app is restricted, but there is an alternative option such as a free student license from the vendor website, you can add a web link so that students are signposted to the right place instead of simply seeing the app as unavailable.

VPN / License Servers

On launch, some apps may need connection to an on-site network license server, as provided by the license vendor. For students and staff to use these apps off-site you'll need to provide a VPN connection.

For simplicity and to avoid the need for a VPN connection, many of our customers use AppsAnywhere's integration with Parallels RAS to deliver these apps off-site. All Parallels RAS installation, setup and support is provided by AppsAnywhere's support teams.

Configuring your AppsAnywhere infrastructure

For students and staff to access AppsAnywhere and launch apps with our application virtualization technology (Cloudpaging), there are two main services that the end-device must be able to connect to, either locally or via the internet.

1. The AppsAnywhere Portal URL e.g. https://demo.appsanywhere.com on port 443
2. The Cloudpaging Paging Servers on port 80

Traffic flow

In order to launch apps, users first connect to AppsAnywhere via the load balanced address in their preferred browser, using HTTPS on port 443.

Should the user launch a Cloudpaged app; in order to allocate a license, internal connections are made from AppsAnywhere to the Cloudpaging Admin/License servers on port 443 (usually also via a load-balanced address). This load balancer and the Cloudpaging Admin/License servers do not need to be externally-accessible.

Once a license is allocated, a secure token is passed from AppsAnywhere to the Cloudpaging Player on the end-user device. This token contains the addresses of the available Paging servers, from which the Player can download the required data to virtualize the app.

Cloudpaging Player first performs a connection test from the end-user device to each of the Paging servers, to determine which server can provide the fastest connection at the present time. In this way load balancing and fault tolerance are acheived automatically.

Finally, to download the pre-encrypted application data to the end-user device, Cloudpaging Player requires a direct connection to the Paging servers, over HTTP on port 80.

AppsAnywhere

All connections to AppsAnywhere are made via the load balancer using TLS on port 443.

You will need to ensure that any certificates applied to your public load balancer or servers are from a Trusted Root Certification Authority. If you are using a self-signed certificate, users on personal devices will see warning messages in-browser when they connect to your AppsAnywhere portal.

Your AppsAnywhere servers, and/or Load Balanced address must be made externally-accessible.

Cloudpaging

All Paging server traffic is direct on port 80. TLS should not be applied.

This is because the paging data that is transmitted by the servers is already AES encrypted during the pre-virtualization and Cloudiification process. Switching to TLS will cause significant performance degradation with no additional benefit, and should be avoided.

Cloudpaging Server also provides formidable security using patented anti‐piracy protection. Connections to Paging servers are secure by design, as the paging servers will only respond to valid token requests from the Cloudpaging Player.

In short, the patented technologies of Cloudpaging Server protect the paging application code from viral attack, and from any in-transit corruption by hackers. Further details can be found in the Cloudpaging Server Admin Guide.

For off-site use, your Paging servers must be made externally-accessible as follows.

Paging Servers

Each individual Paging server needs its own DNS entry that resolves both from the internal network and externally via the internet.

For example, in this existing implementation, someuni.edu have three paging servers configured for internal access only:

In the Cloudpaging Admin console, the values that are set for the Logical IP/DNS are the addresses that  Cloudpaging Player will try to connect to (from the end-user device) in order to 'page' the application data.

To allow external access, the Logical IP/DNS must be reachable by the Player both internally and externally. After reconfiguring for external access the servers may look something like this:

Ensuring continuity of service

Rather than make this change to all Paging servers simlultaneously, we recommend that you first make a subset of the servers externally-accessible.

By moving or re-configuring the Paging servers in two stages, external connections can first be tested without risking a service interruption to existing users.

If Cloudpaging Player (on an end-user device) is unable to reach one or more of the Paging servers, it will simply connect to another available server automatically.

The Paging servers have a built-in health check URL, which you can use to confirm if connections can be made successfully from external networks:

• http://xxx.xxx.xxx.101/jukeboxserver/stream/client.do?msid=ping

If the connection is successful you should receive the following confirmation

• Stream service is ready.

Important: License invalidation warning

The license for your Cloudpaging server infrastructure is restricted to the pre-defined Logical IP/DNS names of your Paging servers and may need to be updated ahead of any changes.

If your Cloudpaging license references *.intranet.someuni.edu or an internal IP address, and you change that value in the Cloudpaging console, those servers will be unavailable and service will be affected.

For this reason, any changes to your infrastructure should be notifed to our support team in a support ticket. We're happy to provide a new license ahead of time if required.

Further considerations

Number of servers

If you are expecting use of AppsAnywhere to increase with the introduction of off-site access, it might be prudent to review the performance of your existing servers and to consider an increase in capacity.

At a basic level, a functional AppsAnywhere and Cloudpaging implementation includes:

• 1 x AppsAnywhere Service
• 1 x Cloudpaging Admin/License Service
• 1 x Paging Service

Each set of three servers can handle 3,000 to 5,000 concurrent users.

So for a site license rollout with 20,000 users, working on 75% concurrency (15,000 concurrent users) we would recommend 3 servers for each service, 9 in total.

Support

If you would like any further advice, or need to request a new Cloudpaging server license, please feel free to contact AppsAnywhere Support for assistance.

We'll work with you to schedule any changes and to ensure a smooth transition to off-campus access for students and staff.

Visit our customer support forum

This article first appeared on our support forum, where you can find additional information and infrastructure diagrams for making AppsAnywhere accessible off-campus to both students and staff.

Read more