AppsAnywhere Cloud Deployment Guide

Introduction

Welcome to your Deployment Guide for AppsAnywhere Cloud.

The aim of this document is to gather the details that AppsAnywhere will need to configure a new AppsAnywhere instance.

This article only applies to AppsAnywhere Cloud deployments.

Contacting AppsAnywhere

If at any stage you cannot find the information you need or have any questions, please reach out via GuideCX or AppsAnywhere Support.

Our dedicated team are also available to help you throughout this process and we can arrange further support calls as needed.

CNAMES

To point your domain name to the cloud-hosted infrastructure, it is required that you create the following CNAME records under your <customer.domain> domain.

The documentation below uses generic placeholders. Your Implementation Consultant should have sent notification of the following fields via GuideCX

• <customer.domain>

• <customer.code>

• <azure.region>

Please contact them if you have not yet received these or require further information.

AppsAnywhere

For your AppsAnywhere portal, please create a CNAME record for portal address that you wish to use.

Your AppsAnywhere portal address will be the how the service is accessed by your student and staff members, so it needs to be a simple to remember address that can be typed, remembered, and bookmarked.

By default, we work on the assumption that the service will be call appsanywhere and this is hosted under you <customer.domain>. This is common for the majority of our customers and helps to ensure documentation and support is simplified as it refers to “AppsAnywhere”

So, for example, if your public domain was, springfield.ac.uk then your portal address would be appsanywhere.springfield.ac.uk

You can of course choose a different service name if required.

This address will need to resolvable both internally and externally.

You will also need to provide a valid SSL certificate for the portal address that you have chosen:

• appsanywhere.<customer.domain>

Our preferred format for receiving certificates is PFX, but we can convert other formats if this is not possible, so please make sure the full certificate, chain, key and password are supplied.

Cloudpaging

For Cloudpaging, even though all the servers are hosted in Azure, to comply with the licensing terms, the Cloudpaging Paging servers also need a <customer. Domain> hosted address.

The Paging servers deliver the application data to the end-user client via the Cloudpaging player, so again this address needs to be resolved both internally and externally.

There is no requirement for any SSL certificates for these addresses as by default all the package data is encrypted.

The number of paging servers will depend on the size of your deployment. Your implementation consultant will advise you of the number of servers for your site.

Pre-Caching on a Network File Share

Whilst for the vast majority of Cloudpaged applications, the normal process would be page them directly from the hosted paging servers in Azure, the Cloudpaging player can be configured at the local level to page from a file hosted on a self-hosted share.

This can be help improve performance in larger, more complex applications so is definitely worth considering.

As this is configured completely by yourselves at a local level, it can be done at anytime by following the article How to configure and use pre-caching on managed devices.

We advise allowing 100GB to support multiple applications, but you can manage this internally and increase/decrease over time if needed.

SAML SSO

A SAML identity provider will be used to provide authenticated access and single sign on (SSO) to the AppsAnywhere instance. 

When setting up your SAML IDP application, your return-to address will be:

• https://appsanywhere.<customer.domain>/sso/saml2/appsanywhere

Please refer to https://docs.appsanywhere.com/appsanywhere/3.2/single-sign-on-settings and https://docs.appsanywhere.com/appsanywhere/3.2/saml-2-0-common documentation for more information.

IDP Metadata

When you create your SAML app, we will require the IDP metadata URL or XML file so we can complete the AppsAnywhere configuration:

SAML Attribute Provisioning information

SAML attributes retrieved when a user authenticates, form the basis of the filtering process used to display which relevant applications have been provisioned to the user. This information is used by AppsAnywhere to know which attribute from the SAML response should be used to retrieve group membership(s)

Attribute checklist

To create and configure user access, SAML User, Displayname and Group attribute names are required:

This information will be used to configure mapping once AppsAnywhere is online by following:

1. https://docs.appsanywhere.com/appsanywhere/creating-saml-attribute-mappings

AppsAnywhere Support Account

For the AppsAnywhere team to install, administer and support AppsAnywhere, an account needs to be created in your directory and associated with the SAML IDP application.

The support account credentials are stored securely internally and only available to AppsAnywhere support staff for the purpose of their jobs.

This account can be a single generic contractor account, but if your security requirements require single named accounts, please let us know, along with any submission/contractor forms, so we can register the appropriate support staff.

Customer accounts

Access to AppsAnywhere is granted via your SAML connection.

Within AppsAnywhere, levels of access are granted via Roles. Details of the available roles are available on https://docs.appsanywhere.com/appsanywhere/user-roles-and-permissions.

Account checklist

We use the values returned in your SAML response to map against the attributes. Commonly these are the USER and GROUP attributes as detailed above in Attribute Checklist

Please provide initial values to allow your Admin team to access AppsAnywhere.

Once you have been granted admin access, you will then be able add your own mappings - https://docs.appsanywhere.com/appsanywhere/3.1/creating-saml-attribute-mappings

Directory user checklist

Handover to AppsAnywhere

Please review the details to ensure all information has been provided to the AppsAnywhere team.

Next steps

1. Provide the details securely and directly in GuideCX.

2. Mark the GuideCX Task as Done

Once AppsAnywhere is ready for handover, a member of the AppsAnywhere team will be in touch.

Kind Regards

AppsAnywhere Implementations