Micro Focus Application Performance Management – Tips And Tricks

Table of Contents

2. Application Performance Management – Tips And Tricks – Jan 2021

1. Instructions to solve the message Server is NOT a READY error

Users often come across an error in ALM 9.51 that says the message Server is NOT READY. It usually happens in the BSM Status GUI of the system. Certain indicators mean that the JBoss is not activating:

The status page returns the “Server is not ready” message.

Processes are not loading.

The wrapper.log file from the <HPBSM>\log\supervisor folder contains this error:

“Error: Password file read access must be restricted: c:\HPBSM/JRE64/lib/management/jmxremote.password”

This error usually occurs because of the Windows Management Instrumentation command-line(WMIC) malfunction, along with various regional settings. Due to its inefficiency, the ownership and permissions (files jmxremote.access and jmxremote.password) are badly affected. 

This issue can be easily solved; you simply need to follow the steps given below:

  1. You need to end all the processes of APM and disable it.
  2. Then go to <APM root directory>\JRE\lib\management.
  3. Then you need to right-click on jmxremote.password and then click on the Properties.
  4. Then you need to click on the Security tab.
  5. Then click on Edit, then select Add, and now you need to add the Administrators group.
  6. Then you need to allow the Read and Write permissions for the Administrators group.
  7. Then you need to repeat steps 2 and 7 for the jmxremote.access file.
  8. Then you need to go to <HPE APM root directory>\JRE64\lib\management.
  9. Then you need to repeat steps 3 and 7.
  10. Now you need to enable APM.

2. Error after moving the Oracle DB server

It is observed that when the DB server is moved to a new system, no data is shown in the EUM Application overview displays. After closely following the installation Guide’s appendix and the many post-install wizard and config wizard runs. After a detailed inspection, it is noticed that the pmanager is not performing well. It is recommended that the user refers to the logs that are attached for the errors. It could be due to running the DBVerify tool that these errors appeared. 

This issue can be solved with the help of the steps given below:

  1. Then you need to stop pmanager.
  • You need to check log/pmanager/pmanager.log to make sure if the pmanager is present in Sleep mode.
  • If the pmanager is indeed in sleep mode, you need to Stop Partition Manager service using DPS JMX. For this, you can use: http://localhost:11021/invoke?operation=showServiceInfoAsHTML&objectname=Foundations%3Atype%3DNannyManager
  1. Then you need to take a backup of the following tables using the following commands:
-- pm_config table of Management database
create table pm_config_bkp as select * from pm_config;
-- pm_catalog and pm_native_catalog tables of Profile schema
create table pm_catalog_bkp as select * from pm_catalog;
create table pm_native_catalog_bkp as select * from pm_native_catalog;
  1. Then you need to execute the SQL on Management database that are given below:

These will help you to take out some of the old config rows (that are related to BPI and TV/Transaction vision) from PM_CONFIG table: PM_CONFIG table:

