Take a look at the technical specifications and information on this page to learn more about what's required to launch apps to your students through AppsAnywhere, on and off campus.

At the bottom of this page you'll also find some frequently asked questions, as well as info on how you can access our Community Forum to share technical tips and tricks. When you become a customer, our tech teams will guide you through the process of getting the following servers and infrastructure setup and correctly configured.

Infrastructure diagrams

Find links below to the infrastructure requirements and technical specifications for AppsAnywhere.

OUR COMMUNITY

For further technical information, join our AppsAnywhere Community forum where customers from across the world of Higher Ed discuss all-things AppsAnywhere.

Server specifications

The following is provided as a general reference. Before you commission any servers our technical team will provide a tailored deployment guide, based on your project requirements. Servers need a minimum Operating System of Windows Server 2012 and the SQL Server should be Microsoft SQL Server 2012 or above.

AppsAnywhere and Analytics servers

CentOS-based virtual appliance

4 vCPU
8GB RAM
32GB free disk space

Cloudpaging admin/license servers

Windows Server 2012 or later

4 vCPU
4GB RAM
100GB free disk space after OS install

Cloudpaging paging servers

Windows Server 2012 or later

4 vCPU
4GB RAM
40GB free after OS install
250GB secondary disk space (to match repository)

Paging servers must be accessible over the Internet. A split DNS is needed so the same FQDN resolves both internally and externally. The free disk space on Cloudpaging Servers (only) should ideally be setup on different drives from the Operating System, but this isn’t a mandatory requirement.

Application repository

An additional file share (network or local to one of the servers) of 250GB disk space is needed to store applications. The size will vary depending on the number and size of the apps deployed.

Caching

When an application from the repository is published, a full copy of the app is cached to each individual Paging server. This is why each of the Paging servers requires secondary disk space.

Database

Microsoft SQL 2012 or later.

Two databases are needed. Installed on a licensed and dedicated Microsoft SQL instance (existing or new). The database servers must meet the Microsoft recommendations.

Active Directory

AppsAnywhere servers require an LDAP connection for end-user access, authentication and management. All Windows servers should be domain joined.

A wide range of additional authentication methods can also be added (for SSO), including Azure, oAuth, SAML and CoSign.

Resiliency

For resilience, servers will need to be duplicated and load balanced when implementing a production service. We recommend splitting across multiple datacenters or sites.

The Paging servers load balance automatically, so only the Admin/License and AppsAnywhere servers require load balancing.

There should also be a failover mechanism for the SQL databases to prevent a single point of failure and any loss of service.


Infrastructure information

By making AppsAnywhere external-facing, students and staff can access their software apps from home, halls of residence, coffee shops or elsewhere via the internet. Control of who, where and how specific apps can be accessed is still administered via AppsAnywhere provisioning and the delivery methods on a per-app basis.

To allow access, administrators need to present certain AppsAnywhere services to users either locally or via the internet. So regardless of whether a user is connecting on campus, via VPN or the internet, they will need the following access:

  1. Access to the AppsAnywhere URL e.g. https://demo.appsanywhere.com, and
  2. Direct access to the Paging Servers on port 80

The AppsAnywhere URL will usually be presented to users via the load balancer rather than a direct connection to the server on port 443. Security is provided in the form of a https connection on port 443. Additionally security is also provided as all connections to AppsAnywhere travel through a firewall and load balancer.

The Paging servers however, require a direct connection to the end-user's client (Cloudpaging Player) on http port 80 (by default). Paging servers need to be published with a single DNS entry that resolves both internally on the network and externally via the internet. The diagrams below show the recommended AppsAnywhere server infrastructure and traffic flow.


Security

Security to AppsAnywhere is provided via the configured load balancer and connections are made via a secure SSL connection.

