Troubleshooting Support Guide for AppsAnywhere

PDF Version

Click the link below to download a PDF version of this page.

• Troubleshooting Support Guide for AppsAnywhere.pdf

Who is this document for?

This document is aimed as a one-stop-go-to guide for new customers and those inducting new service desk colleagues on the day-to-day issues that end users may encounter when using AppsAnywhere.

It pulls together and links back to articles on the more extensive http://docs.appsanywhere.com documentation site, which is publicly accessible.

It may and may also link to knowledge base articles, which due to the information they may contain are behind a registration screen via http://support.appsanywhere.com . If you require access, then please ask your AppsAnywhere administrators to request an account.

AppsAnywhere - What is it?

AppsAnywhere is a web-based portal designed to ensure users receive applications in the most efficient way for their specific device.

These applications are presented in a simple app-store type interface via a secure logon, and allows you to specify which users can see which applications based on several device based environmental restrictions (device, location, BYOD/Managed device, RAM etc.)

The applications presented via the portal are effectively containers, which may host several delivery methods

These delivery methods range in scope from a simple URL link to open a webpage or a file, launching a physically installed local application to launching a virtualised Windows application (Cloudpaging) or launching a remote session via different Connectors such as Parallels RAS, Azure Virtual Desktop or Amazon AppStream.

The user is presented with the best delivery method based on the restrictions and choices you make when defining the application and are based on a number of environmentmental factors relating to the end users device, gathered during the logon process.

It is this logon process and the presentation of the applications that will be detailed further in this guide.

Accessing AppsAnywhere

The process follows two main steps: authentication and validation. Both are initiated by accessing the AppsAnywhere portal page, or in many cases via single sign-on (SSO) via that page

1. User Authentication

   • The user logs into AppsAnywhere using their credentials, or pass through via SSO

   • The AppsAnywhere portal presents all apps the user is provisioned access to.

2. Device Validation (MacOS and Windows)

   • AppsAnywhere client analyzes the user’s current device specifications.

   • This step helps determine the best delivery method available for each provisioned application, ensuring compatibility and performance.

   • If there are no suitable delivery methods, an app will show as Unavailable.

     

   • When a user launches an app, AppsAnywhere delivers the application using the most suitable method for the user’s device. Common delivery methods include:

     • Locally Installed Windows or Mac applications.

     • Downloads.

     • External Websites.

     • Cloudpaging, Windows app virtualization for Windows devices.

     • Hosted virtualized environments such as Appstream, Frame, Parallels RAS, VMWare Horizon, or our own managed Cloud Delivery.

Details on this process can be found here:

• AppsAnywhere Process and Data flow

By automating this process, AppsAnywhere ensures seamless access to applications while optimizing performance across different device types.

Troubleshooting

The key to troubleshooting issues in AppsAnywhere is to identify at which step they originate. The most common issues encountered in AppsAnywhere can be categorized as:

1. Login Issues

2. Validation Issues

3. Access to Applications Issues

4. Delivery Method Issues

Here are some terms this documentation references that can affect the errors you might see, or the troubleshooting steps you engage in:

• Cloud-Hosted – This refers to our Standard Deployment Model where the AppsAnywhere infrastructure is hosted by us using Azure Cloud services.

• Self-Hosted – Legacy & Limited Use - customer hosts the infrastructure on-premise and is responsible for all aspects of server, network and database infrrastructure.

• BYOD (Bring Your Own Device) - end user personal devices

• Managed Devices - organisation owned devices, typically domain joined.

• App Admin – Admins with rights to import users and provision applications

• Systm Admin – Admins with rights to system settings in addition to app admin permissions

• SAML - our default method of granting user access to AppsAnywhere. By using industry standard Security Assertion Markup Language 2.0 (SAML) access can be granted securely and can be easily configured to work in most environments.

• IdP - By levarging your existing Identity Provider (IdP) using SAML your users are validated according to your security standards (MFA etc) using a common interface that they are accustomed to.

Login Issues

There are two primary authentication methods for AppsAnywhere.

1. LDAPS (Active Directory, Open LDAP). The common authentication method for self-hosted AppsAnywhere environments.

SAML can also be added to selft-hosted installations to improve the logon and single sign-on process.

2. SAML (Entra, Shibboleth, CAS, Okta, etc.). SAML is the only recommended authentication method