delete from pm_config
where PM_ENTITY in (
  1. On the Profile database, you need to initiate the attached script pm_regenerate_ora.sql. And when there is a notification to enter input value, you need to enter ALL_TABLES and then enter.

To execute this particular script, you need to note that it must be connected as a PROFILE schema using a sqlplus for SQLDeveloper client.

  1. Then you need to Start Partition Manager Service using the DPS JMX.
  2. And then you need to make sure that there are no errors in the /HPBSM/log/pmanager/pmanager.log.

If you need to initiate the script pm_regenerate_ora.sql on SQLPLUS client after the connection to the PROFILE schema, you must put the command given below:


After that, the dialogue on the screen will need you to enter the table name, so you need to enter ALL_TABLES.

3. The Post Install step is observed to delete /opt/HP after the completion of the installation in Linux

It often happens in BPM 9.51 and later on Linux that the Post Install step deletes /opt/HP after the completion of the installation automatically

This problem can be fixed while keeping some things in mind. While installing BPM 9.51, BPM 9.52, or BPM 9.53 on Linux,

the installer, when it is done with all previous steps, should run the PostInstall step. Which enables the postinstall_bpm.sh file.

The script postinstall_bpm.sh contains

   if [ -d $FOLDER ]; then
echo "Deleting $FOLDER"
rm -rf $FOLDER

It automatically means that it deletes /opt/HP with all files underneath on its own. It is problematic because those files may have some products installed into it, like SiteScope or BSM.

Users need to install the 9.51 version of B and the newest version on Linux, only when nothing is found under “/opt/HP”,

or as the first application.

There is also a hotfix available from the support for BPM 9.53, it can also be used with BPM 9.51 and 9.52.  

4. When APM is unable to get data from RUM in the reports

When users are using the APM 9.51.151, Build 164 on Windows 2012 R2. It is noted that they encounter an issue getting data from Real User Monitor reports. Every report says, “There was a problem retrieving data from the Real User Monitor engines.”

Users are able to log into the RUM Engine GUI and also update the configuration without any problem. They can also keep records of the RTSM-Integration user password easily. The problem arises when they are unable to get the data from RUM reports. 

The users can solve this issue by following the steps given below:

  1. You need to stop the RUm service and navigate to the DIR given below on the Engine Machine:
  1. Then you need to edit the users.xml file then replace the encrypted password field with the password, and then add a new password. 
  2. You need to save the changes and then restart the RUM Engine.
  3. After that, you need to open the Engine JMX console.
  4. Now type your new username/password, the one you recently changed, and access and note it down.
  5. Then open BSM UI – BSM – Admin – End User Management – Setting Tab – Real User monitor Setting Tab – then click on the relevant engine.
  6. Then you need to mark “Override default connection settings.”
  7. Then you need to type username/password from step 2.
  8. Once executing the steps above is done. You now need to restart APM first and then the RUM engine.
  9. Now you need toResync the configuration :

First, select Tools and then on Monitoring Configuration Information, and then you need to Sync All.

5. Solving the ‘undetected installation’ issue due to which the UFT scripts fail

It is observed that BPM 9.53 on Windows 10 has an undetected installation issue that eventually causes UFT scripts to fail.

Users have noted that after BPM was installed, the specific integration with the UFT works rhythmically.

UFT is able to record and replay scripts, and BPM can play the scripts efficiently too. Yet few issues were detected when BPM runs on Windows 10.

The issues have only been observed on Windows 10, all works fine and as expected when BPM is running on Windows 2016.

  1. It was observed that running a script on our own from BPM Admin shows that the script is running but later on BPM shows, “no data received”. 
  2. The running script from the said schedule from APM shows the same script running (as the one above).

The files were duly copied from the BPM folder to the LG folder, the solution:

  1. You need to stop BPM
  2. Then make backup copies of the files below:

3. Then you need to copy the files given below:

<BPM_HOME>\dat\mdrv.dat -> <LGSA_HOME>\dat\mdrv.dat
 <BPM_HOME>\bin\bpm.dll  -> <LGSA_HOME>\bin\bpm.dll
  1. Now you need to start BPM.

After these steps, the scripts are executed as per the requirement and according to the report data.

6. Dealing with the ‘Probe does not start – not responding’ error

Users come across this specific error in RUM 9.40, that says: 

The probe does not start – not responding

RUM Sniffer probe refuses to start.

Status is not responding.

Nothing is updated in capture.log.

watchdog.log contains

2020-11-03 15:35:06,925 RUMProbeMonitor WARNING rp_monitor.py No ping failure :
2020-11-03 15:35:06,926 RUMProbeMonitor WARNING Restarting Probe

Status showing “not responding”

[[email protected] rum_probe]# /etc/init.d/rum_probe-capture status
HPRUMProbe is not responding.

It is reported that the users have even tried to empty the folders mentioned below, but that went without any success:

rm -rf /var/spool/rum_probe/channels/*
rm -rf /var/spool/rum_probe/cache/*
rm -rf /var/spool/rum_probe/rawstorage/*
rm -rf /var/spool/rum_probe/capture/*
rm -rf /home/rum_mprobes/AdditionalProbe1/var/spool/rum_probe/channels/*
rm -rf /home/rum_mprobes/AdditionalProbe1/var/spool/rum_probe/cache/*
rm -rf /home/rum_mprobes/AdditionalProbe1/var/spool/rum_probe/rawstorage/*
rm -rf /home/rum_mprobes/AdditionalProbe1/var/spool/rum_probe/capture/*

In the RUM version 9.40, a specific feature was recently added. That is able to generate the kernel filter based on the Application configuration itself.

In this situation the configuration string that was generated automatically exceeded the maximum length that was, which caused the probe act up,

capture.log shows the details below:

2020-11-05 14:35:58 [139849672312736] INFO  collector.MasterConfig <collector/config/MasterConfig.cpp:2782> - initialize log appenders
2020-11-05 14:35:58 [139849672312736] INFO  collector <collector/main.cpp:295> - JIT is supported by regular expressions library.
2020-11-05 14:35:58 [139849672312736] INFO  collector <collector/main.cpp:331> - XPath API initiated.
2020-11-05 14:35:58 [139849672312736] WARN  entropy.bbtime <entropy/BBTime.cpp:25> - System Time Calculation using vm:  false
2020-11-05 14:35:59 [139849672312736] WARN  collector.MasterConfig <collector/config/MasterConfig.cpp:1592> - Setting global_skip_checksum = 1
2020-11-05 14:35:59 [139849672312736] WARN  rules.RuleProcessor.config <collector/rules/RuleProcessorBuilder.cpp:230> - Missing granularity in cs-rummobileos
2020-11-05 14:35:59 [139849672312736] WARN  rules.RuleProcessor.config <collector/rules/RuleProcessorBuilder.cpp:230> - Missing granularity in cs-rummobiledevice
2020-11-05 14:35:59 [139849672312736] INFO  collector <collector/PostOffice.cpp:74> - Starting channel rum-pages.
2020-11-05 14:35:59 [139849672312736] INFO  collector <collector/PostOffice.cpp:74> - Starting channel rum-ud-discovery.
2020-11-05 14:35:59 [139849672312736] ERROR collector.MasterConfig <collector/config/MasterConfig.cpp:966> - Unable to parse kernel filter: (( port 80 ) or ( (  or host or host or host ) and port 443 )) or (vlan and (( port 80 ) or ( (  or host or host or host ) and port 443 ))) :[collector ]
2020-11-05 14:35:59 [139849672312736] ERROR collector.MasterConfig <collector/config/MasterConfig.cpp:966> - Unable to parse kernel filter: (( port 80 ) or ( (  or host or host or host ) and port 443 )) or (vlan and (( port 80 ) or ( (  or host or host or host ) and port 443 ))) :[collector ]
2020-11-05 14:35:59 [139849672312736] WARN  collector <collector/main.cpp:401> - Errors occurred during startup (RUM(r) probe Capture v9.40.10.0171 Linux x86_64 r19913)

You need to follow the instructions given below to fix this issue carefully:

  1. You need to navigate to the Beatbox Conf file of all of your probes
  2. Then you need to do an addition of the line given below in the (collector) section:

enable_full_kernel_filter false

  1. Then you need to visit the RUM UI to find Tools.
  2. After that, you need to select  Monitoring Configuration Information.
  3. And then click on Sync All Configuration.

After these steps, you need to restart all the probes and the engine and then check the connection once more.

7. Instructions to fix the APM local client crash

It often happens with the users that when they are using a local client for APM and view MyBSM, Top View, End User Monitors, it does not work. The login Expiration notice is shown on the screen, and the APM local client crashes. This could occur when other pages other than the current one are open in the background. Some users have tried to fix it with the initiation of the local client 13:03, and it still crashes after an hour. 

You can solve this error by the steps given below:

  1. You need to log in from BSM GW Server to the JMX-console: http://:29000/jmx-console.
  2. Navigate to the service: LW-SSO Configuration.
  3. Then you need to find the value for the Expiration Period in the table provided. It should probably be 60 by default and should be in minutes.
  4. Then you need to edit the value and change it to 999999.
  5. Then you need to select the Apply Changes option.
  6. Then make sure if 999999 is the value when you login into JMX using another GW.
  7. Then you need to Log out and then select the red cross icon top right corner of the screen to close the browser.
  8. Then you need to log in again and carefully check all the details.

8. Resetting the JMX admin ID password

The users observe that they were able to login to the JMX console easily but often encounter some errors. It occurs even when they have used the correct ID and password.  The error message on the screen says, below:

--error message--MX4J - Exception Code: 403 Message: Authentication failed.

The solution for this seems to be changing the JMX console password, It could be done with the use of the Configuration Wizard. You can reset the password by following the steps given below:

  1. You need to stop the Web Server.

If you are using an embedded Apache Web Server, you need not follow this step at all.

  1. Then you need to stop HPBSM Gateway servers and then the Failover DPS server.
  2. And then stop the Primary DPS server and run the Configuration Wizard on each and every server.
  3. After that, you need to start the Primary DPS Server and then the Failover DPS server.
  4. At the end carefully start HPBSM Gateway servers.

9. Solving the ‘Error after upgrading to APM 9.50’ error

‘Error after upgrading to APM 9.50’ is often displayed on the screen after the APM upgrade. It is known to be a problem regarding the  Access Protection and On-Access Scanner. Initially, while upgrading, there were no issues, but the DP server did not start at all. The error is shown below:

"Failed pre-initialization tasks, will not start BSM! Error:java.io.IOException..."

In order to solve this issue, an exception rule/policy needs to be created for the prevention of the Protection and On-Access Scanner to hinder the BSM processes during the startup progress.

  1. Then you need to make an exception to exclude all of the content from the main C:\HPBSM\ folder, not a specific list of .exe files.

This is necessary due to the fact that the .exe files are used in the startup process and can change according to the particular deployment settings.

In case a different module is activated, then a brand new .exe can be added to this process, and a third-party AntiVirus software could stop it.

10. Solving the starting error of APM in the APM version 9.51

It often happens that users are unable to start APM in the APM version 9.51. The error message that is displayed upon the screen is written below:

APM failed to start.

An error occurred when accessing jmxremote.password.

This error usually appears in the folder location given below:

<HPE APM root directory>\log\supervisor\wrapper.log.

This starting error can easily be tackled by taking some measures. The user who executes APM also needs to be the owner of the jmxremote.access file. They also need to have permission to read/write on this file. After these measures are taken, the user can overcome the APM starting error.