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:
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:
The user needs to closely follow the steps given below:
- The user needs to keep a backup copy of the Java service wrapper configuration file
- 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:
- 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:
- Then the user needs to save the Java service wrapper configuration file
- 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/dynamic.properties:
html.cm.enable = 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 +TLSv1.2 +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:
- The user needs to add the following by default to the webserver.properties 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 cipher.suite.filters=\ exclude:.*DHE_RSA_WITH_3DES.*,\ exclude:.*ECDHE_RSA_WITH_3DES.*,\ exclude:.*RSA_WITH_3DES.*,\ exclude:.*RC4.*,\ exclude:.*anon.*,\ exclude:.*WITH_NULL.*,\ exclude:.*WITH_DES40.*,\ exclude:.*WITH_DES.*,\ exclude:.*RSA_WITH_AES.*,\ exclude:.*RSA_WITH_CAMELLIA.*,\ INCLUDE:.*
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.
- The user needs to remove the embedded probe from the probe aggregator, this will help the aggregator service to start perfectly.
- 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.
- 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).
- 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:
- The user needs to stop and remove the previous IAPA and Operations Agent on the Diagnostics Commander.
- Then you need to erase everything in the installation directories.
- Carefully install Operations Agent that comes along with the Diagnostics and the IAPA components again.
- The user needs to restart the Operations Agent on the DPS and GW servers.
- 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
- 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 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: java.io.IOException: There is not enough space on the disk
This error can be fixed, the user simply needs to follow the steps given below:
- 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.
- 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.
- 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:
- The user needs to navigate to MercuryDiagnostics\Server\etc\webserver.properties and open it.
- Then you need to change this line to the property: bac.registration.use.referer = false.
- 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:
- 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.
- 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\dispactcher.properties 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.