Debugging APM CE (CEM) Unspecified User Problems

Document ID : KB000032827
Last Modified Date : 14/02/2018
Show Technical Document Details

    Summary: 

   There are various reasons that APM CE (CEM) may not capture an authenticated user id in a monitored transaction. This can result in an unspecified user. Reasons 

   for this happening and what to do about it are discussed below

 

    Instructions:

 

     1. What is the Unspecified User Problem?

 

 

     The unspecified user message typically looks like shown below:

     Unspecified User.jpg

 

     While displaying "login name" or "user group" in a defect list, an unspecified user(s) appears instead of the actual user name.

 

    Having an unspecified user has the following disadvantages:

1)     It hinders resolving an issue because the person who logged in is unknown.

2)     Statistics for a particular user may be incomplete or misleading due to unspecified users.

 

   An important note: There are various times when receiving an unspecified user message may be the expected result. An example is an e-commerce

   website has no login process.

 

   2. Guiding Principles

1)     When working on unspecified user issues, start with the possible easier use case to find causes (such as those associated with authentication type and session identifier) and work towards the more complicated ones (such as network-related.)

2)     Unless it is a case as listed above, most transactions will contain a login name and user group. So, unspecified users should be the exception rather than the rule.

3)     There should only be one unidentified user per defect.

4)     Only Unspecified Users and User Group Request Headers are the typical two user groups for e-commerce reports unless using certain types of user identifiers.

 

  Typical Causes

   The following are typical causes of unspecified users:

 

 

Cause

Reason Why

How to Fix

Easy/Hard to Detect

Session Identifier Issues

Invalid or missing session identifier means APM cannot differentiate user sessions and identify users. This also impacts the binding of the various transaction hierarchy elements.

-Correct text/case in session identifier.

- Add or use another session identifier.

- If no session cookie is available, then add a port number. (Such as for NTLM Authentication.)

Easy

Application Type Issues

Incorrect application type impacts the type of session identifier used. See session identifier for reasons why this is happening

-Choose correct application type (such as Siebel instead of general)

Easy

Authentication Type Issues

Authentication type impacts the type of session identifier used. See session identifier for reasons why this is happening

- Choose correct authentication type. (such as NTLM instead of Basic)

Easy

Before Login

If a defect happens in the login process, before the user is logged in, there will be no user identification

Turn off defect specifications before login or set expectations there will be no users for pre-login defects.

Easy-Moderate

Session Timeout Issues

The user is at a remote location that needs a longer period of time for a session timeout.

Or session timeout is shorter than time needed to login/for a session.

Increase session timeout. (60 minutes by default).

 

Moderate.

Redirect to External URL

Users are authenticated are initially seen but an external redirect link is clicked.

 

Once clicked, you can see the transaction but lose the user to session information

Increase session timeout.

 

Use an internal link

 

This may be in the application/network realm and may not be possible to solve.

Hard