General Settings

Overview

The General Settings page brings together all of the most basic settings that are required to for AppsAnywhere to work and to customize the user experience. It is important to understand what each of the settings in this section mean as they will all impact on the user experience.

This article is split up to explain each section of the Settings > General Settings page in turn

Required Settings

When AppsAnywhere is first installed, you will need to visit the General Settings page to ensure that the most basic settings are specified so that AppsAnywhere can operate. Most notable is the Base URL setting, without which you will find that validations will constantly fail. The following settings are required:

• Base URL

• Default Location

• Admin Email Address(es)

Setup

The setup section of the general settings page includes settings related to the core functionality of the system.

Base URL

The Base URL should be set to the top level, externally facing URL of the AppsAnywhere environment. It is used by the AppsAnywhere client for all requests that have to be sent by AppsAnywhere so ensure that the address entered here is accessible from every device that will be using AppsAnywhere.

• If you have multiple AppsAnywhere servers then this should be set to the load balanced address for those servers.

• If you have a single AppsAnywhere server then this should be the fully qualified domain name for that server. 

Make sure you include the protocol at the beginning (https). 

If the base URL is changed by a system administrator, there could be a service interruption.

It is recommended to verify with AppsAnywhere Support that there will be no impact to making the change.

Web Proxy Address

To standardise the implementation and consumption of proxy configuration across all aspects of the appliance this setting has been moved to the Appliance Configuration Console (ACC). Documentation of the proxy configuration options are detailed on the Configure Proxy Settings page.

Use X-Forwarded-For to Obtain Client IP?

In order to determine the geographical location of a user, AppsAnywhere looks at the IP address from which the request originated, which it then either matches to an internal IP range or looks up in the GeoIP database to determine a location. If you are using a load balancer in front of your AppsAnywhere server(s) then quite often AppsAnywhere only ever sees the requests as originating from the load balancer's IP address. If this is the case then you will see everyone accessing AppsAnywhere being considered to be on-site and in the country defined as the 'Default Location' (see below), regardless of where the system is being accessed from. 

To get around this, you need to configure your load balancer to pass through the true originating IP address of the request in the X-Forwarded-For header and check this setting to instruct AppsAnywhere to use that information when determining a user's location.

Customisation

The customisation section of the general settings page includes settings to tailor the AppsAnywhere look and feel.

Site Title

The Site Title alters the HTML <title> attribute for the AppsAnywhere site which determines what is displayed as the tab title in the browser as shown in the example below.

We recommend keeping the title short enough to fit in the standard tab width. 

Hide Short Domain Prefix

The short domain prefix appears beside the username on the login screen. If you don’t want users to see this information, or it’s not relevant to them, you can hide it.

Behaviour

The behaviour section of the general settings page incorporates settings related to the user experience and workflow.

Enable automatic validation

The Auto-Validate setting determines whether or not validation occurs by default as soon as a user logs into AppsAnywhere. If this option is un-ticked then the user will be presented with a popup when launching an app that requires validation, and they do not have to complete validation unless they want to launch apps that require it. 

Automatic validation shows the in-progress and success states below. Hovering over the in-progress ‘orb’ shows a description of what is occurring, unless the user is retrying validation, at which point the text will always be shown while validation is in progress.

Disabling automatic validation is most useful for users that do not make any services available on anything other than managed devices, as in these scenarios validation may not ever be required. If there are no restrictions on any apps available to the user then they will not even be prompted to complete validation.

Enable EULA(s) For Managed/Lab URL?

Determines whether or not the EULA is displayed if the user logs into AppsAnywhere using the /labs URL.

Use Cloudpaging License Warnings

By default, all operating system compatibility is displayed within AppsAnywhere. However, Cloudpaging does have the ability to warn users if an app is considered incompatible or untested on their device via the Cloudpaging Player. By selecting the "Use Cloudpaging License Warnings" check box, AppsAnywhere will update all associated Cloudpaging licenses with the defined app compatibility, meaning Cloudpaging will warn the user of any potential issues.

Manual Login 2.12+

There are two methods of logging in to AppsAnywhere, single sign-on (SSO) and manual login using a username and password. This setting controls the visibility of the username and password login form when single sign-on methods are available.

There are three possible values, the behaviour of each option is explained below.

Show

When set to show the username and password login form will be visible to users when navigating to the /login route and the user will be able to log in with a username and password.

Hide

When set to hide the username and password login form will not be visible to users when navigating to the /login route, except in the case where the URL parameter allow_manual_sign_in is set to true. The user will be able to log in with a username and password when this parameter is present and set to true, however will not otherwise be able to.

To set the URL parameter allow_manual_sign_in to true you must append ?allow_manual_sign_in=true to the end of the URL, as shown in the following example.

https://appsanywhere.myuniversity.org/login?allow_manual_sign_in=true

