skip to main content

Tech specs and info

Technical info
Software2 Community Forum

Our community

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

Visit

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.

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 Software2 Support. We'll work with you to schedule any changes and ensure your transition is made securely and with minimal service interruption.


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

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 Technical FAQs

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.

What are the technical requirements for AppsAnywhere?

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

Where are AppsAnywhere servers located?

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.

Can the servers for AppsAnywhere be cloud-based?

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

What backend is needed to deploy AppsAnywhere?

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.

Can you use a virtual server with AppsAnywhere?

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

Can you save work locally in AppsAnywhere?

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!

How does AppsAnywhere integrate with AD?

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.

What effect does launching AppsAnywhere have on the network?

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.

How often do you upgrade AppsAnywhere?

We regularly update AppsAnywhere with new features, most of which are driven and suggested by Software2’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.

What web browsers are supported by AppsAnywhere?

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.

Can our university brand AppsAnywhere to make it look like our own?

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


Key use cases and solutions