AppsAnywhere Cloud Deployment Guide

Introduction

This article details the information that AppsAnywhere will gather as part of the implementation process to configure a new AppsAnywhere instance.

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 AppsAnywhere infrastructure, it is required that you create the following CNAME records in your DNS.

The documentation below uses generic placeholders and an Implementation Consultant will provide the following fields.

• <customer.domain>

• <customer.code>

• <azure.region>

AppsAnywhere

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

This address will need to resolvable both internally and externally.

You will also need to provide a valid SSL certificate for the portal address.

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 certificate for this address as by default all the package data is encrypted.

Pre-Caching on a Network File Share

Whilst the vast majority of Cloudpaged applications are paged directly from the hosted paging servers in Azure, pre-caching is required for optimal performance with larger, more complex applications.

Further information is available on the following documentation.

• How to configure and use pre-caching on managed devices.

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 Single Sign-On Settings and 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)

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

• 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.

Within AppsAnywhere, levels of access are granted via Roles. Details of the available roles are available on User Roles and Permissions.