Hide and Disable

When set to hide and disable the username and password login form will not be visible to users when navigating to the /login route and they will not be able to log in with a username and password under any circumstances, including when the URL parameter allow_manual_sign_in is set to true.

Default to "Apps" on the Portal home screen 3.1+

A default “Apps” option has been added to try to provide some option that should always contain apps, which is particularly useful for new users. If this option is selected, then the “Apps” option will be the default for new users.

However, depending on your setup, you may wish to default to your first app collection, which happens if this option is disabled.

NOTE We will always select the app collection a user last selected at as a priority, so this option applies to new users, or new devices.

Client install suppression

By default, AppsAnywhere has to ask every new user whether or not they have the AppsAnywhere client installed. This is done using the welcome dialog with the two buttons (blue and green) which ask if the user has already used AppsAnywhere before on this device. A better way of detecting the AppsAnywhere Client will be included in a future release but, for now at least, we have to ask. AppsAnywhere also displays banners on the bottom page if it suspects that a user may not have accepted a security prompt when a message is sent to the AppsAnywhere client (during validation or app launch). 

In a managed environment, you are probably able to guarantee that the AppsAnywhere client is installed and these popups are not just superfluous, but annoying and potentially confusing for the user. 

If this is the case then you can use the "Suppress Client Checks and Launch Prompts" check box to stop these messages being displayed on any device that meets one or both of the following criteria:

1. AppsAnywhere considers the device to be on-site, as defined by the Local IPv4 CIDR Addresses defined earlier in this section.

2. The user has logged in via SSO, which AppsAnywhere assumes would only be possible on a managed device. 

There is also an additional box where you can define CIDR exceptions to this rule. This is intended for IP ranges that cover your VPN or WiFi connections, where users would be considered on-site but are most likely on un-managed devices which still might not have the AppsAnywhere client installed. In the "IPv4 CIDR Addresses to Exclude From Suppression" box, enter a semi-colon separated list of IP ranges you wish to exclude from the message suppression (i.e. you still want the messages to be shown).

These functions will be suppressed under the following scenarios if the settings are activated.

After Windows Pass-Through Auth

If a user logs in with Kerberos single sign on.

When Accessed Through Managed /Labs URL

If a user logs in via the /labs url e.g. https://appsanywhere.com/labs

When On-Site

If a user logs in and is defined as being on site from their IP address.

IPv4 CIDR Addresses to Exclude From On-Site Suppression

There is also an additional box where you can define CIDR exceptions to this rule. This is intended for IP ranges that cover your VPN or WiFi connections, where users would be considered on-site but are most likely on un-managed devices which still might not have the AppsAnywhere client installed. In the "IPv4 CIDR Addresses to Exclude From Suppression" box, enter a semi-colon separated list of IP ranges you wish to exclude from the message suppression (i.e. you still want the messages to be shown).

Location

As described briefly above, AppsAnywhere uses the IP address from which the request originated (from the server's perspective) to determine the location of the end user. If they are outside of the institution's network then this will be seen as a public IP and a geographical location for that IP will be found from the GeoIP database. If the request comes from within the institution then the IP address seen by AppsAnywhere will be a local one and therefore not registered in the GeoIP database. 

The location section of the general settings page allows you to configure what AppsAnywhere considers to be on-site devices and the geographical location that should be assigned to these devices. Describing these settings is simpler if you consider them the other way around.

Default Language

The Default Language value specifies which language AppsAnywhere should use.

Default Location

Whenever AppsAnywhere determines a user to be on-site, it will need to know which geographical region to use when applying region restrictions as it will not be able to determine this from a local IP address as it will not exist in the GeoIP database. 

The Default Location value specifies which location AppsAnywhere should use when it encounters an on-site IP address.

Local IPv4 CIDR Addresses

For AppsAnywhere to properly determine which of your devices should be considered to be "on-site", CIDR notations need to be added to define the internal network range of IP addresses. 

For example, if the CIDR 10.0.0.0/24 is configured, any request AppsAnywhere receives from devices with IP address in the range 10.0.0.0 to 10.0.0.255, will be considered on site.

Multiple CIDR ranges are defined by separating them with semi-colons but typically, the most top-level network range should suffice. 

For more info on CIDR notation, see https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Online tools can be used to calculate the CIDRs required e.g. https://www.ipaddressguide.com/cidr

Administration

The administration section of the general settings page includes settings relating to AppsAnywhere administrators.

Remove Audit Records After...

The AppsAnywhere audit records will automatically be removed if they are older than the time defined.

Admin Email Addresses

The admin e-mail address will be sent all expiration notifications related to both applications and provisions. We recommend entering a group e-mail address so that no single person has responsibility for ensuring applications do not expire. 

Expiry emails are sent for: