Common Delivery Method Settings
General Overview
The settings explained in this article apply to every delivery method that you add to your application, regardless of what type of delivery method it is. These settings define the underlying behavior of the delivery method and help determine whether or not it can be used on a particular end device.
Read the Prioritizing delivery methods article to understand a little bit more about how AppsAnywhere uses these settings to determine exactly which delivery method to use at any one time.
Basic Settings
Display Name
All delivery methods can be assigned a display name to make it easier for you, as the administrator, to identify the delivery method in future. This is purely a name for your benefit, it is only used within the admin interface (whenever delivery methods are listed) and is not used in any user-facing element of the system.
You do not need to enter a display name. If you choose not to enter a display name, AppsAnywhere will use a summary of what we consider to be identifying details for the particular delivery method, depending on what type it is. For example, for External Website delivery methods, we will just show the URL if no display name is provided.
If you wish to enter a display name, choose something that will help you identify the particular delivery method when it comes to reordering delivery methods, defining Cloudpaging upgrades or generating shortcuts, as a few examples.
Launch Button Text
For each individual delivery method, you have the ability to choose what text you want to use on the launch button. The default text typically relates to the type of delivery method you are creating, for example, the default for the External Website delivery method is "Visit Website", whereas for the majority of other delivery methods, the default text is just "Launch". However, with the addition of more flexible delivery methods, the verb you might want to use might be different to the default provided by the system, as the action being completed might be more suited to the launch button saying "Execute", "Install" or "Visit AppStore". You may also want to customize the launch button text if you are using the Offer Multiple Delivery Methods option and have multiple delivery methods of the same type (and therefore, with the same launch button text).
You do not need to specify launch button text for each delivery method you create. If you choose not to enter custom launch button text then the default will be used, depending on the type of delivery method you are creating.
If you do need to enter custom launch button text for your delivery method, choose something that is clear and concise so the user understands exactly what will happen when they click the button, otherwise they may be hesitant to do so.
Due to the type of font used in the front-end interface (i.e. not mono-spaced), it's impossible for us to set a character limit on the launch button text as if you were to use only 'W's, you can only fit 9 characters in, but you can fit in over 16 characters, depending on what you are writing. We also chose not to truncate your text as we thought that wouldn't look very good for the user.
So, beware that you do have the ability to distort the launch buttons if you put in too much text. Always go back and check how the launch button looks whenever you add custom launch button text and if it doesn't fit, choose a different word or phrase to use.
Operating System Compatibility
The most basic restrictions that you would place on any individual delivery method is the operating systems that it is compatible with. Some delivery methods (such as External Websites) are available on every type of device whereas others (such as Cloudpaging) are limited to specific types of devices by their nature. For example, the Cloudpaging delivery method is only available to Windows devices, similarly the RemoteApp delivery method is only available on operating systems that can facilitate an RDP connection (Windows, OSX and most Android devices).
Whenever you add a new delivery method, you have the option to specify, at a very granular level, which operating systems it can be used on with. You can also, very simply, choose to support all of the operating systems compatible with that delivery method.
The range of operating systems shown in the 'Operating System Compatibility' section will depend on the type of delivery method you are adding. For example, if you are adding a Cloudpaging delivery method, you will only be able to select compatibilities from the various Windows operating systems, however, when adding an External Website delivery method, you will have the full list of operating systems supported by AppsAnywhere to choose from, as all of these operating systems are capable of sending the user to a website.
Specifying Operating System Compatibility
When adding a new delivery method (see Adding delivery methods), you will see the Operating System Compatibility pane on the far right hand side.
As you can see from the picture above, by default, the delivery method is set to be compatible with all operating systems (or at least those supported by that type of delivery method).
Expanded Compatibility View:  | If you wish to restrict the delivery method to only work on a subset of the available operating systems, then toggle the button next to the OS Support label to Configure You will then see the main operating systems that are supported. You can change the toggle buttons for each operating system between All and None to allow or deny use on that particular operating system, or toggle any of them to Configure again to further drill down into the specific versions that you might want to specify support for. As in the example on the left for Windows 7, for many operating systems you can drill down a further level to specify whether to support the 32-bit or 64-bit version of each operating system (for those that have both), by selecting the dropdown icon next to the toggle buttons. Selecting the Untested toggle button for any operating system, version or architecture will warn the user when they launch an application on that type of device that it has not been tested in that environment, even though you expect it to work without issue. As you define each delivery method, think carefully about the types of devices you want it to run on and try and ensure you have some form of delivery method in your list to support each type of device. |
Examples
The example above shows (most of) the available operating systems for an External Website delivery method. Imagine you were adding a link to the iOS appstore as an external website delivery method. Here you would want to set the Operating System Compatibility to None for everything other than iOS. If you then added another delivery method that linked to a URL in the Google Play Store, you would set the Operating System Compatibility to None for everything other than Android on that delivery method.
As another example, imagine you have a Cloudpaging application that has to have a different package for 32-bit and 64-bit machines. You could add two Cloudpaging delivery methods to your application in AppsAnywhere and the user wouldn't need to know the application was delivered by different packages depending on their environment. Simply link the first delivery method to the 32-bit package and set the Operating System Compatibility to All for each of the 32-bit versions of Windows and None for all of the 64-bit versions of Windows. Then do the reverse for the second delivery method, link this to the 64-bit package and set the Operating System Compatibility to All for each of the 64-bit versions of Windows and None for all of the 32-bit versions of Windows. Now you have one application, one launch button which launches the relevant Cloudpaging package for the end user's device.
Restrictions
The restrictions panel (at the bottom of the middle panel when adding or editing a delivery method) contains a few more settings that can be used to further restrict how and when a particular delivery method is used. The restrictions below allow you to handle some of the more complex user scenarios for your application delivery and ensure you provide the maximum coverage possible while still remaining within the terms of your software licensing restrictions.
The restrictions panel shown here contains five settings that allow you further to restrict use of the delivery method; Mappings, Device Type, Device Ownership, On-Domain and On-Site, which are all described below.
To use SAML attribute mappings, an additional update to your AppsAnywhere servers is required
Mappings
The Mappings setting allows you to restrict availability of the particular delivery method to users or devices that are linked to specific Directory records, either directly or through membership, or by SAML Attributes.
When enforcing this restriction, AppsAnywhere will look at both the user entity and the device entity and match them to the specified mappings. This means you could restrict a particular delivery method to a mapping group that contains a specific set of devices and only have it available on devices that are a member of that group, but equally you could restrict it to a mapping group that contains a specific set of users and only they will have access to the delivery method, regardless of where they log in.
This restriction can be used in conjunction with other delivery methods accordingly prioritised to provide a specifically licensed version of your app to machines in a lab environment but a differently licensed version to everyone else.
This can also be used to provide offline access to a Cloudpaged application to specific users (staff, for example) and not others.
If you wish to restrict access to a particular delivery method in this way then you must first ensure that the directory records or SAML attributes you wish to restrict by have been imported into the system. Take a look at the Importing directory entities and Creating SAML Attribute Mappings pages for more information if you have not done this already.
Directory
Directory mappings can simply be selected using the dropdown menu as shown, you may pick as many records as you wish to give access to based on the restrictions required. If you chose this option initially but wish to swap, you can use the Re-select button at the bottom of the restriction area.
If you select more than one directory record in the list, the resources will be available to anyone who matches (or whose device matches) against ANY of those records specified.
Attribute
Attribute mappings can be much more complex, but allow for complete control of delivery methods through SAML attributes (see Creating SAML Attribute Mappings for more information). From the image above you can see multiple mappings in place, these can be added and removed as required and are built by the attributes selected in the dropdown menus. The logic behind these mappings is that all attributes within a single set must be satisfied in order to have access to the delivery method.
Using the example above, a user might require Attribute 1 and Attribute 2 to gain access, or just Attribute 4. A user would be denied access if they only had Attribute 1 and Attribute 3.
If you chose this option initially but wish to swap, you can use the Re-select button at the bottom of the restriction area.
Device Type
The Device Type setting allows you to restrict availability of a particular delivery method to users specifically accessing AppsAnywhere from a laptop.
This restriction utilizes the AppsAnywhere Client to inspect the available power settings of the user's device (for Windows Devices), or the defined device type (for Apple Mac) and report back to the system whether the device has been determined to be a laptop or otherwise. This allows you as the administrator to restrict access to delivery methods that may be intended only for fixed, and not mobile, devices. Where delivery methods come with specific options (such as the offline availability option for Cloudpaging), it also enables you to provide the same delivery method with different options for laptops.
If you wish to restrict a delivery method to only be available on laptop devices, change the Device Type setting to the Laptop Only option. Otherwise, leave this value set to All.
Device Ownership (Bring Your Own Device)
The Device Ownership setting allows you to specify whether or not users will be allowed to use the particular delivery method on their own machine.
In order to use this setting, you will need to deploy a registry key to all of your institution-owned/managed machines so that it can be identified by the AppsAnywhere client during validation. Any device that isn't marked as institution owned in this way will be considered as a user-owned device.
Leave this setting set to All if the delivery method can be used on any device (including user-owned devices). If your license specifies that the application (delivered in this way) can only be used on institution-owned/managed machines, then change the dropdown to Institution-Owned Only. Additionally, you might also set this setting to Institution-Owned Only if you simply don't want this delivery method to be used on user-owned machines if, for example, it's an installation package tailored specifically for your own devices. If you have another delivery method that is restricted to Institution-Owned Only devices, then the User-Owned Only restriction comes in useful for providing an alternative delivery method for everyone that isn't on a device owned by the institution.
For more information about deploying the registry keys required to make use of this setting, refer to the AppsAnywhere Policy Template article
On-Domain
Limitations of on-domain detection
On-domain detection is currently only supported for devices that are AD joined and an LDAP connection is configured with a matching domain.
On-domain detection is not currently supported for Entra joined devices or when SAML is used for authentication/authorization with no configured LDAP connection, including AppsAnywhere Cloud.
The On-Domain settings allows you to specify whether or not the device that the user is using must be joined to your institution's domain.
In this context, AppsAnywhere will be checking that the device is joined to the specific domain that granted the user access to the application, as defined in the provision for the application. For example, if you provisioned an application to the group 'Engineering Students' in your CAMPUS domain, then enforcing on-domain would ensure that this delivery method could only be used on devices joined to the CAMPUS domain.
Leave this setting as Do Not Enforce if the delivery method can be used on devices that are not joined to the domain. If you license specifies that the application (delivered in this way) can only be used on domain-joined/managed devices, then change the dropdown to Enforced. Additionally, you might also set this setting to Enforced if the application package you are delivering will only work on domain joined devices, perhaps if, for example, those are the only devices you know to have a vital pre-requisite installed.
On-Site
The On-Site setting allows you to specify whether or not users will be allowed to use the particular delivery method outside of your institution's network.
By default, AppsAnywhere uses the IP address of the user's device in order to determine whether or not they are considered on-site. As the AppsAnywhere servers are hosted within your network, when AppsAnywhere looks at the source IP for the request sent to the server, if the user is on-site then it will see a local IP address (an IP address within the range of your local network). If however the user is outside of your network, AppsAnywhere will see a public IP as the source of the request and will therefore determine them to be off-site. There are some factors to consider when using this setting:
In order for this setting to work, you will need to define the IP ranges (via CIDRs) that your local network ranges. See Managing Settings for more information on getting this configured.
The load balancer must be configured to pass client IP addresses to the AppsAnywhere servers. See Use X-Forwarded-For to Obtain Client IP under General Settings.
You should carefully consider which IP ranges you define as 'on site'. Whether or not you include IP ranges given to VPN users, or those in on-site residences may be determined by your software licenses.
As with the BYOD setting, this setting can be overridden by deploying a registry key to any device that you wish to be considered as on-site, but doesn't sit within your defined network range.
Leave this setting as Do Not Enforce if the delivery method can be used on devices that are located outside of your institution. If your license specifies that the application (delivered in this way) can only be used within the physical bounds of your institution, then change the dropdown to Enforce. Additionally, you might also set this setting to Enforce if you simply don't want this delivery method to be used off site, for instance if you do not want users at home making use of your internal resources or services.
For more information about deploying the registry keys required to make use of this setting, refer to the AppsAnywhere Policy Template article
Examples
The additional restriction settings allow for very fine control of your specific use cases.
Imagine you have an application that is available for delivery by Cloudpaging and through a VDI/RemoteApp solution. Using the settings described above you could permit users to access that application natively using Cloudpaging on their own device as long as they bring it into one of your on-site labs. This allows you to offer native performance on BYOD machines even if your software license only permits that application to be launched within the physical bounds of your institution. For users who aren't on-site, you could allow AppsAnywhere to fall back to the next best delivery method, the VDI solution, so that users can still access the application but your license terms remain enforced.
Another example may be that a specific application can only be used on domain joined machines, but those machines can be anywhere in the world, as long as they remain connected to the domain. You can restrict the preferred delivery method to On-Domain - Enforced, but provide a secondary "fall back" delivery method that provides the user with a download of a differently licensed version of the application, or an external website link to the vendor's student access sign-up page.