Site icon Software Test Tips

Micro Focus Diagnostics – Tips and Tricks

Micro Focus Diagnostics Tips and Tricks

Micro Focus Diagnostics helps to quickly isolate and resolve development and production app performance issues by providing code-level visibility at the transaction level.

This post will have the monthly Micro Focus Diagnostics Tips and Tricks which will be a consolidation of various common issues in Micro Focus Diagnostics. Do check out this article for troubleshooting tips and tricks for other tools.

Table of Contents

Micro Focus Diagnostics – Tips and Tricks – Jan 2021

1. Retrieving the samples from the Diagnostics Collector Agent in case there is a failure

It often happens that the users are not able to get the samples from their respective Diagnostic Agent. They have encountered access and permission related problems. And there is an error on the screen, with all of the credentials given below:

2020-01-16 11: 22: 00,426 WARN user admin [shared InfrequentEventScheduler] Failing permissions download from Connection timed out: connect (URL:

2020-01-16 11: 22: 00,426 WARN user admin [shared InfrequentEventScheduler] RerunValidation (Permissions): Unable to contact commander. Keeping Revalidate permissions for user mercury in group probegroup = Default (lastaccess 66938ms ago)

2020-01-16 11: 22: 01,960 WARN useradmin [RangeSocketListener-1] No recent communications with Diagnostics Server ( - not attempting remote user authentication / authorization (remote users will be denied access)

This error can be fixed as well; you just need to follow the steps given below carefully:

  1. You need to navigate to Maintenance, then under that, click on Registrar.
  2. Then you need to click on the Registered components; then, you need to find the Nexus_BD

These steps will guide you to cancel the registration, and you just need to wait for some time so that it can register again to inform metrics one more time. This solution should be effective, and it will solve all the authentication-related errors that occurred before.

It is also recommended that the user checks the proxy server settings that the users can find on the Mediator server. The Mediator server is located in the /etc/ file and, then on the Commander server under the path similar to the /etc/ file.

2. Instructions to tackle the Diagnostics .net Agent ProbeAggregator when it goes out of Java heap size

This issue is experienced when the Diagnostics 9.50 and .net agent 9.50 are installed in the Windows Operating System server 2012 platform. Users encounter this issue when they notice that the .Net agent is unable to collect any of the necessary data.

When the log details are checked, an error says, “java.lang.OutOfMemoryError: Java heap space” on the  ProbeAggregatorJSW.log file the user is currently running on the device. The root cause of this error is the java.lang.OutOfMemoryError factor of the respective file. 

This error can be easily solved manually; the user just needs to follow the steps given below:

  1. Open probeaggregator.cmd, taking the help of the notepad.
  2. Then increase the -Xmx value to a higher one.

For example, it could be two times higher than the previous value or as per the system resources requirement.

3. Details regarding the configuration of the Diagnostic server

Figuring out how to configure the Diagnostic server on your own may seem like a difficult task, but the users can do it with the help of certain guidance. Many users have faced an error in the Performance center Diagnostic scenario page.

It is observed that it usually happens when they are working on the settings icon. The error message that is being displayed is given below:

Unable to configure J2EE/.NET Diagnostics. There may be a configuration problem with the Diagnostics Server

Details specified in the Diagnostics page of the Administration Site.

This error can be fixed, but before that, the user needs to have full information about the product that has been installed and about its version too. As per the application technology you are using, you will have to install a Java or .NET agent.

Along with that, the specific instrument of that application should be obtained too because it will be responsible for sending data to your Diagnostics server. The user needs to make sure that the particular Diagnostics server version is not a lower kind than any of the Diagnostics agents.

4. Removing the Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\

It has often been observed that the Diagnostics server 9.26 Oracle Java JRE 1.8.x / 8.x creates problems while working. The users have some complaints, while they currently have 2 of the Diagnostics servers.

Both are running an older version 9.26, the users want to delete the previous Oracle Java files but are afraid if that would affect the Diagnostics application in any way.

The answer to that query is that removing the previous Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\  files would not affect the Diagnostics application’s functioning. 

Once you have finished removing the Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\ files, you just need to navigate to the Diagnostics server’s embedded JRE.

At the time of the installation, the JRE comes with the Diagnostics server in the embedded form, so deleting Oracle Java JRE 1.8.x / 8.x from C:\Program Files (x86)\ would not be a problem.

5. Viewing the Hikari connection Pool JMX parameters

Users often have problems regarding the Hikari connection Pool JMX parameters, as they cannot view it to inspect it or keep an eye on it. There is also an issue regarding the configuration of the metrics.config file at all times.

It is observed that the team that utilizes the said application needs to monitor the activities of the JMX parameters. While using the Hikari connection pool, the team wants to monitor all of the information related to Hikari, like its object name, class name, and all of the descriptions that come along with it. 

The users also observe that in the metric.config file for the Java agent 9.51 there are some Hikari metrics(these metric.config file lines between the range of 358 and 365) present. You can find the metrics.config file in the Java platform section by the set definitions given below:

P120?Java\ Platform/com.zaxxer.hikari\:name\=dataSource,type\=HikariDataSource,*.MaximumPoolSize = Maximum Pool Size
P120?Java\ Platform/metrics\:name\=HikariPool-1.pool.ConnectionCreation,*.Count = Current Count

6. Fixing the issue when the Diagnostics only collects one server request for Open Text

It often happens that the users have an issue in the server request collection in the Diagnostics. The Diagnostics seem to collect only one server request for the Open Text. The specific server request that it collects is a get() statement. Diagnostics, which is on the Windows Server 2016 standard.

Users already have installed the .NET agent that comes along with the Diagnostics 9.50 generally. The OpenText server is responsible for running the Windows Server 2012 R2.OpenText usually uses IIS to deliver content.

The user is recommended to utilize the custom instrumentation initially for safety purposes. In the beginning, we could run on the Diagnostics server 9.4x, or we can also navigate to the suitable .dll files that are applicable. This is necessary to establish a secure platform for monitoring as per the requirement of Diagnostics.

In order to instrument the Java side, the user needs to use the Java agent. Then they need to carefully check the documentation and remain updated about it so that they can instrument the JVM with ease.

It is necessary for acquiring more detailed information regarding OpenText. It is also important that their support/R&D are directly contacted in order to obtain the documentation or some direct instruction that points to the major .NET DLL(s) that needs to be instrumented.

7. Specification of Multiple JBoss targets possible and providing support for Java Agent Scripts

Users often have queries regarding the multiple target specification for Diagnostics Java Agent installations for Tomcat or JBoss monitoring, if it is supported for Java Agent Scripts or not.

They have observed that at the addition of the specific configuration lines for JBoss, it puts special characters in it, and the manual is seen to have only the UNIX/Linux items that are mixed with the Windows variables, like $JAVA_HOME vs. %JAVA_HOME%.

It is observed that it is copying and pasting this same information, basically just results in the special characters being inserted in the standalone.bat. Thus, it becomes worrisome, and that is the reason for the application’s service for behaving unnaturally. Similarly, a plain text version for the one given following would be appropriate for this problem, for the Windows version: 

if $cygwin; then JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"` JAVA_LOC=`cygpath --path --windows "$JAVA_LOC"` JBOSS_CLASSPATH=`cygpath --path --windows "$JBOSS_CLASSPATH"` JBOSS_ENDORSED_DIRS=`cygpath --path --windows "$JBOSS_ENDORSED_DIRS"` fi # Configuring Diagnostics Java Agent AGENT_HOME= PROBE_ID= "$JAVA" -jar $AGENT_HOME/lib/jreinstrumenter.jar -f $PROBE_ID PROBE_OPTS="-Xbootclasspath/p:$AGENT_HOME/classes/$PROBE_ID/instr.jre" PROBE_OPTS="$PROBE_OPTS -javaagent:$AGENT_HOME/lib/probeagent.jar" PROBE_OPTS="$PROBE_OPTS$PROBE_ID" # Use the line below ONLY for JBoss 6 # PROBE_OPTS="$PROBE_OPTS - Djava.util.logging.manager=org.jboss.logmanager.LogManager" # Use the line below ONLY for JBoss 7 PROBE_OPTS="$PROBE_OPTS - Djboss.modules.system.pkgs=org.jboss.byteman,com.mercury.opal" JAVA_OPTS="$JAVA_OPTS $PROBE_OPTS" # Display our environmentecho "=========================================================================" echo "" echo " JBoss Bootstrap Environment" echo "" echo " JBOSS_HOME: $JBOSS_HOME"Thank you.~ Michael

This issue can be fixed while we are working on JBoss 7 JVM. In the specific version of JBoss 7, the domain server has a domain.xml file; the following section was added to each of the Server-group element-

Here the problems are being analyzed that occurred following the install documentation, and that enables us to find the solution for the same as well: 

  1. It was noted that the non-primary nodes were not able to load the agent; it was because the Diagnostics Agent path is specifically unique on each server. The same server-group settings are usually passed to every server in the said cluster. This can be fixed with the use of a wildcard that is located in the section above; it starts with Xbootclasspath.
  1. Then in the monitoring console, it is noticed that the probes were not visible properly, and users found it difficult to continue. The issue remained the same even while using the %0 variable in the, which made it difficult to view and introspect which of the server and JVM the user was actually looking at in the console. This issue can be solved by simply passing an environment variable, that is $VIPNAME into the xml, with the JVM name. Kindly note that the JVM name is also the server-group name. 

In the second section mentioned above, it is observed that the is actually the application name and VIP, which makes it pretty clear for the user to identify which JVM is being monitored using the console. With the help of this naming method, the user can also add as many servers or JVMs as they require, and it will be accurately shown in the console from now on. 

8. Upgrading the Diagnostics server 9.50 and retaining the configuration settings and the historical data

Users often come across difficulties while upgrading the Diagnostics server 9.50 to the most recent version, 9.51. The users want to retain the configuration settings and the historical data while keeping the Diagnostics server version 9.50 and then importing the applications from the previous version. It is also observed that upgrading to the 9.51 version has resulted in absolute failure.

It is quite possible to upgrade to 9.51 from the previous version of the 9.50 Diagnostics server while keeping the configuration settings and the historical data. For keeping the said changes from the previous versions and upgrading the Diagnostics server, the user can simply to follow the steps given below carefully: 

  1. You need to stop the earlier version and end-all of the processes of Diagnostics 9.50.
  2. Then you need to make sure to back up the /etc folder anywhere outside the Diagnostic server, so it is not lost in the procedure.
  3. Then you must backup the /archive folder outside the Diagnostics server.
  4. Then you need to completely uninstall Diagnostics 9.50.
  5. Now you need to install Diagnostics 9.51 completely.
  6. After that, you must stop Diagnostics 9.51 services.
  7. Then replace the /etc. and the /archive folders present with the backups from steps 2 and 3 above.
  8. Now start the Diagnostics 9.51 services manually.

9. Instructions to instrument Oracle Application without needing a console (CPE OCTIM19G1061847)

The users have installed a Diagnostics agent on the Oracle app server successfully. The problem arises when the Application Server Control console is not activated or enabled. Due to that problem, users are unable to follow up on the procedure as duly mentioned in the Diagnostics Java guide.

It is indeed possible to add the JVM parameters on your own, without needing any of the Application Server Control console. The application server version which the EBS currently utilizes is

The user can generally perform this procedure without a console, you just need to instrument the core module. After that you will need to add them to the start Java options section accordingly:

data id="java-options" value="
-server -verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=160M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Dhttp.cookie.ignoreCommaInCookiesNamed=X_NoMatchingCookies"/>

10. Solving the error when the Diagnostic Java Agent fails to reflect after the restart using GUI

The users often go through errors when they restart Diagnostic Java Agent while using the Node Manager in GUI. The error is regarding the Diagnostic Java Agent when it does not react or reflect after restarting.

The situation is that it barely only reflects when the application team starts the script again manually. It may seem bothersome if this is a recurrent problem. They are noticing that the Application startup through the Node Manager in GUI could not reflect the application data level at all. 

This error can be solved if the user takes certain necessary measures. When the user initiates the, that specific agent reflects all of the data of the application. Then the user needs to inspect thoroughly throughout all of the information at hand.

Then they will be able to locate the Node Manager and find that it is using a different script for starting the Diagnostic Java agent. Due to this particular reason, the user had gone through the error because of this particular script that was not compatible hence resulted in this error. 

  1. The user needs to carefully set the StartEnabledScript and check if the files are correct and not corrupted. 
  2. Then they need to make the Node Manager using the start script to start the application again. 
  3. Then the users need to make sure that the procedure has been followed seriously, in case there is any follow-up on the screen. 

Micro Focus Diagnostics – Tips and Tricks – Feb 2021

1. Solving the “…unable to bind listeners to any port in the range 32000-…” error at the time of initiating the .Net Agent Probe Aggregator Service

It often happens that when .NET Agent Probe Aggregator runs as a service managed by the existing Java service wrapper there is an error. The specific wrapper utilizes a communication channel to regulate and manage the Aggregator. The reason for this particular error could be because of some problem in the service wrapper managing the port clash.

The Diagnostics .NET Agent has a particular Probe Aggregator service that has been preinstalled with the Agent. The Probe Aggregator service is responsible to aggregate the .NET Agent data to 5-second intervals before it sends this data to the Diagnostics Mediator server. This function is the reason for good scalability.

It does so by decreasing the network communications with the Mediator server (which could increase the probe system overhead). The user is advised to utilize this service along with the .NET Agent. Sometimes it happens that when Probe Aggregator service is initiated with Windows Services, a dialog box is displayed on the screen. 

Written to the Probe Aggregator JSW (Java Service Wrapper) log file:

FATAL  | wrapperp | yyyy/mm/dd hh:mm:ss | unable to bind listener to any port in the range 32000-is32999. (An attempt was made to access a socket in a way forbidden by its access permissions. (0x271d))

This particular log file can be found by default at:

C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\log\ProbeAggregatorJSW.log

The Probe Aggregator is a Java application and it’s quite akin to the one utilized to run a Diagnostics Mediator. A specific java service wrapper is used to run the Probe Aggregator. The wrapper that is used is actually from Tanuki Software and that wrapper manages the Probe Aggregator Java application with the help of a trusted channel.

In case a previous application is running on port 32000 and if the Windows shows an error code regarding the permission, that is because of the mishandling of this error code. After the Java service wrapper is responsible to eliminate the above-mentioned error.

To solve this problem it is necessary that the user specifies alternate port ranges especially for the Java service wrapper and Java application by editing the Java service wrapper configuration file:  ProbeAggregatorJSW.conf 

And that file is by default, is located at:

C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc

The user needs to closely follow the steps given below:

  1. The user needs to keep a backup copy of the Java service wrapper configuration file
  1. In order to specify a different port range for the Java service wrapper (i.e from 37200 to 37299), you need to add the lines given below:
  1. In order to specify another port range for the Java application (i.e from 37300 to 37399), you need to add the lines given below:
  1. Then the user needs to save the Java service wrapper configuration file
  1. After that, you need to start the Windows service “HPE Diagnostics Probe Aggregator” once again.

 2. Instructions to disable the RUM client monitoring on both .Net and J2EE Agent

It is observed that often the users have queries on how to disable the RUM client from monitoring integration in both .NET and the J2EE Agent. And also ways to disable the X-HP-CAM-COLOR response header for RUM requests. It is quite easy to do so, the user needs to follow certain rules:

The solution below is strictly meant for .Net Probe alone:

In order to disable the response header, the user needs to edit the .Net Probe’s etc/probe_config.xml file. Then the user needs to comment out the key that must be identical to the one given below:

<rum enabled="true" encryptedkey="OBF:3pe941vx43903wre40303xxz3q6r42ob43n93wre3io03xjs40h940pc3wir3q233jur3zir3yi03zir3vc03wre3xpi3r8o3olr44na3zor3v6m3vc03zir44u03ohb3rdi3xjs3wx03v6m3zor3yc63zor3jqz3q6r3wd740vi40b53xpi3ike3wx043gp42ur3q233y3r3zwy3wx0432i42293p9p" responseheader="X-HP-CAM-COLOR"/>

Or the user could also set the rum enabled=”false” and after that, they need to restart the app server (IIS).

 The solution below is strictly meant for the J2EE Probe alone:

In Java Problem an option can be visible at the time of the installation. There is a checkbox available that says Diagnostics with RUM Client monitor”. It will be there when installed once, there is only one way to turn it off. It can be turned off by editing the etc/ = false
client.monitoring.enabled = false

3. When the VA point in HP Diagnostics: 64-bit block cipher 3DES vulnerable to SWEET32 attack

It often happens that the users have a VA point in the HP Diagnostics version 9.30:

+ Port 23472
+Warnings: 64-bit block cipher 3DES vulnerable to SWEET32 attack
Key exchange (DH 512) of lower strength than the original certificate key

This error can be fixed, the user simply needs to follow the instructions given below carefully:

The user needs to select and then edit the specific webserver. properties, which can be done by the following:

  1. The user needs to add the following by default to the of the Commander. 

Some of the users had to add some more ciphers in order to exclude, to clear all the ciphers that exist in customers’ security scan.

secured.connection.disabled.protocols=SSLv3, SSLv2Hello, TLSv1, TLSv1.1, SSLv2

4. Instructions to resolve the “JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 2G requested. Could not create the Java virtual machine

It often happens with the users that the Websphere Application Server using 32-bit Jre is unable to initiate with the probe instrumentation and -Xmx 2048M. The issue is that the Websphere Application Server is unable to instantiate heap and the Java virtual machine is not created.

It is well-advised to the users that specifically for the 32bit Jre, the max heap needs to be defined as less than -Xmx1500m. This prevention should definitely solve this error for the users.

5. Fixing the issue when the “The HP Diagnostics Probe Aggregator failed to start” is displayed on the screen

It often happens that users encounter as an error on the screen that says:

The Diagnostics 9.26 DotNet  Agent Probe Aggregator service will not start

The contents of the log file are given below: 

Running command: D:\MercuryDiagnostics\.Net Probe\ProbeAggregator\bin\ProbeAggregator-windows-x86-64.exe -i "D:\MercuryDiagnostics\.Net Probe\ProbeAggregator\etc\ProbeAggregatorJSW.conf"wrapper
HP Diagnostics Probe Aggregator installed.Starting the HP Diagnostics Probe Aggregator service... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking... Checking...Error message: The HP Diagnostics Probe Aggregator failed to start. See log file: D:\MercuryDiagnostics\.Net Probe\ProbeAggregator\log\ProbeAggregatorJSW.log. Error number: 1Probe Aggregator setup failed.Removing temporary setup files folder: D:\MercuryDiagnostics\.Net Probe\setup\pasetupfiles

This error can be easily resolved, the user needs to thoroughly follow the steps given below:

Generally, the reason why the probe aggregator was not initiating is due to the embedded probe. It was because there was an issue instrumenting some classes that caused the delay in the startup.

  1. The user needs to remove the embedded probe from the probe aggregator, this will help the aggregator service to start perfectly.
  2. Then the user needs to reconfigure the .net agent, as it could be that it was not set up correctly (reporting mediator, metrics ip, aggregator IP) , hence malfunctioning. 
  3. The main reason for the initiation error with the probe was due to web service. As it had few issues with ports (HttpWebServer port 35000 appears to be in use).
  4. After that you need to run the AddHttpURLPrefixes.js., this should solve the problem.

6. Resolving the Integration issue in HP diagnostic to HP BSM

It is noticed among the users that they go through certain Integration issues in HP diagnostic to HP BSM. It is recommended that the users re-install the Operations Agent and IAPA components.

Then they should re-issue the integration carefully, restart and then accept the certificate requests manually. This issue can be fixed easily, the user needs to follow the steps given below:

  1. The user needs to stop and remove the previous IAPA and Operations Agent on the Diagnostics Commander.
  2. Then you need to erase everything in the installation directories.
  3. Carefully install Operations Agent that comes along with the Diagnostics and the IAPA components again.
  4. The user needs to restart the Operations Agent on the DPS and GW servers.
  5. Then you need to make sure to save the integration again from the BSM UI. The former would be responsible for executing the command given below on the Diagnostics Commander:
script oainstall.vbs -a -configure -s -vc
  1. Then the user needs to permit and grant all of the awaiting certificates present on the DPS server.

7. Sorting out the issue of the large trend files in the HP Diagnostics 9.26 archive folder

Users have come across the sudden running out of disk space. This usually happens because of intermittent days where the particular .trend file is present in the archive folder. It also becomes quite a storage consuming (11GB – 25GB). It is a known fact that there are 92 probes available.

There are many questions that come into focus, like if it is possible to remove the specific files or can the hp diag mediator be stopped or not.

It is possible that there are many errors but mainly on the yearly aggregation file:

2018-09-05 09:44:41,690: WARNING archive : Destination Medium : FileStorageMedium: :\HPDiagData\mediator-\persistence\Default Client_\Years\1Y\2018.tree

2018-09-05 09:44:41,690: WARNING archive : , java.lang.IllegalStateException


According to the old case, it is observed that this error could have occurred because of the corrupt or missing yearly files. Due to the corrupt files, it can cause all of the daily files to malfunction and they have not compressed accurately. 

Due to the appearance of this error the user can figure out why the yearly file was not able to expand/grow:

2018-09-05 09:41:08,678: SEVERE archive: Could not initialize summary iterator: There is not enough space on the disk

This error can be fixed, the user simply needs to follow the steps given below:

  1. The user needs to authenticate that there is sufficient space on the particular disk. It is well-advised that the users opt for 4GB per probe, in this case, it will be 368 GB.
  2. You need to delete the following file:

\HPDiagData\mediator-\persistence\Default Client_\Years\1Y\2018.tree or any of the 2018.* file that is present. The user needs to keep a backup somewhere else.

In order to do that, the user can:

You need to stop the system.

Then delete the file.

Now you can start the system.

  1. After the deletion, the user can think of increasing the disk space for the archive. Then the file will be completely regenerated from the Monthly data.

In order to increase the file, the user needs to force stop all the activities, then you can do it along with the previous step right when the system will halt.

8. When the Diagnostics server is registered to another BSM

It often happens that users come across an error dialogue box on the screen, it says:

“Diagnostics server is registered to another BSM” 

It is due to the Integration Diagnostics server being registered into some other BSM. The major cause of this error is because of the setting: bac.registration.use.referer = true.

The user needs to perform the steps given below in order to fix this error:

It needs to be on the Diagnostics Commanding server:

  1. The user needs to navigate to MercuryDiagnostics\Server\etc\ and open it.
  2. Then you need to change this line to the property: bac.registration.use.referer = false.
  3. After that, you need to restart the commander.

9. Instructions to fix the “Object reference not set to an instance of an object” while saving a performance load test

It often happens that when a user is saving any load test in a version-controlled project there is a notification indicating a fault. The changes are not saved as one would expect and the save button constantly appears to be active. When the load test is closed the error message pops on the screen.

When the user is operating ALM Performance Center 12.53 in order to edit a performance load test, saving the load test is not possible. In either the ALM Desktop Client or in the My Performance Center nowhere it is able to save.

The issue appeared at the time when the user was employing a version-controlled project, where even after pressing the Save button nothing happened. And if the user presses on the Close button there a dialogue box comes into sight saying: Are you sure?

Then if the user selects the OK option, the earlier mentioned error emerges.

It is noticed in all the version-controlled projects that this error is a recurrent one in all the other types of projects. Even though it is also observed that this issue did not happen with the previous (patch) versions of the particular product. It is quite obvious that the problem lies in the save function.

The Save function can be recovered, the user simply needs to follow the steps given below:

You need to make the changes given below on every PC Server within the ALM PC environment:

  1. The user needs to modify the start page, by following:

The user needs to keep a backup copy of the file: index.html and it can be found at <Performance Center Server installation folder>\PCWEB\HTML\StartPage

Then you need to edit the file: index.html and it can be found at: <Performance Center Server installation folder>\PCWEB\HTML\StartPage\index.html

Then you need to change the value IE=EDGE to IE=9, so that the line “Meta” tag that has this particular entry will be displayed as: <meta http-equiv=”X-UA-Compatible” content=”IE=9″/>

After that, you need to save the file.

  1. Then the user needs to alter an IIS setting following the instructions given below:

You need to open the IIS Manager console on the PC server.

Then you need to navigate to Sites and then to Default Web Site.

Then go to Admin, and then double click on Authentication.

Click on the Forms Authentication entry, then do a right-click and select the Edit option.

You need to amend the cookie name from “.ASPXAUTH” to “.ASPXAUTH_adm”

Do not forget to select the OK button to save the recent setting.

Then you need to click on the PC Server name under the Connections

Then under that, you need to click on Actions, and then on Restart that will be visible on the right-hand side to restart IIS.

10. Fixing the error when it shows: Diagnostics Next Gen – No Data

This error has been observed in the Diagnostics version 9.50 on the Linux RHEL. It seems that the Java Agent is also instrumented with the application server. The error is seen when the users navigate to the Diagnostics Next Gen GUI and they are unable to view any of the data.

This error can be resolved by performing the steps given below:

1. The next-Gen UI will definitely have the data in case the Top-level Request view has data.

2. Then you need to authenticate the aggregate.top_level.fragments = true is displayed in MercuryDiagnostics\etc\ file of the Java Probe.

The users need to note that the top-level Aggregator feature is specifically available in the Java Agent 9,40, 9.50, and the other new releases.

Micro Focus Diagnostics – Tips and Tricks – Mar 2021

1. Diagnostics issues with integration to BSM

The relation between the diagnostics server and BSM is lost, and the integration stops working at random. 

Diagnostics Server often deregisters itself with HP BSM after effectively applying it to Business Service Manager (BSM).

The following error is recorded in the Diagnostics server.log: 

SEVERE   registrar           : Attempt to set RegistrarData.lanID to null!
java.lang.NullPointerException: Attempt to set RegistrarData.lanID to null!
WARNING  diag_server         : AdminLogin referrer ('http://BSM_SERVER:80') does not appear to be us (DIAGNOSTIC_SERVER_MACHINE) or the currently registered BSM ('').

The following steps can be implemented  to resolve the issue: 

  1. Access the commander’s machine. 
  2. Open: MercuryDiagnostics\Server\etc\
  3. This line should be added to the properties file: bac.registration.check.referer=false
  4. Reboot the commander
  5. Check to see if the issue has been resolved.

2. The Diagnostics .NET Agent installation fails when the optional Probe Aggregator Service is selected

What is Diagnostics .NET Agent? 

The Diagnostics.NET Agent is a program that allows you to perform diagnostics on your server. It is mounted on the server that hosts the application you’d like to monitor. The.NET AppDomains you want to control are automatically discovered and instrumented during agent installation and setup.

Process invocations, collection points, and the start and end of business and server transactions are all captured by the handler. Many of Software’s Diagnostics products, such as LoadRunner, Performance Center, and BSM, are compatible with the.NET Agent.

If the installation of the.NET Agent may be hampered by security restrictions then you can follow the below solution

  1. When attempting to install the Diagnostics.NET Agent on a Windows Server platform with the optional Probe Aggregator Service selected, the installation fails. 
  2. In the report, the following error is mentioned: “ProbeAggregator/log/ProbeAggregator/JSW” file:
  3. FATAL  | wrapper  | 2014/04/18 16:54:03 | OpenSCManager failed – Access is denied. (0x5)
  4. The following error may also be found in the “/setup/SetupResults” file has:
  5. Running command: C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\bin\ProbeAggregator-windows-x86-64.exe -i “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc\ProbeAggregatorJSW.conf”
  6. Error message: . Error number: 1
  7. Probe Aggregator setup failed.
  8. Removing temporary setup files folder: C:\MercuryDiagnostics\.NET Probe\setup\pasetupfile

This problem may be induced by the installation platform’s security restrictions.

The following steps can be implemented  to resolve the issue: 

  1. Make sure the user installing it is a complete administrator. 
  2. User Account Control (UAC) is turned off. 
  3. That the installer is started by right-clicking and selecting “Run as administrator…”

3. How to set up SSL on a Diagnostics server using a certificate from CA authority?

What is an SSL Certificate? 

SSL-Secure Sockets Layer is a security protocol that is widely used on e-commerce sites and pages where users must submit personal or credit card details. An SSL certificate is a form of digital certificate that enables an encrypted link and provides authentication for a website.

These certificates inform the client that the web service host demonstrated domain ownership to the certificate authority when the certificate was issued. 

How keystore and certificates work in Java?

  1. Create a file containing a private key and a self-signed certificate from it.
  2. Create a file containing a private key and a certificate request file (.csr) containing that key, so that a CA authority can generate a certificate based on that key. For SSL to operate in the SERVER, the certificate must be imported to the keystore file containing the matching private key after it is generated by the CA authority. 
  1. Generate keystore:
<diagnostics_server_install_dir>/_jvm/bin/keytool -genkey –keystore <diagnostics_server_install_dir>/etc/keystore -storepass <password> -alias SERVER -keyalg RSA -keypass <password> -dname "CN=<diagnostics_server_hostname>, OU=Diagnostics, O=Hewlett-Packard, L=Palo Alto, S=CA, C=USA" -validity 3650
  1. Generate Certificate request file:
keytool -certreq -alias SERVER -file <diagnostics_server_install_dir>/etc/diag.csr -keystore
<diagnostics_server_install_dir>/etc/keystore -storepass <password>

3. Request that the CA authority generate the certificate from the diag.csr file and send it back in.cer format. 

  1. Import the cert.cer certificate file from the CA authority into the keystore on the server:
keytool -import -trustcacerts -alias SERVER -file cert.cer –keystore <diagnostics_server_install_dir>/etc/keystore
  1. For the private key (in the keystore) and public key (in the certificate) to match, the certificate file must be imported in the correct keystore file from which the certificate request file was created; otherwise, SSL will not function. 
  2. To use the new keystore register, restart the Diagnostics server. 
  3. If your CA authority created the certificate with a different private key, you’ll need to generate the keystore with the matching key using different instructions, as shown next.

Generating keystore file from existing certificate and private key files

  1. To make this function, ask your CA to give you a certificate and private key file in any format supported by openssl binaries, such as private.key and cert.cer in PEM format. 
  2. Once you have the files, use openssl to convert them to pkcs12 format (you can request this format from the CA authority to avoid having to use openssl): 
  1. When prompted, type the desired password for the new.p12 file (which may be the same as the password for the keystore file). 
  2. If you don’t have access to openssl binaries, you can use the following online tools
  3. After you’ve built the.p12 file, use keytool to build a new keystore with the following key:
keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore <diagnostics_server_install_dir>/etc/keystore
  1. When prompted by keytool, type the desired password for the new keystore register. 
  2. Following the instructions to obfuscate passwords and set up SSL options in the keystore
  3. <diagnostics_server_install_dir>/etc/ file as shown in Install & Configuration Guide:
# passwords for the keyStore and key
keyStorePassword=<password used by keytool when keystore was created>
keyPassword=<private key password used in openssl command> 
  1. Restart Diagnostics server to pick up the new keystore file.

4. Error SEVERE archive: Unable to create archive after upgrade Diagnostic 9.23 Server

How to upgrade Diagnostics Server? 

You can use the update wizard to upgrade Diagnostics Server components, or you can use the silent upgrade protocol to upgrade the components and deploy the silent upgrade to several computers.

When you run the installation wizard on a device that already has a previous version of the product, the wizard switches to update mode for the installed component or components and allows you to install components that are not on the same machine.

If you get the SEVERE archive error: Unable to build archive following upgrade Server Diagnostics 9.23

The error occurs because the symbol table is not up to date with the Diagnostic Server update.

The following steps can be implemented  to resolve the issue: 

  1. Please read the updated document and execute the following command:
  1. This will bring the symbol table up to date with the Diagnostic Server and resolve the issue.

5. Error: “…initializing com.mercury.diagnostics.capture.metrics.jmx.WebSphere6JMXCollector@8b0e7414 java.lang.IncompatibleClassChangeError” reported by the Diagnostics Java Agent probing a WebSphere Application Server

What is WebSphere Application Server? 

WebSphere Application Server (WAS) is a web application server that runs on IBM’s WebSphere platform. It is, more precisely, a software platform and middleware for hosting Java-based web applications.

It is the centerpiece of IBM’s WebSphere software suite. It was initially founded by Donald F. Ferguson, who later became CTO of Software for Dell. In 1998, the first version was released. 

This issue may be caused by a problem with the IBM J9 VM JRE, which would result in certain metrics for affected probes not being displayed. To fix this issue, a number of alternative measures are suggested.

The following error may be identified when the HP Diagnostics Java Agent is configured to probe a Java application running on the IBM J9 VM JRE:

2015-09-22 13:54:24,558 SEVERE capture.metrics [Metrics Collection] Error initializing com.mercury.diagnostics.capture.metrics.jmx.WebSphere6JMXCollector@8b0e7414


This error may be caused by a problem with the IBM J9 VM JRE (specific FixPacks).

The following steps can be implemented  to resolve the issue: 

  1. Upgrading to HP Diagnostics 9.24 (or later) or,
  2. Upgrading the IBM J9 VM JRE 1.7 to the latest available fix pack (equivalent to or later than IBM JRE 1.7 SR6 FixPack 1).
  1. Take a backup copy of the JAR file “probe-jmx-was6.jar” delivered with the Java Agent in the folder/directory “<Java_Agent_Install>\JavaAgent\DiagnosticsAgent\lib” (e.g. “C:\MercuryDiagnostics\JavaAgent\DiagnosticsAgent\lib”),
  2. Unzip the JAR file into a temporary location and locate the folder/directory named “com\mercury\diagnostics\capture\metrics\jmx”,
  3. Remove all classes from this folder/directory except:
  1. WebSphere6JMXCollector.class
  2. WebSphere6MetricGroup.class

6. HPE Diagnostics User Interface freezes or hangs

After launching the HPE Diagnostics User Interface (UI) by selecting “Open Diagnostics” (or “Open in This Window”) and entering a username and password, performing an action such as displaying data for all Java Probes for long periods of time (days or weeks) can cause the UI to freeze and prevent further actions. This problem can arise in a larger Diagnostics environment with a large number of Mediators and probes. 

Once the Diagnostics UI has frozen, there is no way to restore it, and the browser tab that is showing it must be locked. The UI can then be opened in a new browser tab (or new browser instance), but the freezing behavior is likely to return.

The following steps can be implemented  to resolve the issue: 

  1. To find the “Java (32-bit)” Control Panel entry, open the Windows Control Panel and check for “Java.” To open the Java Control Panel, click on the entry: 

Note: If there is no “Java (32-bit)” Control Panel entry this may be due to there being multiple Java versions installed on the client platform. 

Locate the Java 32-bit installed in a folder under “C:\Program Files (x86)” (typically “C:\Program Files (x86)\Java\jre7\bin”) and execute the file “javacpl.exe” using right-click “Run as administrator”.

  1. To open the “Java Runtime Environment Settings” dialog, click the “Java” tab and then the “View” button. 
  2. The default heap size is usually 256MB, but this can vary depending on the device. Before the process terminates, the actual memory size of the process can be seen in the Windows Task Manager. Increase the heap size and test to see if the UI freeze persists; if so, increase the heap size as required. The following example configures a 700MB heap, but up to 1GB (“-Xmx1G”) can be used (memory is restricted in this 32-bit process):

7. Error: “HttpWebServer port 35000 appears to be in use” when starting the Diagnostics .NET Agent

  1. On the port range 35000 to 35100,.NET Agents fail to start and are unable to communicate. 
  2. The agent (probe) fails to start as planned after a successful installation of a Diagnostics.NET Agent, and the following error message is written in the agent log file: 
  1. According to the agent configuration in the file at: 
  1. As a result, no data for this probe is recorded in the Diagnostics UI, and it does not appear in the Diagnostics Health View. The following alert message appears in the Diagnostics UI: 
  1. Navigating to:

http://<probe_host>:35000 results on no response.

  1. The netstat order, on the other hand, indicates that ports 35000 to 35100 are open for use.

The following steps can be implemented  to resolve the issue: 

  1. For the ports in the.NET Agent Profiler’s port set, a “urlacl” must be listed. To fix the issue, follow these steps:

cscript “C:\MercuryDiagnostics\.NET Probe\bin\AddHttpURLPrefixes.js” (for Windows Server 2008)

cscript “C:\MercuryDiagnostics\.NET Probe\bin\AddHttpURLPrefixesW2k3.js” (for Windows Server 2003)

  1. If the Windows platform where the.NET Agent is mounted has several network cards, edit the configuration file at:
  1. Also edit the configuration file at: 

If an alternative port range has been specified for the .Net Agent Profiler then follow these steps:

                    var minPort = 38100;

                   var maxPort = 38200;

8. Configuring the Diagnostics .NET Agent and Probe Aggregator to use non-default ports

Why is Probe Aggregator important for .NET Agent? 

When dealing with a large number of probes from.NET agents, it is suggested to use Probe Aggregator. Because of its functions like reducing network communication between the probe and the server, as well as the server’s load and also the Probe Aggregator improves scalability.

The use of the Probe Aggregator was used to evaluate and enforce load testing and power management. There should be no more than 50 probes connected when.Net agents are connected directly to a Diagnostics Mediator without using Probe Aggregation.

  1. The .NET Agent connects to Probe Aggregator on port 45000 (using HTTP),
  2. The .NET Agent connects to Probe Aggregator on port 2626 (using TCP),
  3. The .NET Agent Profiler listens (for HTTP) on the lowest available port in the range 35000 to 35100,
  4. The Probe Aggregator listens (for HTTP) on port 45000,
  5. The Probe Aggregator listens (for TCP) on port 2626,
  6. The Probe Aggregator, which runs in a JVM, is also probed with a Java Agent. The Java Agent Profiler listens (for HTTP) on port 35000.

The following steps can be implemented  to resolve the issue: 

  1. probe_config.xml (“C:\MercuryDiagnostics\.NET Probe\etc\probe_config.xml”)
  2. metrics.config (C:\MercuryDiagnostics\.NET Probe\etc\metrics.config)
  1. (“C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc\”)
  2. (C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc\”)
  1. (C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\probe\etc\”)

2. which is located in the folder “<.NET Agent Install>\ProbeAggregator\probe\etc” (default is “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\probe\etc”)

  1. The Probe Aggregator will listen (for HTTP) on port 38000 (default is 45000),
  2. The Probe Aggregator will listen (for TCP) on port 38626 (default is 2626),
  3. The .NET Agent Profiler listens (for HTTP) on the lowest available port in the range 38100 to 38200 (default is 35000 to 35100),
  4. The Probe Aggregator probe (Java Agent) listens (for HTTP) on port 38100 (default is 35000).

<diagnosticsserver url=”” />

<mediator ssl=”false” host=”″ port=”38626″ metrichost=”″ metricport=”38000″ />

<webserver start=”38100″ end=”38200″ />

metrics.server.uri =



jetty.port = 38000

jetty.port = 38100

<.NET Agent Install>\log (default is “C:\MercuryDiagnostics\.NET Probe\log”)

and the Probe Aggregator at:

<.NET Agent Install>\ProbeAggregator\log (default is “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\log”)

and the Probe Aggregator probe (Java Agent) at:

<.NET Agent Install>\ProbeAggregator\probe\log (default is “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\probe\log”)

9. .Net agent causing memory and CPU overhead during load test.

What is CPU Overhead? 

The amount of work that a computer’s central processing unit can do and the percentage of that power that is used by individual computing tasks are both measured by Central Processing Unit (CPU) overhead. Supporting the functions of the computer’s operating system is one of its activities.

It also includes Internal components, such as hard drives and graphics processing units with providing connective features too, such as networking support, and lastly external components, such as the computer’s display. Processor power is provided for applications by the need for CPU overhead. 

The following steps can be implemented  to resolve the issue: 

  1. Stacktracesampling :
 <stacktracesampling enabled="false" maxactivethreads="100" suspendthread="true" outboundcalls="false" rate="100" tardymethodlatency="150"/>
  1. RUM probe:
 <rum enabled="false" ...
  1. Threads Monitoring: 
<process name="ASP.NET" monitorthreads="false" enablealldomains="false">

10. After upgrading, history data lost, custom view and application lost

What is the use of Custom View in Diagnostics 9.40?

You can use a custom view to save unique display and print settings (such as hidden rows and columns, cell selections, filter settings, and window settings) for a worksheet so that you can easily add these settings to that worksheet when needed. A custom view can also provide a special print area.

You can create several custom views per worksheet, but each custom view can only be applied to the worksheet that was active at the time the custom view was developed. You can uninstall a custom view if you no longer need it.

If the History data, custom views, and the application were all lost after upgrading to 9.40.

The following steps can be implemented to resolve the issue: 

Micro Focus Diagnostics – Tips and Tricks – Apr 2021

SEVERE error in Diagnostics when trying to start the server.

Who hasn’t faced a problem while starting a server? Normally, after amending Diagnostics due to an installation or an upgrade, you would face errors while starting the Diagnostics server.

During the process of starting Diagnostics server, in server.log you will see the following error message:

The SEVERE error in Diagnostics is when you modify a server’s configuration files or after an upgrade, while starting the Diagnostics. The cause is to remind us about the left traces from the former installation of Diagnostics. Specifically, refers to the examples of the server nanny.

For fixing it, remove the duplicate of the server nanny files from the path. The following server nanny address might be renamed.

For example –


How to configure HP SiteScope so that it can be monitored using an HP Diagnostics Java Agent

Most of the application servers involve modification of startup scripts for adding the JVM Parameter. Yet this tactic does not provide a positive result for HP SiteScope. Those who don’t know, HP SiteScope is an application running in a Java Virtual Machine (JVM). Now the real question is how to monitor HP SiteScope using an HP Diagnostics Java Agent?

If an application server is to monitor using the HP Diagnostics Java Agent needs the JVM Parameter from the JRE Instrumenter. It requires adding to the startup script for the server.

Nevertheless, HP SiteScope requires a modified registry setting by adding the JVM Parameter. The to be modified registry setting holds the full parameter list for starting the HP SiteScope. It is confined in the Windows “service” registry entry for HP SiteScope. After applying this procedure, make sure the HP SiteScope JVM is instrumented using JRE Instrumenter.

The Java installation maneuver by SiteScope is sited at: <SiteScope_install>/java 

These are steps for identifying the name of the Windows “services” entry. Follow accordingly:

Step 1: Use START->Run “services.msc” for opening Windows.

Step 2: Search the SiteScope services entry and check the name it appears with. Mostly it will be as “HP SiteScope” or “SiteScope”.

For stopping SiteScope: Click on the SiteScope services entry. Select “Stop the service”. The Site Scope will be stopped.

These steps are for adding the JVM Parameter. Follow accordingly:

Step 1: Use Start->Run “regedit” for opening the Registry Editor. Take a backup of the registry.

Step 2: Search the SiteScope service entry in the registry; it will be as “Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services“. If the SiteScope services are named as “SiteScope”; the key will be as “Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SiteScope“.

Step 3: Click on the sub key (under that key) “serviceParam”. It normally starts with “”.

Step 4: For this sub key double click on “Default”. Select the “Modify….”

Step 5: Put on the JVM Parameter from the JRE Instrumenter. This will change the entry from:….



For example:

-Xbootclasspath/p:C:\MercuryDiagnostics\JavaAgent\DiagnosticsAgent\classes\Sun\1.6.0_14\instr.jre -javaagent:C:\MercuryDiagnostics\JavaAgent\DiagnosticsAgent\lib\probeagent.jar -Dcom.sun.manage….

Step 6: Save the revised “serviceParam” entry. Close the “regedit”.

Step 7: Start SiteScope in Windows Services and review will be hurled in the SiteScope JVM.

Error: “HttpWebServer port 35000 appears to be in use” when starting the Diagnostics .NET Agent

From the port range 35000 to 35100, .NET Agents failed to start and couldn’t communicate. After a successful installation of Diagnostics .NET Agent, the agent fails to start and following error message pops up in the agent log file:

HttpWebServer  HttpWebServer port 35000 appears to be in use

According to the agent configuration in the file, this error message is recurring in all the ports of the range 35000 to 35100:

C:\MercuryDiagnostics\.NET Probe\etc\probe_config.xml

Thus, neither data is testified for this review in the Diagnostics UI, nor the data appears in the Diagnostics Health View. The following cautioning message is displayed in the Diagnostics UI.

The probe is not currently running or is not configured properly

Piloting to: http://<probe_host>:35000, also shows no result. However, the “netstat” command shows that ports 35000 to 35100 are available to use.

An “urlacl” is to be pointed out in the port range for the ports, used by the .Net Agent Profiler.

Follow these steps for solving the issue:

Step 1: Log in the Windows platform and run the .NET Agent as an administrator. Or open Windows PowerShell via “Run as Administrator”.

Step 2: Run the below mentioned Windows platform specific command:

cscript “C:\MercuryDiagnostics\.NET Probe\bin\AddHttpURLPrefixesW2k3.js” (for Windows Server 2003)

cscript “C:\MercuryDiagnostics\.NET Probe\bin\AddHttpURLPrefixes.js” (for Windows Server 2008)

Step 3: Use the command “iisreset” and restart the examined application.

On the Windows platform where .NET Agent is installed, if multiple network cards are present edit the configuration file:

<.NET Agent Install>\etc\probe_config.xml (default is “C:\MercuryDiagnostics\.NET Probe\etc\probe_config.xml”)

Then, confirm a value is given to the “host_name” in the upcoming setting:

<diagnosticsserver url=”http://<mediator_server>:2006/commander” registered_hostname=”<host_name>” />

For editing the confirguation file:

<.NET Agent Install>\etc\metrics.config (default is “C:\MercuryDiagnostics\.NET Probe\etc\metrics.config”)

Ensure that a name is mentioned for the “host_name” in the below setting:

metrics.agent.registered_hostname = <host_name>

For any other port range facing issue in the .NET Agent Profile, use the method defined in Configuring the Diagnostics .NET Agent and Probe Aggregator to use non-default ports. Then, follow the below mentioned steps:

Step 1: For the ongoing Windows platform, make a backup copy of the JavaScript file.

Step 2: For the in-use Windows platform, edit the JavaScript file. Modify the following port range lines:

var minPort = 38000;

var maxPort = 38300;

Step 3: Save the JavaScript file and run it as said above.

What permissions are needed for Oracle DB collector?

To know the permissions that are required for Oracle DB collector. Continue to read.

The operator requires to CREATE SESSION. For collecting the performance metrics “SELECT ANY DICTIONARY” on v$.

License Clarification for HP BSM Diagnostics

You will find the example and answer about “how licenses can be used?”

How do licenses for HP BSM Diagnostics 9.20 work?

For example:

Composite Applications One OS Instance w/ APM 360 OSI SW – 20 DIAG-APM360OSI HP BSM Diagnostics

  1. How many inquiries can be installed depending on the above?
  2. Using one Diagnostics Java inquiry, how many JVM cases can be handled?

Using this license, the operator can install many queries as well as monitor many JVMs as required.

The license restriction is related to the number of OS cases to use. Both virtual and physical OS cases can be counted.

Diagnostics License information

What is capacity defined as per the Diagnostics License Management page? And how? Well, this article holds the meaning of Capacity shown in License Management. It helps users to state needs and understand the policy of the license.

The capacity of licenses depends upon different units based on the version of Diagnostics in use. Further, those units hang on the Diagnostics server version. For example, 9.20 and earlier is App Instances and for 9.21 and later is OS Instances.

First, it is important to check the version of Diagnostics. Depending on the number of the probes configured, there is different capacity consumed.

In this regard, there are two different types of licenses in Diagnostics:

For checking the number of licenses required, a user needs to check the number of probes active in the system. Not on the commanding server.

How to modify Thresholds in Diagnostics

In this article, you will find how to modify custom thresholds in Diagnostics. The refers that needs to be modified depending on the operator’s uses.

Default thresholds can be constructed for components that are in connection to a mediator in the /etc/ with the format:

<metric-parent-node-classname>.<metric-name> = [-] value

<collector-name>.<metric-name> = [-] value

The change duplicates at server level but the threshold values which can be modified for defined entity types. For the entity list it is essential to search in the <server>/etc/thresholds.configuration file. Modifying these is similar to the setting of metric threshold in the Details pane of Diagnostics view. If you wish to change the thresholds for all servers, request it by creating a script as they are regulated at JVM level. These server scripts can be written and run at http://<Diagnostics Server>:2006/thresholding/script.jsp.

More information about how to write the threshold setting scripts, is available in HP Diagnostics User’s Guide, under the chapter of ‘How to Set Thresholds Using Script Statements’. In addition to that, you can use the diagserver:port/thresholding page for setting bulk thresholds and alerts by path, where you can find script examples.

The difference between normalized CPU utilization and Total CPU utilization

In this article, you will find the answer to all the questions that are hovering in your mind. Like, what’s the difference between the normalized CPU utilization and total CPU utilization. What is the number of cores? Let’s find out.

Normalized CPU utilization is the CPU utilization required for the application server process divided by the number of logical cores or processors. The CPU utilization on the Windows or the host system, counting in all processors will be less than 100. Whereas Total CPU Utilization is present on all the cores, adding it up will be greater than 100. For instance, let’s take Total CPU Utilization at 4% and the number of CPUs/cores is 4. Then, the Normalized CPU Utilization will be at 1%.

Both metrics, Normalized CPU utilization and Total CPU utilization forecasts the same thing, that is, the CPU consumed by the checking process. It includes the Java application, the JVM, all the native libraries used by the JVM or the app and the probe. This represents the total of CPU utilization through all the threads fitting to the process.

Let’s say the system has N Cores or CPUs, then:

Normalized CPU Utilization = Total CPU Utilization/N;

On the single CPU system, it appears that metrics have the identical values.

If you want to compare CPU Utilization of the probe with the system CPU Utilization, then the used Normalized CPU Utilization metric for the case is counted so that the metric shows the result less than 100% and stays constant with the host system CPU utilization metric.

Reduce instrumentation overhead.

What sort of mechanisms or techniques does Diagnostics give for reducing instrumentation overhead?

The primary step is to make sure the instrumenting is accurate. For instance, the prime suggestion is not to instrument set or get calls. This simply returns or sets a single value, quite speedily. To transact with a very less transaction time, you don’t require an instrument for performance.

After that, take a note about Diagnostics that is designed for using the level of instrumentation. It would give adequate information for troubleshooting a temporary issue. Or it will be hard for reproducing performance issues to impose a low overhead which in return helps to control in the most production environments.

For achieving this target, Diagnostics has two mechanisms. It robotically adjusts data collection in reply to the performance characteristics of the presently executing server request.

The first mechanism is latency-based trimming. Assuming a certain invocation of an instrumented method is fast, then the invocation will not be reported. There would be no sign of a corresponding node in the Call Profile. This further dismisses the overhead substantially. As the Diagnostics Agent doesn’t have to build the necessary object and dwell it in the call tree.

During the identical time, it is quite implicit that fast calls have no importance to the user whose main focus is analyzing performance issues. You can also modify the accounting threshold (by default 51 ms) for eliminating these types of fast call, obtained through the very thin bars in the call profile. These fast calls also have comparatively high overhead. And they don’t give any resourceful information to help diagnose performance issues.

The second data collection mechanism is stack trace sampling, especially for Java 1.5 or above. It reports a long running method, despite not being instrumented. Therefore, if you enable this feature and tune it for providing an accurate level of information; the operator can turn off a few of the instrumentation and believe the potential performance problems in the module will get caught by stack trace sampling.

As far as the light-weight code injection, it needs to be done. The instrumentation is very light weight. You need to realize that a greater part of the overhead is caused due to taking a timestamp. It is highly necessary for calculating the latency.

The metrics collected out of the box

What does “the metrics are collected out of the box” even mean? Let’s find out!

The doc of metrics collected is the ‘metrics.config’ for .NET Agent and ‘metrics.config’ file for Java agent. What metrics Diagnostics accumulates is totally dependable in part of the running application server (WebLogic, WAS, IIS, Jboss and more). If observing at WAS, the metrics Diagnostics collected is reliant on the PMI setting of WAS. Any PMI and JMX metrics can be collected by the Diagnostics Java Agent.

If you want to make a list of all the existing metrics for each JMX collector and store them in a file, then the Java Agent metrics.config file provides that. The default.dump.available.metrics assets in the metrics.config is set to true, then the case will make the list of available metrics to a text file in the probe log directory.

The text files are termed as the following:


<probe-id>/jmx_metrics_<collector-name>.txt. to probe all the metrics available to the case in the JVM. The final result can be edited into new metrics.config entries on the fly.

Given that, you can modify the metrics collection in the metrics.config agent file. To have more ideas, refer to the Install Guide sections on “Configuring Diagnostics Metrics Collectors”.

Using the .NET Agent and the Java Agent, the installation process of the system metrics collector happens. It helps to collect system-level metrics like memory usage and CPU usage from the agent’s host. If you wish, you can alter the system metrics collection in the metrics.config file.

Micro Focus Diagnostics – Tips and Tricks – May 2021

1. How to set up BSM / SHA to collect Diagnostics metrics?

A brief intro, BSM stands for Business Service Monitoring and SHA stands for Service Health Analyzer. This is an end-to-end management software tool that joins in a server application, network, and other business transaction monitoring. SHA and diagnostics integration are interrelated to each other.

Now comes the question, how to set up BSM/SHA for collecting Diagnostics metrics? (SHA and Diagnostics integration)


Step 1: Run this command, \<HPBSMInstalldirectory>\dbverify\bin\run_schema_upgrade.bat.

Step 2: Go to the Windows taskbar, Click Start > All Programs > Business Service Manager > Administration > Configure Business Service Management.

Step 3: Click Next and add an SHA license

Step 4: Click Next and choose Service Health Analyzer

Step 5: Broad the wizard.

Lastly, take a look at this document attached, for more information.

2. How to set up SSL on a Diagnostics server using a certificate from the CA authority?

Want to set up HTTPS through a CA certificate? Check the solution below to know how to set up SSL using a certificate from the CA authority on a Diagnostics server.


Before jumping into any sol, know-how Keystore and certificates work in Java.

Java’s storehouse for keys and certificates is called a Keystore file. The native tool for managing Keystore files is known as keytool. The keytool comes together in any Java Runtime Environment (JRE).

The Keystore consists of all imported and trusted certificates for retiring HTTPS connections and their public keys. But most critically, it has a SERVER certificate and the unique private key is used for generating that certificate to serve the incoming HTTPS connections.

If a Keystore is created by keytool, there are two options available for SERVER certificate:

Option 1:

Generate the file using a private key. Then, a self-signed certificate will be generated from it. More instructions on this option can be found in the Diagnostics Install and Configure Guide.

Option 2:

First, generate the file with a private key and then generate a certificate request file (.csr) that contains the key for CA authority for creating the certificate based on that key. Once the certificate is made by the CA authority, it is required to import to the Keystore file that contains the matching private key for SSL for working in the SERVER. For implementing this option follow the generic keytool instructions:

Generate keystore:

<diagnostics_server_install_dir>/_jvm/bin/keytool -genkey –keystore <diagnostics_server_install_dir>/etc/keystore -storepass <password> -alias SERVER -keyalg RSA -keypass <password> -dname “CN=<diagnostics_server_hostname>, OU=Diagnostics, O=Hewlett-Packard, L=Palo Alto, S=CA, C=USA” -validity 3650

Produce Certificate request file:

keytool -certreq -alias SERVER -file <diagnostics_server_install_dir>/etc/diag.csr -keystore

<diagnostics_server_install_dir>/etc/keystore -storepass <password>

Appeal to the CA authority for generating certificates using diag.csr file and send back it in .cer format.

Ship in cert.cer certificate file from CA authority in server’s keystore:

keytool -import -trustcacerts -alias SERVER -file cert.cer –keystore <diagnostics_server_install_dir>/etc/keystore

Now, the certificate file must be sent back in the correct Keystore file form in which the certificate request file was created, for public key (in the certificate) and private key (Keystore) matching accordingly. Or else SSL will not work. In the next step, restart the Diagnostics server for picking up the new Keystore file.

But what if your CA authority has already created the certificate through a different private key? Then, follow a different set of instructions for generating the Keystore with matching keys as mentioned below.

To generate Keystore files from existing certificates and private key files follow the below-mentioned steps.

Step 1: Request your CA to send the private key files and certificate files in any form that is supported by OpenSSL binaries. For instance, cert.cer and private.key in PEM format. (If OpenSSL binaries are not available there are many other tools available such as > ssl converter.html)

Step 2: After receiving the file use OpenSSL for exporting them into pkcs12 format. If possible, request this format from CA authority for skipping OpenSSL export operation:

openssl pkcs12 -export -in cert.cer -inkey private.key -certfile cert.cer -name “SERVER” -out keystore.p12

Step 3: Now, when prompted enter the wanted password for new. P12. You can use the same password for the Keystore file.

Step 4: When .p12 file is created, use keytool for generating the new keystore with matching key:

keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -destkeystore <diagnostics_server_install_dir>/etc/keystore

Step 5: Now enter your password for the new Keystore file as asked by keytool.

Step 6: After the generation of Keystore is completed follow the instructions below to cloud passwords. Set up SSL options in <diagnostics_server_install_dir>/etc/ file as shown in Install & Configuration Guide:

# passwords for the Keystore and key

keyStorePassword=<password used by keytool when Keystore was created>

keyPassword=<private key password used in OpenSSL command>

Step 7: Restart the Diagnostics server for picking up the new Keystore file.

3. JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 2G requested. Could not create the Java virtual machine

With probe instrumentation and Xmx 2048M, Websphere Application Server fails using 32-bit Jre. But what is the possible issue of Websphere Application Server’s failure? It errors out by showing the message “JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 2G requested. Could not create the Java virtual machine”


To fix this troubling issue, check this sol. The max heap should be defined as less -Xmx1500m for 32-bit Jre. For more detailed information, go to > tech network > java > hotspot faq 138619.html#gc_heap_32bit

4. JBoss server will not start after probe instrumentation

After Java Probe Instrumentation, the JBoss application server fails to start. Facing this issue? The sol is just below.


JBoss entails additional special settings for working properly with the Java HP agent.

For JBoss 7.x, 8.x (Wildfly), add the following JVM parameter:


For JBoss 6.x, add the following JVM parameter:


5. Error: “When the timeout occurred the thread…” reported by a Linux based Java application running in a VMware environment with HP Diagnostics

You might observe poor application performance while using the Java Agent to probe a Java application; if it runs on a Linux hosted VMware environment. Another reason for poor performance is if the VMware API provides timestamp info that is not configured correctly.

Want to know detailed information about the issue? If a Java application runs on a Linux server (virtual machine) in a VMware environment that is probed using the HP Diagnostics Java Agent, then the exhibiting performance is poor. 

It also reports the below mentioned in the Java application’s logs:

[7/8/15 15:56:57:847 BST] 0000006c TimeoutManage I WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WebContainer: 253,5, main].

When the timeout occurred, the stack of this thread was as follows:

com.mercury.diagnostics.capture.jni.VmwareJNI.getHostTimestampUsecsWa(Native Method)














The performance will no longer be there when the Java Agent is disabled.

Now, let’s move to the reason. When the HP Diagnostics Java Agent finds out that the Java application is probed and being running in a virtual host, like in a VMware environment, the Java Agent by default will try to access VMware for obtaining the timestamp information It is necessary for regulating the latency of functions which is instrumented by the probe.

Moreover, whether the VMware environment doesn’t conform to the requirement specified in the section “Time Synchronization for Probes Running on VMware” present in the HP Diagnostics Installation and Configuration Guide, then the Java Agent accessing the VMware API might exhibit the performance issues.


For fixing, instruct the Java Agent for using the Java Virtual Machine (JVM). It will help in obtaining the timestamp information rather than the VMware API. Specify a value of “false” for the property “attempt.VMware.timestamp.adjustments” in the Java agent configuration file “”.

For instance, edit the file at:

<Java Agent Install>\etc\

Then, shape the property “attempt.vmware.timestamp.adjustments” as follows:


6. What’s New in 9.23 IP2?

IP2 stands for Internet Protocol Integration Project. But what is new in 9.23 IP2.


Security Fixes –

It provides an update that fixes the Heartbleed vulnerability issue, which is associated with OpenSSL. For information, check out the HP Security Bulletin and

System Requirements Changes –

For the Diagnostics Enterprise UI client, support JRE version 8.

Compatibility Changes –

For implementing more compatibility changes, support the following:

Supports Performance Center version 12.00

Supports LoadRunner version 12.00

RUM-Diagnostics Integration –

Using the .NET Agent, many improvements have been made to the RUM-Diagnostics by injecting in the RUM JavaScript. Want to know more details?

7. How to change Commander to Mediator?

Want to change the Commander to Mediator? If yes, continue to read, you will answer your question. But then pops another question. What is the method for changing a commander to a mediator?


Here is the solution to change Commander to Mediator. Follow the steps below:

Step 1: Edit the file. Then, change the ‘commander.url’ value to the valid commander’s address despite the ‘localhost’.

Step 2: Restart the new Mediator.

8. The Diagnostics .NET Agent installation fails when the optional Probe Aggregator Service is selected

If you select optional Probe Aggregator Service, the installation of Diagnostics .NET Agent fails. Why? Security restrictions might cause hinders with the installation of the .NET Agent.

Want to know more about the problem? Let me explain that to you. While struggling to install the Diagnostics .NET Agent, the installation process completes failing; as the optional Probe Aggregator Service is selected on the Windows Server platform.

The subsequent error gets reported in the “ProbeAggregator/log/ProbeAggregator/JSW” file:

FATAL | wrapper | 2014/04/18 16:54:03 | OpenSCManager failed – Access is denied. (0x5)

The error mentioned below might be also found in the “/setup/SetupResults” file has:

Running command: C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\bin\ProbeAggregator-windows-x86-64.exe -i “C:\MercuryDiagnostics\.NET Probe\ProbeAggregator\etc\ProbeAggregatorJSW.conf”

Error message: . Error number: 1

Probe Aggregator setup failed.

Removing temporary setup files folder: C:\MercuryDiagnostics\.NET Probe\setup\pasetupfile


The main reason behind this error is the security restrictions. Keeping in mind, the fix is here. While installing the .NET Agent with the Probe Aggregator Service, confirm the following:

The User Account Control (UAC) is disabled.

The user carrying out the installation is a well-experienced administrator.

The installer must be launched via the right-click “Run as administrator…” option.

9. How to disable RUM client monitoring on both .Net and J2EE Agent

Do you know you disable the X-HP-CAM-COLOR response header for RUM requests?

But the issue is how to disable the RUM response header (or client monitoring integration) in both J2EE and .Net Agent. Don’t worry, the solution is just below.


For .Net Probe –

For disabling response header edit the following,

.Net Probe’s etc/probe_config.xml file

And, the key will look something like this in below:

<rum enabled=”true” encryptedkey=”OBF:3pe941vx43903wre40303xxz3q6r42ob43n93wre3io03xjs40h940pc3wir3q233jur3zir3yi03zir3vc03wre3xpi3r8o3olr44na3zor3v6m3vc03zir44u03ohb3rdi3xjs3wx03v6m3zor3yc63zor3jqz3q6r3wd740vi40b53xpi3ike3wx043gp42ur3q233y3r3zwy3wx0432i42293p9p” responseheader=”X-HP-CAM-COLOR”/>

Don’t want to use the above method?

Then, simply set rum enabled=”false” and restart the app server (IIS).

For J2EE Probe –

To fix the Java problem, there is an option available during the installation time. A dialogue box says that “Diagnostics with RUM Client monitor”. After the completion of installation, choose the only way of turning it off, that is, to edit etc/dynamic properties: = false

client.monitoring.enabled = false

After completing all the above procedures, the changes will take immediate action.

10. The diagnostics server is registered to another BSM

The error message, “Diagnostics server is registered to another BSM” appears on the screen when integrating diagnostics and Business Service Management (BSM).

Wondering what the problem is? It is simple as the error message itself explains, the diagnostics server is listed as an alternative BSM. The cause of this error is, the setting “bac.registration.use.referer = true”.


To fix this error, tail the following steps.

Step 1: Open the Diagnostics Commanding Server.

Step 2: Next open MercuryDiagnostics\Server\etc\

Step 3: Change the above line to the property: bac.registration.use.referer = false

Step 4: Restart the commander.

Exit mobile version