If you are using AppsAnywhere via our cloud hosted package, then the only supported login method is SAML

Forbidden page after logging in

Issue Text

Forbidden

You are not authorized to access this page.

Please contact your local web administrator for assistance.

→ Back to login

Root Cause

User authenticated successfully, but they are not included in a Directory Mapping.

Steps to Troubleshoot and Resolve

1. Ensure the user is imported. This process is different depending on your environment’s authentication method.

   1. LDAPS: https://docs.appsanywhere.com/appsanywhere/3.2/importing-directory-entities

   2. SAML: https://docs.appsanywhere.com/appsanywhere/3.2/creating-saml-attribute-mappings

User arrives back at the AppsAnywhere Login page after logging in via SAML

Root Cause

There are required fields in AppsAnywhere’s SSO Settings that don’t match the claim sent by the IdP. An AppsAnywhere system admin will want to confirm that the attribute names and certificate listed in the AppsAnywhere SSO Settings match what the IdP is sending.

As the SAML intergration is a key component to AppsAnywhere access to the settings and configuration are limited to those support staff who have been granted System Admin rights in AppsAnywhere, however all users are able to use the troubleshotting tips to check what is being sent in the SAML response file.

Steps to Troubleshoot and Resolve

1. You can still use a SAML trace extension to capture the response from the IdP sent to AppsAnywhere after login.

   1. Many SAML tracer extensions exist for all browsers. Here is an example: SAML, WS-Federation and OAuth 2.0 tracer - Microsoft Edge Addons

2. If you have system admin level permissions in AppsAnywhere, compare the output in the Attribute and Certificate sections of the SAML trace with the data in AppsAnywhere’s SSO Settings. Otherwise, send the SAML trace to a system admin who can check those settings.

• Documentation: SAML 2.0 Common

Active Directory or OpenLDAP Login Error

If an individual user is unable to logon, then basic checks of username and password, or account lockout should be undertaken.

If multiple or all user are having issues then your internal AppsAnywhere admins.

As the AD login uses a service account, this account would be the first place to check to see if this was locked out.

If the password has changed/expired then they will need to escalate this directly with AppsAnywhere via https://support.appsanywhere.com

• Documentation: LDAP Connection Details

Validation Issues

After login, the AppsAnywhere portal attempts to validate a user’s device to gather information. This is done via the AppsAnywhere Client (MacOS & Windows).

The AppsAnywhere client gathers information from the end user device and is used to determine which delivery method to provide for each application the user has access to.

Validation involves the AppsAnywhere client running on the user’s device and sending the output to the AppsAnywhere portal. A detailed breakdown of the validation process can be viewed here:

• AppsAnywhere Process and Data flow - User Validation

If validation fails, a Validation Troubleshooter will appear to help guide the user through common causes.

Troubleshooting Step 1: Security Prompts

The first step in validation troubleshooting is ensuring the user approves the security prompt from the browser. Retry validation and make sure they click “Open”.

Troubleshooting Step 2: Client Installation

The next step is ensuring the AppsAnywhere client is installed on their machine. If it is not, the user can click the “The client isn’t installed” button and get a download of the AppsAnywhere client installer to run on their device.

This download can also be accessed from the user profile menu.

If validation still isn’t working, it’s worth uninstalling the AppsAnywhere client on the user’s device and installing it new.

Still Not Working?

If you are not able to resolve then this should initially be escalated within your organisations IT department, and if necessary, then with AppsAnywhere support.

In all cases, it is essential than the full client log files are included, as detailed in the next section.

Collecting Log Files

The AppsAnywhere client can be used to easily collate all necessary log files from the client device. These will include logs and event viewer files for the AppsAnywhere and Cloudpaging Player clients, as well as logs for any 3rd party Intergrations that may be configured in AppsAnywhere, such as Parallels, Citrix, Vmware Horizon.

AppsAnywhere

The simplest way to collect the AppsAnywhere log is via the AppsAnywhere system tray icon detailed above.

If manually collecting the log file, then the default location is:

C:\Users\<user>\AppData\Local\Software2\AppsAnywhere\Log\S2HubTracelog.log

Cloudpaging 

The Cloudpaging player log can be viewed directly from the Cloudpaging Player via File → Options menu, then selecting the Logs tab.

The default location of the log file is

