UEM Health Check

Run a UEM Health Check


Make sure that the HTTP headers x-dtPostBody, x-dtHealthCheck, and x-dtAgentId do not get blocked in your environment. The UEM Health Check needs them to work properly.

In the AppMon Client, click Start Center, then click the Select System Profile list box in the Start Center to select the System profile containing the applications to check.

Click Monitoring > UEM Health Check and click the Check your UEM configuration link.

The UEM Health Check dialog box appears validates and the selected application's URLs. An Application URL is valid if it has valid syntax, the page is reachable, and at least one of the application's URI patterns matches the URL.

If an application cannot validate successfully, you can click the application name to check the application's URI patterns, then edit the patterns in the System Profile preferences. See System Profile - Applications for more information.

Basic checks

When you perform a UEM Health Check, AppMon executes a number of basic checks. These do not depend on any application-specific settings, so basic checks are performed even if no applications are selected. AppMon also executes a check when applications are not selected for the UEM Health Check process.

License check

License checks ensure that License checks can fail with the following messages.

  • Volume Expired: If the UEM visits volume expires, you must redeem another voucher or purchase additional volume. See Manage UEM Visits Volume for more information.

  • Volume Exhausted: If the number of page visits in the license is expired, see Volume Expired to redeem or purchase a UEM Volume.

  • No UEM Volume Included in License: To purchase a UEM Volume, see Volume Expired.

  • No License Information Available: If the check does not determine any licensing information, contact support.

  • License State Error: If the license is expired, invalid, not activated, locked to a different machine, or unknown, contact support.

Agent check

This checks the availability of Agent Groups in the System Profile, and the mapping of Agents to Agent Groups (Tiers).

Agent checks can fail with the following messages.

  • Broken Sub-Agents: A sub-Agent reports as broken if configuration problems such as those related to shared memoryexist. Find the reason and details in the Agent logs.

  • No Agent Group / Tier: This occurs when Agent Groups/Tiers are not defined for the System Profile. Click Settings > Edit System Profile and define at least one Agent Group/Tier with a mapping for your Agents. See the Configure Agent Groups section in the Agent Groups page for more information.

  • No Agent Connected: An Agent is not connected to the Agent Group. To resolve the issue:
    • Check the mappings in your Agent Groups and make sure that at least one Agent is connected for each defined application.
    • Make sure that at least one Agent Group has an active and placed User Experience Sensor with at least one Agent connected.

See the Configure Agent Groups section in the Agent Groups page for more information.

Application checks

For each application that you select in the UEM Health Check wizard, AppMon performs the following application-specific checks:

If one of these application-specific checks terminates with an error, AppMon skips all dependent checks.

UEM enabled check

This check makes sure that capturing UEM data from the browser is enabled. The check fails if capturing is enabled only for server-side data, or if capturing is disabled completely. You can adjust capture settings in System Profile settings. In the AppMon Client, click Settings > Edit System Profile > User Experience. Then click the tab for the desired application and adjust the capture settings. See User experience - capture settings to learn how.

Injection check

This check verifies that the JavaScript Agent is injected correctly. Inject the JavaScript Agent into all pages manually or automatically. For automatic injection, a number of options restrict the injection.

Configure JavaScript Agent injection in System Profile preferences > User Experience. To configure for all applications, click the Default application tab and make your configuration settings Under JavaScript Agent. For Individual applications, Select the application specific tab. See System Profile - User Experience > JavaScript Agent for more information.

The JavaScript Agent is correctly injected if the src-attribute of the first script-tag in the HTML response body matches a certain file name pattern.

To Health Check each application, enter a URL. Click Start Center > Monitoring > Check your UEM configuration under UEM Health Check. If you have a web server master Agent, the connected sub-Agent may be from an earlier version and reports a different configuration.

Agent version check

Use this to check the Agent version in the Health Check's web request.

  • Agent(s) Not Up-To-Date: The Agents listed in the UEM Health Check run an earlier version than the AppMon Server and were not updated properly by the bootstrap Agent. Verify that the communication works between the AppMon Server and Agents.

  • The Health Check's HTTP Request Returned an Invalid Response From the Connected Agents: The following are some possible causes.
    • Missing response header which should contain the IDs of the connected Agents. This can happen when one of the connected Agents runs on a version earlier than 5.5.
    • Invalid response header modified by the connected Agents.
    • Agent that is unknown to the AppMon Server. Agent is connected to a different AppMon Server or none at all.

  • Master Agent Unknown or Not Found: One of the connected sub-Agent's master Agent is either not available or unknown to the server.

  • Versions For Sub-Agent and Master-Agent Do Not Match: The master Agent and one of the connected sub-Agents run on different versions. The following are some possible causes.
    • After installing an AppMon Update, the Web Server Agent or the master Agent are not restarted or are unable to retrieve the latest Agent version from the AppMon Server.
    • If you use IIS under Windows Vista, or later, the installation directory C:\Program Files may cause a shared memory problem.

JavaScript Agent delivery

This check verifies that a valid JavaScript Agent is injected into the requested web page.

  • The Agent is not delivered: The Agent URL is not reachable. The may be due to one of the following:

    • The Agent path is not handled by a web server with an installed Agent. A typical case is a Java server with an application that runs in a sub-path such as /app/ but no root application is available. The JavaScript Agent fails when requested from the root path.
    • The Agent path is not handled by the servlet engine itself, but by a custom part of the app server. WebSphere sometimes does that for static content.
    • The Agent path is blocked by a firewall.

    Possible solution: use a custom path to JS agent as instructed in User experience - web application settings.

  • Agent Empty: The Agent URL is reachable but does not return content. Some firewalls or proxy servers return empty content, instead of a 404 HTTP error. Configure your firewall or proxy server to correctly serve the JS Agent URL.

  • Agent is Gzipped But was Requested Uncompressed: This occurs when a web server compresses the content for all requests, although the content was not requested with the Accept-encoding: gzip header enabled. This may be problematic for clients who do not support gzipped content. This can be caused by a servlet filter, an Apache module, or an ISAPI filter that does not respect the Accept-encoding header correctly.

  • Invalid Agent Content: The delivered Agent contains invalid JavaScript content which may trigger JS errors on the injected page and, therefore, is not a valid JS Agent. This can be caused by a Web server returning a default page instead of a HTTP 404 error when a page is not found. Typically, this is because the requests to the JavaScript Agent are not allowed by a firewall, proxy, or the web server.

  • Gzipping is Disabled: Sending JavaScript Agent in a compressed format is deactivated in the UEM Sensor configuration. This leads to more overhead when downloading the JavaScript Agent, but this setting may be necessary to avoid double gzipping of the Agent.

  • Agent not Gzipped Although Requested Compressed: This occurs when the Accept-encoding header is not passed to the Agent. It may not be a problem. It may indicate that gzipping does not work for this application. This may impact performance.

  • Agent is not Gzipped Although Gzip Header is Set: The Agent is requested as gzipped and the respective response header (content-disposition) is set, but the response does not contain gzipped content. There may be a problem in the web server configuration. This occurs when a web server compresses all responses and disregards the Content-disposition response header set to gzip.

Deactivate sending the JavaScript Agent gzipped in the UEM Sensor configuration, as a workaround.

  • JavaScript Agent is Gzipped Twice: The delivered JavaScript Agent is gzipped twice. Contact your system administrator or support.

AppMon monitor request check

This check verifies if the monitor request path is valid. See JavaScript Agent - Configuration for more information.

For the applicable System Profile, select > User Experience > Application Specific Settings tab to configure a JavaScript Agent injection for all applications or for each one separately.

A request is valid when both the http status code and the response body match specific values.

  • The HTTP status must always equal 200 (OK).
  • The response body must match the following pattern with valid status values OK, FL and valid server values Java, Web server:

The following is an example of a valid request:

   HTTP Status: 200
   Response Body: OK(Java)

The AppMon Monitor request check may fail with the following messages:

  • Response Code Invalid: The HTTP request to the Monitor URL returned with an HTTP status code other than 200 (OK). Verify the specified Monitor URL. There may be a firewall that blocks requests to that URL.

  • Response Body Invalid: The HTTP request to the specified Monitor URL was successful but returned with an invalid response body. This may be due to an invalid Monitor URL. The web server redirects to a default error page and has an HTTP status 200 (OK).

  • Request Body Invalid: This error occurs if the Agent cannot read the parameters of the monitor signal request. This may cause a problem with UEM data, such as missing User Action PurePaths. Your firewall may block POST requests, or truncate or encode them. If you're not able to change these settings, select Split large signals inside your application's UEM settings. As a result, the requests are sent with the GET method.

  • Cookie Problem: During the Health Check execution, there is a problem with cookies when you access the Monitor URL. The following are a list of causes:
    • The required AppMon cookie dtCookie cannot be created. This problem is discovered when the Set-Cookie header is not found on the response headers. Verify the cookie policies of your application server or webserver.
    • The found session-cookie is invalid. Update the Agents versions.
    • The cookie's domain is set to an invalid value.

  • Unsafe Cookie Content: The injected application server may have a problem with unsafe cookie content; for example when a cookie contains characters like '<', '>' or '$'. The JavaScript agent is using a cookie named dtSa, which might be available if an action with a redirect happens. It stores information about the previous page, such as the encoded URL. Depending on the characters in that URL, the cookie might contain the previously listed problematic characters. If the monitored application does not include switches between different subdomains, the agent can be configured to use SessionStorage instead of a cookie. For AppMon 6.5.10 and later, the Disable subdomain source action support setting is available in debug mode. Contact support for information on selecting this setting.

Known Problems

Using GZIP compression on server

This occurs when custom or multiple GZIP-filters are installed on the application server. Install one GZIP-filter only or use an application URL which does not use a GZIP-filter.