In EAA, you have a diagnostics console which helps you troubleshoot user application issues application access issues, access control list (ACL), and authorization violation, or network connectivity issues.

To report an issue user opens a support ticket for the IT help desk. Ticket logs username, device ID of EAA Client, URL of the Login Portal (identity provider URL), date, time and problem description. A problem description includes for example the name of the application, the last time the application was accessed when it worked, and the time and date when it stopped working. You can upload relevant information into the user diagnostics page and narrow down the causes for the problem.

Use the User Diagnostics portal

Prerequisites:

• User's support ticket input:

  • For a client-access application issue, you should know the Device ID, EAA Client version, OS of the laptop, last activity on the computer.

  • For a web access application (client-less) you should have the type of browser used to access the application and last activity on the computer.

• User ID.

1. Log in to Enterprise Center.

2. In the Enterprise Center navigation menu, go to Application Access > Reports > User Diagnostics.

   🚧

   Internet Explorer version 11 is not supported.

   Run User diagnostics in other browsers (IE Edge, Chrome, Firefox, or Safari).

3. Enter the user's User ID or Device ID of user's EAA Client.
   Mind uppercase and lowercase characters.
   To debug an access-application issue it's enough to enter User ID.

4. Select the identity provider (IdP) URL.
   You can see all the IdPs for the tenant (they are not dependent on User ID or Device ID).

5. Click the calendar to set a date range (up to seven days) when the problem occurred. Try and narrow time frame to get more accurate data.

6. Click Search.

7. To investigate the issue use the information from the user's ticket and select one or more of tiles:

   • Client-access applications that were accessed on the different EAA Client device IDs appear each on a different tile.

   • Access applications (web, VNC, RDP, SSH) appear all in one tile Clientless activity. It shows the browsers used during the last activity by the user.

   • During the time range selected, if there was no activity for any access-application, tile does not appear.

8. Get the needed information and help from the User diagnostic sections:

• ACCESS. View application requests, application volume (bytes in, bytes out), errors, and application configuration events.

• POLICY. Review any access, authorization policy violations and take actions to fix them.

• NETWORK. Check the connectivity and the status of each network segment, and troubleshoot configuration issues.
  

ACCESS

This section shows all applications accessed by the user in the time period, including both access applications and client-access applications. By default, the applications list is sorted by Requests in the descending order. You can sort them also by Volume or Errors.

• Requests are the total number of times the user tried to access the application in the selected time period using the selected devices.

• Volume is the total MB over the time period.

• Errors are the total number of errors encountered by the user while accessing the application in the selected time period using the selected devices.

The name of the application that appears in the Applications list can be related to the application configuration:

• For a wildcard tunnel client-access application all of the applications within the domain are shown in the Applications list. When you hover over it, you see the Endpoint Host name.

• For an access application (web) and tcp-type client-access application, the External host name appears in the Applications.

You can also filter for the name of the application from the support ticket in the right of the access section.

1. Expand the ACCESS section.

2. Select an application.

3. Click on the application to see the application access chart for the selected time frame. By default, it shows:

   • the distribution of volume (in MB)
   • total requests (hits)
   • denies count (4XX messages)
   • error count (5XX errors)
   • date of the deployment

You can hover over the plot to see the deployed version, admin name, and any comments about the deployment changes. The chart helps correlate any changes in the traffic, requests, denies, errors against the deployment events. In the selected time frame, if the user has not accessed the application during off-peak hours, like night-time, you do not see any data.

3. Click on the application hostname link to navigate to the application configuration page and to update configuration issues, or click View deployment history to go to the deployment history section of the deployment tab within the application configuration. You can revert to older deployments, fix any application configuration issues, and redeploy the application.

POLICY

This section shows all access control list (ACL) violations, authorization violations for all the applications in the selected tiles, and identity provider (IdP) in the selected time range. Authorization violations for the IdP (like accounts locked after too many incorrect logins, MFA errors, invalid credentials). Multiple violations for one application are shown in separate rows.

If there are no violations during the selected time frame, no data is displayed.
Use this section to fix any policy violations to applications or authorization violations using the selected IdP.

1. Expand the POLICY section.

2. Filter it by the IdP name, an application host name, or Fully Qualified Domain Name (FQDN).

3. To fix an ACL violation, click Edit Rules under Actions. ACL rules for the application opens. You can update the ACL and redeploy the application.

To fix the IdP authorization violation, click the Edit Directories for IdP. The IdP configuration opens. You can assign the correct directory to the IdP, update the directory with the correct user, groups, and permissions to fix the authorization issue and redeploy IdP.

NETWORK

Select or search for an application to troubleshoot. A time slider appears with traffic data for the application. Use the forward and backward button to navigate through each data point to see the status, errors, latency, bytes in, bytes out in each of the network segments at that time instant. The different network segments are the user and cloud zone, and the cloud zone and connector. If there is an accelerated service like IP application accelerator, then it's included in the user to cloud zone network segment. If you have multiple connectors for high-availability, they are also shown as separate network segments between the cloud-to-connector, and connector-to-origin app server for each connector.

Use the NETWORK section to fix any network connectivity issues in the different network segments.

1. Expand the NETWORK section.

2. In the Select application to troubleshoot, enter the name of the application or search it.
   An application graph with a time slider appears.

3. Check the data before the time the problem happened and at the time the problem was reported to find any abnormalities. Use the forward and backward buttons to navigate through each data point on the time slider.

Data can be present or absent at a certain time. The square on the time slider summarizes the net status of all the network segments. It is interpreted as follows:

Users access applications more during weekdays, less during evenings and likely there is zero access during weekends (that's why you cannot see any data during this time).

The failed requests aggregate and it is shown as a percentage (a colored dot for each network segment). If there is no activity you do not see any network segments.

Network segment status description table

Examine this information to check the health of the different network segments over different timelines before and after the problem occurred. Any recognizable pattern can be a clue to troubleshoot the issue.

Use cases solved with User diagnostics feedback:

• Debug low or zero bytes for a file-share client-access tunnel application. If you use a client-access tunnel application for file sharing, you see big numbers of bytes in and bytes out when there is data transfer from and to the application. If you notice a low byte in, byte out count in the User to Cloud Zone network segment, it indicates a problem. If you notice zero byte in, byte out count in the User to Cloud Zone network segment, the application might be down. See if the application works natively. If so, contact support.

• Debug high latency for accessing an application when the connector is in a geographically distant location. If you observe that the latency for accessing an application is too high, check the geo location of the connector and select a location close to the cloud zone of the origin server. To reduce the latency, click the Configure Cloud Zone in the User to Cloud Zone network segment. Update the Akamai Cloud Zone in the Location section of your application's general settings, to the closest one to the application. Deploy the application.

Limitations

• The time-slider in the network section aggregates the errors over the time period and status indicator color can be mis-leading.

• For access-applications (web, VNC, RDP, SSH) or classic apps logged in the ACCESS there's no identity provider (IdP) details. That's why applications displayed on the IdP my be fewer than you expect (but all the classic application appear).