C:\ProgramData\Endeavors Technologies\StreamingCore\Log\StreamingCore.log

Third Party Client Logs

If your institution is using Citrix, Parallels or other third party connectors, then these will have their ownn specific log files. More details can be found in our article:

• AppsAnywhere Log Files – AppsAnywhere Support ^{(registration needed)}

Again, the easiest way to collect these is via the AppsAnywhere system tray icon, which will gather all available logs and Event Viewer logs.

Escalation

If you need to escalate a issue, both internally with your own helpdesk, or to the AppsAnywhere support team, we do advise collecting the full support bundle and including in any escalation ticket, and not copy the one or two lines withing the log file that may highlight an issue.

Access to Applications Issues

Access Issue: User Cannot Find Their App

Users can only see applications in AppsAnywhere if they are granted access via an AppsAnywhere Provision.

1. Add the user to a provision that includes the app in question. Most often this is done by adding them to a group already provisioned to access that app, but they can also be added individually to a provision.

2. Have the user log out and log back in. They should now see their application.

• Documentation: AppsAnywhere Provisioning

Access Issue: Unavailable Applications

An application shows unavailable for a user when they are permitted access to that application via a provision, but there is no way to deliver the app to them.

Most of the time, this is due to the application having no delivery methods which support them or their machine. There is one scenario when a non-delivery method setting could cause an application to become unavailable.

Delivery Method settings that can cause an Unavailable Application

The user’s device failed to meet any set delivery method restrictions.

• Documentation on Restrictions:

  

The delivery method does not support the user’s operating system.

• Documentation on Operating System Compatibility:

The delivery method has a Mapping defined which doesn’t include the user.

• Documentation on Delivery Method Mappings

The device does not meet the delivery method’s hardware requirements.

• Documentation on Hardware Profiles:

• There are no settings limiting access to the user or their device, but the delivery method(s) themselves do not support their device. See the Delivery Method Troubleshooting section below for details.

Other reasons for an unavailable Application

Restrictions are a key component in configuring AppsAnywhere, and this article explains the range various method by which access to an application or an individual delivery method can be granted or restricited.

Delivery Method Launch Issues

Locally Installed Issues

AppsAnywhere can detect locally installed apps on Windows or MacOS.

If an app is not detected as locally installed by the AppsAnywhere client, it will be due to the information set in the Locally Installed delivery method for the app in AppsAnywhere not matching the app installed on the machine.

• Documentation: Locally Installed Delivery Method

If you lack admin permissions in AppsAnywhere and need to escalate to someone who does, here is the useful information to gather from the user’s machine for the app in question:

Windows

Mac

Cloudpaging Issues

The best place to start troubleshooting Cloudpaging issues is to first determine if the app ever gets to the “Running” state in the player.

Running

A Cloudpaged app that gets to the “Running” status in the player has launched with no issues from the Cloudpaging point of view. The player will display the status as “Running”.

Flashing icon when the app is paging

Not Running

Sometimes the app doesn’t virtualize in the Cloudpaging Player at all. In this case, the AppsAnywhere client will display a Launch Error.

Normal icon

Cloudpaging Issue: Application takes a very long time to Launch

This can happen if the Player is taking a very long time to get the data it needs from the server. This can happen for two primary reasons:

1. “Noise” in the Cloudpaging Package. Noise refers to unnecessary assets in a Cloudpaging package. If an appset has a large amount of noise, it can interfere with the data the Player needs to run the app and can impact the time it takes to get that data.

   If the appset was packaged outside of our packaging service, it’s worth inspecting the appset for any noise or other ways to make it more efficient.

If you suspect that the application is deploying assets or includes ‘noise’ that are causing issues, and the appset has been created internally by your instuitution, then this will need to be referred back to your colleagues responsible for creating the appset.

If the appset is pre-packaged by AppsAnywhere, then that same team should validate your findings, and then if necessary refer back to AppsAnywhere support

For larger and more complex applications then Pre-caching can be used to bring the data closer to managed machines to speed up the first-time launch of applications.

• Documentation: How to Configure and Use Pre-caching on Managed Devices – AppsAnywhere Support ^{registration required}

Cloudpaging Issue: AppsAnywhere Client Launch Error

Sometimes an app doesn’t launch in the Cloudpaging Player at all. In this case, the AppsAnywhere client will display a Launch Error.