Paging servers are secured in that they will only respond to valid token requests from the Cloudpaging Player. Additionally, the Cloudpaging packages themselves are encrypted during the Cloudifying process using PKI Certificates and AES Encryption. Cloudpaging Server provides formidable security by using patented anti‐piracy protection and Secure Sockets Layer protocol. The patented technologies of Cloudpaging Server protect paging application code from viral attack and intransit corruption by hackers. 

It's not recommended to run the paging service on a secure port as this will have a negative impact on performance. Cloudpaging is optimized to run on a non‐secure port as individual blocks are encrypted during the Cloudifying process.

If you are considering making your AppsAnywhere installation available externally, please contact AppsAnywhere Support. We'll work with you to schedule any changes and ensure your transition is made securely and with minimal service interruption.


Azure Active Directory compatibility

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. Applications such as Microsoft Office 365 and the Azure portal can use Azure AD for identity management and Single Sign On (SSO). Other, third-party vendors can use this platform too.

AppsAnywhere does this and once you are signed into an Azure AD session you can navigate and SSO across all applications that can authenticate using this method. This is applicable all the way from Office365 to Azure AD compatible VLEs.

AppsAnywhere is fully compatible with Azure Activer Directory to enable Signle Sign On

Frequently asked questions

Here are some of the common questions we get asked about AppsAnywhere, from a technical point of view. If the answer to your question isn't listed here, feel free to check out our Community Forum or contact us for more information.

AppsAnywhere Technical FAQs

AppsAnywhere can be installed on any supported Microsoft Windows OS and there is no minimum specification.

AppsAnywhere servers can be installed on-site (at multiple locations) or on an externally-hosted infrastructure. In addition, the two approaches could be combined to produce a hybrid local/hosted environment.

Of course, AppsAnywhere can be hosted by your favorite cloud provider.

To get the best out of AppsAnywhere, we tailor the infrastructure to meet your IT department’s needs. AppsAnywhere intelligently delivers and virtualizes apps to the end-users, so the backend infrastructure requirements are minimal (unlike VDI!). Most of our customers deliver ALL their apps to ALL their students and staff from just 8 web servers.

Yes. Nearly all our implementations to date run on a virtual infrastructure.

Absolutely! Because apps are delivered and run on the physical end-user device, all work can be saved locally (as you would with any other app). In fact, apps delivered by AppsAnywhere not only have access to all the local drives, they also have access to all locally-connected peripherals such as USB devices and printers, too!

AppsAnywhere uses a service account to read your Active Directory structure. Once the users, groups and machines are imported, we provision apps to these users, groups or machines.

Thanks to the clever way AppsAnywhere virtualizes apps, it doesn’t have a significant impact on your network traffic. Most apps are cached on the end-points, so the majority of network traffic is about user authentication and license management.

We regularly update AppsAnywhere with new features, most of which are driven and suggested by AppsAnywhere’s community of expert university IT staff. As a valued customer you can expect at least three releases each year, conveniently tied into the academic calendar.

AppsAnywhere is guaranteed to work with all the major web browsers, including Internet Explorer, Edge, Firefox, Chrome and Safari. All other browsers that conform to the usual web protocols will work, too.

Absolutely, this is a requirement of all our users. AppsAnywhere is an exciting service provided by your institution. You can choose what to call the service and how to brand it. Our team will help you with all your branding and communications plans.


Find out more about AppsAnywhere

Integrations

Integrations

AppsAnywhere integrates with the software deployment and EdTech tools you already use, including SCCM, VDI, App-V, Jamf, Microsoft and Canvas.


Key use cases and solutions

Enable BYOD

Enable BYOD

Bring Your Own Device (BYOD) is a hot topic in Higher Ed IT, and often a key strategic IT driver. How do you enable a BYOD policy when it comes to delivering software to students on and off campus?

Reduce or right-size VDI

Reduce or right-size VDI

Right-size or enhance your existing Higher Ed desktop virtualization or VDI solution by delivering software apps to any student with AppsAnywhere.