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

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 Software2 Support that there will be no impact to making the change.

Web Proxy Address

If your servers use a proxy to access the internet then you should enter the proxy address here. AppsAnywhere requires access to the internet to obtain versioning information from the Software2 central API when you use the Client Settings page and again to download any new client installers as and when you choose to update them.

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.

Behaviour

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

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)

Auto Validate

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 banner at the top of the page to indicate that validation is required to launch certain apps but they do not have to complete validation unless they want to launch apps that require it. 

In addition, any apps that do require validation will have an action button that triggers validation in place of the usual launch button until validation is completed, as shown below: 

This setting is most useful for users that do not make any services available on anything other than managed devices. 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. 

Disable All User Tutorials?

This setting will disable AppsAnywhere Tutorials.

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. 

Customisation

The customization 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 from the Software2 demo site.

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

Default Layout

The default layout allows you to select the layout in which you would like the apps displayed in the portal. This can be an option of list, Large or Standard view. 

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.

Client Check, Tutorial and Popup Suppression (Suppress All Popups and Prompts...)

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