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.
Customer CNAME record | Azure Hosted DNS record | |
---|---|---|
appsanywhere. | > |
|
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.
Customer CNAME record | Azure Hosted DNS record | |
---|---|---|
paging.cpp01. | > |
|
paging.cpp02. | > |
|
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 an on-prem 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:
Property | Value |
IDP Metadata URL or XML file | e.g. https://login.microsoftonline.com/xxxxxxxxx/federationmetadata/2007-06/federationmetadata.xml |
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:
Property | Attribute | Expected Value/Format |
User |
| e.g. user@domain |
Group |
| e.g. 5e581c85-8025-xxxx-a342-xxxxxxxx6fde |
DisplayName |
| e.g John Smith |
This information will be used to configure mapping once AppsAnywhere is online by following:
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.
Username | e.g. appsanywhere@ |
Usage |
|
Password Policy |
|
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
User or Group Attribute Value | Role(s) |
| System Admin |
| App Admin |
| User |
Directory user checklist
Item | Details | Completed |
Credentials or Contractors form provided. | Provided securely |
Handover to AppsAnywhere
Please review the details to ensure all information has been provided to the AppsAnywhere team.
Next steps
Provide the details securely and directly in GuideCX.
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