Troubleshooting Steps

First, check the client log files. The Cloudpaging Player log can be found at

• C:\ProgramData\Endeavors Technologies\StreamingCore\Log\StreamingCore.log

Example: Paging Servers Unavailable

• StreamingCore.log

So the above is displaying issues getting a response from the Paging servers (which deliver the appset to the end users Cloudpaging Player (lines 29,31,40, 43, 50 & 52) which eventually forces the error trying to deliver (lines 54,55,56)

Cloudpaging Issue: App stops running or is removed from the player after launching

This can happen if the Cloudpaging session for the app is expired. Common reasons an app session is expired include:

1. AppsAnywhere admin manually expired the session via the Cloudpaging Session settings.

2. An update has been applied by an AppsAnywhere admin, so the application will remove itself from the player, before launching the new version

3. There was a technical error renewing the Cloudpaging session.

   • This will happen if there’s any issues renewing the Cloudpaging session. Normally, the Cloudpaging Player checks in with the server post launch and every 5 minutes to ensure the user’s Cloudpaging session for that app is still active.

     • Documentation on Load Balancer Configuration: Load Balancer Configuration

4. The Cloudpaging Player was unable to check in with the Cloudpaging server. Usually this happens when the machine loses internet access, but it can also happen when an app that was allowed offline for a certain number of days has surpassed the number of allowed offline days.

Cloudpaging Issue: App showing errors while running

If an app launches in the player but does not perform how you would expect, it indicates a packaging issue with that application.

In this case, the Audacity appset is missing a key file (for e.g. a dll) it needs to run. Common situations like this can include:

• Missing application prerequisites such as c++ redistributables

• Missing or incompatible version of .Net

• Misconfigured service or driver

This must be resolved by investigating and fixing the appset. Helpful information to escalate to a packager who can then compare to a machine where the appset works includes:

• Specific app error message / image

• Operating system and architecture

• Installed C++ Redistributable

• .NET version

• Other installed applications

• Event viewer application logs

Even though the application is a virtualized Cloudpaging application, it is still a Windows application launching and interacting with a Windows desktop device.
So normal troubleshooting and research avenues you would normally take to investigate software issues are still valid.

• Vendor documentation

• Windows updates know issues

• Application/Vendor community groups

External Website or Direct Download Issues

Both of these delivery methods work by launching the url set in the delivery method settings in a new browser tab on the user’s machine.

Make sure the URL works by launching it outside of AppsAnywhere.

• Documentation:

  • External Website Delivery Method

  • Direct Download Delivery Method

Secure Download Issues

This delivery method works by having the AppsAnywhere servers host a file. When a user clicks the Launch button, the AppsAnywhere portal delivers the app to them as a download.

For Secure Downloads to work the user must be logged into AppsAnywhere and validated by the AppsAnywhere client. As a result this method is only available for MacOS and Windows users.

• Documentation: Secure Download Delivery Method

Troubleshooting Step 1: Verify the local file path

The first thing to check is to make sure the local file path in the Secure Download delivery method settings is correct. Because the download is hosted on Linux AppsAnywhere servers, the path should always be:

/var/www/appsanywhere/secure/<application.msi>

where <application.msi> is the file you’ve uploaded to the Secure Downloads file share.

Troubleshooting Step 2: Verify the file in the Secure Downloads share

This step will look different depending on if your AppsAnywhere environment is self-hosted or cloud hosted.

Self-Hosted

In self-hosted environments, the institution has a file share set up that the AppsAnywhere servers can access. Make sure the file exists in that folder.

Cloud-Hosted

In cloud-hosted environments, we provide access to the Secure Downloads share via the Azure Storage Explorer which you can use to verify the app.

• Documentation: Uploading Apps to AppsAnywhere Cloud

Troubleshooting Step 3: Escalate to Support

If the file still isn’t downloading, there may be an issue in the communication between the AppsAnywhere servers and the Secure Downloads share. At this point, it is best to escalate to AppsAnywhere support to identify what the issue is.

Other Delivery Method Launch Issues

If you have any other delivery methods not launching correctly or encounter a situation not outlined in this guide, the best steps are to check the documentation for that delivery method at:

• Delivery methods

Afterwards if you cannot solve the issue, proceed to collect client log files and escalate to support.