search cancel

Debugging APM CE (CEM) Unspecified User Problems


Article ID: 32827


Updated On:


CA Application Performance Management Agent (APM / Wily / Introscope) INTROSCOPE


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

     1. What is the Unspecified User Problem?

     The unspecified user message typically looks like the image shown below:


     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.



APM 10.x


Typical Causes

   The following are typical causes of unspecified users:


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.)


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)


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)


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.


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).



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.