Micro Focus SiteScope – Tips and Tricks

5. Micro Focus SiteScope – Tips and Tricks – May 2021

1. Silent Login feature no longer working – deprecated or replaced?


For your knowledge, you should be aware that we have several SiteScope server pairs across the enterprise. Alerts from these servers to OBM, and include the stock Custom Attributes SiteScopeDrillDownURLJava and SiteScopeDrillDownURLUC plus a custom CA “cma4” (UC), and additionally in OBM create another CA SiteScopeDrillDownURL (Java console). We have OBM users who will use the UC CAs for drilldown from Chrome. Chrome is the browser we use with OBM 2020.05, and is the standard browser of the company.

They can fall back to IE, of course…but I strongly disagree. The browsers are not the main issue. Per the docs we see that the silent login is discontinued. Since we use this feature dozens of times each day, more on busy trouble days, we need to know if this option, a direct drilldown URL for a monitor via the UC without login, is actually available to users.

Our production monitoring includes six (6) SiteScope server pairs for different monitored zones in the enterprise. The silent login URL is very critical to our daily operation. But we should be concerned about our alternatives.

Here in this article, we will check the above written.


Background issue: User wants to know if Silent logging is deprecated and what are his options.


The SSO option is available in SiteScope. SSO stands for Single Sign On which is a method of access control that enables an user to log on once and gain access to the resources of multiple software systems without being prompted to log on again. If you want detailed information about SSO, here is link: https://docs.microfocus.com/itom/SiteScope:2020.05/AuthStrategies

Here are the authentication strategies for SSO supported by SiteScope.

Lightweight Single Sign-On (LW-SSO): This is embedded and is the default single sign-on authentication strategy for SiteScope. It does not require an external machine for authentication. The default passphrase string for all software applications integrated using LW-SSO should be immediately changed after installing SiteScope.

For more details on how to change the default SSO value in SiteScope, check How to change the LW-SSO string in SiteScope.

For more details on LW-SSO, including limitations, security warnings, and general reference, see LW-SSO Authentication.

Lightweight Directory Access Protocol (LDAP): Authentication can be configured using the LDAP.While using this , simultaneously you can use an external LDAP server to store authentication information (usernames and passwords). SiteScope uses the LDAP server to verify a user’s credentials.

However LDAP is temporary. You can enable and disable according to your wish from User Management Preferences. For details, see LDAP Authentication and Authorization.

2. Import/Export Sitescope Unsatisfactory

SiteScope 2020.05 is installed on a dedicated server with OS Windows Server 2016. The configuration of a SiteScope version 2018.11 is imported

Build: SiteScope 11.60.83 64-bit JVM, Build 82 However it is not transferred to the new server. No error message received during the Export or Import process. The logs will be uploaded to the FTP of the case


Background issue: User is migrating SiteScope 11.60 from one server to another in SiteScope 11.92 (2020.05) User exported the .zip file using the config.tool but had issues importing that file.

Follow the below written steps:

Step 1: Config backup file was created in SiteScope 2018.11 (11.60) using the config tool.

Step 2: Stop SiteScope in “Services”

Step 3: RUN config.tool (with admin rights): \SiteScope\bin>config_tool.bat

Step 4: Click in “Select” searched folder “SiteScope” and “Open”

Step 5: Next box was located the path to place the .zip file backup : C:\backup.zip

Step 6: We added the passphrase (recent versions is required to encrypt the data), 6 characters minimum

Step 7: Copied : “backup.zip” to server destiny.

Step 8: STOPPED SiteScope in “Services” in the server destiny

Step 9: RUN config.tool (with admin rights): \SiteScope\bin>config_tool.bat –>for server’s destiny

Step 10: Selected “Import Configuration”

Step 11: Choose “Use existing exported configuration file” provide backup’s zip file “Selected” : C:\Users\”USERNAME”\Desktop\backup.zip

Step 12: We added previou passphrase.

Step 13: Unchecked “importing data from a SiteScope installation prior to 2018.05 (11.50)” because it comes from 11.60

Step 14: Before getting started the SiteScope Service , we went to the master.config and suspend all the monitors and reviewed the IP or FQDN configured:


Suspend monitors

Changed from _suspendMonitors= to _suspendMonitors=true

Reviewed IP from these values by the required FQDN for the customer to the actual server in SiteScope version 2020.05:

_adminURL =




Reviwed the tomcat folder and server.xml values: Tomcat>conf>server.xml and check that “defaultHost=”localhost”” for name=”Catalina”.

Do you want to install Manual SiS 11.33. Follow the below written steps.

Step 1: Stop the service to allow deletion of all files. (stop OM agent also)

Step 2: Rename or delete the entire SiteScope folder (Sitescope_old).

Step 3: Use MS cleanup tool (msicuu2)

• To remove every new SiteScope 11.x package registration install in the server the MS tool called Windows Install Cleanup. Download it from here.

Launch the App and select all components with the word “SiteScope” (notice some other non-SiteScope HP components may appear):

To remove the registration of SiteScope as a program installed in the control panel list remove the following registry keys; they are the most important ones looked for by the “Install Anywhere” installer:

Step 4: Delete Windows registry keys (regedit)


HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Hewlett-Packard (SystemHealth only 64-bit OS)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HP SiteScope àor SiteScope.

The Control Panel needs to be checked in order to make sure that all SiteScope patches or core products are removed. Sometimes they stay on the list, just double click to show the remove message.

Step 5: Delete the following file C:\WINDOWS\vpd.properties (older versions of Sitescope)

Step 6: Go to START in Windows and type : %TMP% and remove all temporary files

Step 7: Reboot the server

Step 8: Before Start the SiteScope Service Run the config.tool and select “sizing” : In microfocus.com, itom > SiteScope:2020.05 > SizingSiSWinPlatform

In microfocus.com, itom > SiteScope:2020.05 > SiSCapacityCalculator

SiteScope Capacity Calculator

SiteScope includes a tool that helps you predict system behavior and perform capacity planning for SiteScope. You enter the CPU and memory details of the system on which SiteScope is running, and the number of monitors of each type and the frequency that they are to run.

The calculator then displays the expected CPU usage and memory usage for each monitor type, and the recommended system requirements for the given workload. This enables you to determine whether your configuration requires tuning.

3. Status Minor and Critical APM 9.51

There are several MINOR and Critical alerts in APM, as attached prints. I need the correct setting so that the alerts are just as “ok”.


Background issue: There are several MINOR and Critical alerts in APM, as attached prints. I need the correct setting so that the alerts are just as “ok”.

RUM (Real User Monitor Engine).

The System Health has a critical status for the Entity: Snapshot Jobs Alive Count

Solution Suggested:

In softwaresupport.softwaregrp.com, doc KM1457033 > fileName=hp_man > BSM_920 > RealUserMonitor_Admin_pdf.pdf (chapter 5, page 91)

Entity: Snapshot Jobs Alive Count

Description: The total number of open snapshot jobs waiting to be processed

Critical Status (Red): RUM might not be able to process all the snapshots

In softwaresupport.softwaregrp.com, doc KM03163971 > fileName=RealUserMonitorAdmin.pdf (chapter 8 , page 83)

Entity: Snapshot Jobs Alive Count

Description: The total number of open snapshot jobs waiting to be processed.

Critical Status (Red): RUM might not be able to process all the snapshots.

Troubleshooting: In APM, check the snapshot configuration (EUM Admin > End User Management > Data Collection > Snapshot collection) and ensure that a reasonable number of pages back are configured for snapshots.


In APM, check the snapshot configuration (EUMAdmin > EndUser Management >  DataCollection > Snapshot collection) and ensure that a reasonable number of pages are configured for snapshots. (limit them)

4. SiteScope 11.92 / 2020.05 – Quick Reports Not Displaying

The quick Reports are not displayed in SiteScope 11.92 / 2020.05. After upgrading, no other browser or SiteScope client tools are displaying Quick Reports.

All other reports work as expected (daily email reports via email, management reports, alert reports etc…).


Users are now using the default password for the keystore. The reason behind not displaying the reports is because the below keys contain a wrong password value for the keystore that is,



This issue can be resolved after updating the keys with the correct passwords.For this you need to follow the below written steps:

Step 1: Stop SiteScope.

Step 2: Create a backup of the configuration.

Step 3: Update following keys with the keystore password in <SiteScope>\groups\master.config:



Step 4: Start SiteScope and test the reports.

After this the Quick Reports will be displayed without any issues.

5. Need to know if any components in the attached spreadsheet are required

There are some vulnerabilities attached to the spreadsheet on our APM servers. Our security organization has already identified it. This needs to be removed. But before taking any step we need to be assured if any of these components are required by the APM software or if they can be removed from the system completely.


Background issue: Our security organization has identified the vulnerabilities in the attached spreadsheet on our APM servers. I need to know if any of these components are required by the APM software or if they can be removed from the system completely.

We have checked your post regarding the Java patch for JRE used by APM 9.51 UI. Are you using version 1.8.0_161? You can find out from Java control Panel:

<>APM 9.51 recommendation for JRE,

In microfocus.com, itom > Application Performance Management:9.51 > ClientSysReq


APM DPS Windows Server 2012 R2 Standard 64 bit Edition SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST).SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST).

This vulnerability cannot be explained in such a few words. This article is just an overview. If you want more details on this, it is available in the external links at the end.


• It is technically an attack against a single browser, not the server. The most likely goal of an attack is to retrieve an encrypted session cookie in order to hijack a user’s session.

• While a “practical” attack has been demonstrated, it is not a simple attack. It involves man-in-the-middle network access in conjunction with a certain amount of control over the user’s browser to have it make repeated requests with content under the attacker’s control, as well as heavy real-time computing power. The attack vector was known previously but not considered usable.

• The attack applies only to CBC (cipher block chaining) algorithms as implemented in SSL 3.0 and TLS 1.0. The streaming cipher RC4 is not vulnerable, and newer versions of TLS implement CBC in ways that are resistant to this attack. However, some cryptographers consider RC4 weaker than the CBC algorithms (AES and DES), while implementation of TLS 1.1+ is uncommon.

• Browser (and component) makers are taking steps to close the vectors that allow attackers the kind of access needed and implement TLS 1.1+.

It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services.


A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system.

TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.

This plugin tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite and then solicits return data.

If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable.

OpenSSL uses empty fragments as a countermeasure unless the ‘SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS’ option is specified when OpenSSL is initialized.

Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendExtraRecord.

Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not be, depending on whether or not a countermeasure has been enabled.

Solution is, 

Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported.

Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available.

Note that additional configuration may be required after the installation of the MS12-006 security update in order to enable the split-record countermeasure. See Microsoft KB2643584 for details.



Negotiated cipher suite: AES128-SHA







I understand from your post that you are referring to the JRE version used by the client for APM UI that needs to be patched, because both APM GW & DPS uses openJDK and not Oracle Java.

c:\HPBSM\JRE\bin>java -version

openjdk version “1.8.0_212”

OpenJDK Runtime Environment (Zulu (build 1.8.0_212-b04)

OpenJDK 64-Bit Server VM (Zulu (build 25.212-b04, mixed mode)

I currently use JRE 1.8.171 or even higher versions without any problems accessing APM UI.

On the other hand, using the APM 9.51 Local Java Client brings its own OpenJDK:

F:\Software\APM9.51\apm_local_client_win\java\bin\java -version

openjdk version “1.8.0_181”

OpenJDK Runtime Environment (Zulu (build 1.8.0_181-b02)

OpenJDK 64-Bit Server VM (Zulu (build 25.181-b02, mixed mode)

6. Error in metrics Uptime

The team introduces the Uptime event, which generates an automatic message seeking a ticket from the tower. When doing the review, the Windows tower documents the ticket with documentation that the equipment has been turned on for 21 days with no reboots, and it is double-checked by phone with said tower that the monitored hostname and IP are correct.

The metric setting in Sitescope is examined, and it is found to be properly configured, with the counter time indicating that the Uptime is around one and a half days. Please double-check because the time on the server and the metric, which will trigger the request to the tower, differ.


Background issue: customer has issues with uptime

SiteScope: 11.33

Puerto de SiteScope: 8443

Windows Server 2012 R2

Solution suggested:

Customers have performance issues with skips, it was suggested to fix the monitors’ frequencies in skips and increase the connection limit for remote servers.

Action Plan:

Plan de Acción para servidores Linux en error -1:

Getting the error:

“Attempting SSH V1 connect SSH V1 connect failed Attempting SSH V2 failed remote command error (-1) remote command error (-1) “.

Using the algorithm “diffie-hellman-group1-sha1″ works but using “diffie-hellman-group14-sha1” fails with

“SiteScope should use diffie-hellman-group14-sha1 instead of diffie-hellman-group1-sha1”

Solution see,

ommunity.microfocus.com > t5 > Operations-Bridge-User > Remote-connectivity-via-ssh-no-longer-works-on-SiteScope-11-32 > td-p > 238976

Workaround 1:

community.microfocus.com > t5 > Operations-Bridge-User > Sitescope-11-24-unable-to-connect-to-remote-ubuntu-server > td-p > 1620392

Update below line in /etc/ssh/sshd_config file and then restart ssh


Workaround 2:

Connection error occurred: Key exchange failed.

Possible root cause of a UNIX remote connection attempt failed due to “Key exchange failed”.

A new remote UNIX server is not connecting via SSH, the connection fails and the following message is written to logs:

Mon Dec 05 05:33:30 EST 2011 SSH internalConnectV2: A Connection error occurred: Key exchange failed: Failed to connect to server: Connection refused: no further information (uc).

Testing connectivity with PuTTy tends to work, however mindterm also fails with the same error message:

Key exchange process has nothing to do with key file authentication. The process is performed for all types of authentication methods. On the first time a SSH client connects to a server there is an exchange of keys that identifies each server.

On the server side these client keys are stored and checked the next time the client tries to connect. If the file or the key itself gets corrupted on the server side it will not trust the client identity any longer and connection will be refused.

This key exchange failure might be related to a corrupted key assigned to SiteScope server IP on the target side. These SSH keys are stored normally in /etc/ssh/ssh_known_hosts or, more likely, /home//.ssh/known_hosts (for OpenSSH software). All SSH software providers should have equivalent files, as per the key exchange process is part of the SSH protocol.

Removing the whole file or just the line assigned to the SiteScope server IP or hostname will force a new key exchange as in the first time attempted.

Workaround 3:

Below changes were made to establish connectivity

Sitescope Server OS == Linux:

Step 1: Edit the Remote Unix Connection

Step 2: Changes OS (if needed)

Step 3: Add prompt by logging into the server using the account. e.g. (:~>)

Step 4: Under Advance change the SSH Client to External SSH Client

Sitescope Server OS == Windows:

Step 1: Edit the Remote Unix Connection

Step 2: Changes OS (if needed)

Step 3: Add prompt by logging into the server using the account. e.g. (:~>)

Step 4: Under Advance change the SSH Client to Plink

Step 5: Add Custom Commandline – D:\SiteScope\tools\plink.exe -ssh $user$@$host$ -pw $password$.

Action Plan 2:

• Disable monitors related to Linux servers that are failing and causing handle counts and skips.

Next steps: we agreed to the next webex session next friday to check the action plan results.

7. ERROR – Can’t get MIB file list java.lang.NullPointerException

In the logs it is displaying the following message

2020-10-22 13: 00: 18,826 http-bio-443-exec-2 ERROR - Could not parse: TRIPPLITE.MIB Duplicate module: file: /// D: /SiteScope/templates.mib/README-MIB.txt: 1: 1: TRIPPLITE is already defined when adding: file: /// D: /SiteScope/templates.mib/TRIPPLITE.MIB:12:1:TRIPPLITE2020-10-22 13: 00: 19,388 http-bio-443-exec-2 ERROR - Can't get MIB file listjava .lang.NullPointerException and the mibs are in the indicated paths.


Background issue: MIBs are not working :

2020-10-22 13:00:18,826 [http-bio-443-exec-2] (MergeParserPhase.java:116) ERROR – Could not parse : TRIPPLITE.MIB Duplicate module: file:///D:/SiteScope/templates.mib/README-MIB.txt:1:1:TRIPPLITE is already defined when adding: file:///D:/SiteScope/templates.mib/TRIPPLITE.MIB:12:1:TRIPPLITE2020-10-22 13:00:19,388 [http-bio-443-exec-2] (SnmpUtil.java:657) ERROR – Can’t get MIB file listjava.lang.NullPointerException

Here is the solution. There is a file regarding issues not related to MIB files: “README-MIB.txt”.  Therefore we removed, restarted SiteScope and reloaded the MIB file in the SNMP by MIB monitor and this worked. Now there’s nothing to be worried about.


Users are unable to remote login error servers. There is a connection error for the monitor. This can turn out to be serious if not looked into now.


Background issue: Connection errors and skips

SiteScope version 11.41

Memory 16 Gigabytes

• We checked the skip monitor and found several skipped monitors.

• We reviewed the monitor count log.

Server Statistics log shows you are required to change the memory heap size.

Action Plan 1:

• Increase the Java heap size in the SiteScope server. This can be done by the following steps:

Step 1: Stop SiteScope service.

Step 2: Go to the Registry Editor and follow this path:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HPSiteScope\serviceParam].Edit the -Xmx and -Xms values (both them) to 8192

Step 3: Go to the master.config and change or add this parameter at the end of the list:

Garbage collector se usa cuando hay problemas de performance:

_runGPeriod=900000 –> to free memory

Step 4: Reboot the Server.

Step 5: START the SiteScope Service.


As we agreed for now you will change just the frequency from “pharmacy” monitors to check if after those changes it continues failing. If after all these steps, skips and false alerts continue, it will be necessary to change the frequency for URL and URL sequence monitors and Database monitors as well. User modified the Polling interval for the Pharmacy Monitors and it looks good.

9. Sitescope SQL DB table not getting updated

The SQL DB table is not getting updated in SiteScope. There may be some issues regarding the update. Sitescope SQL DB table not getting updated


Background issue: Sitescope SQL DB table not getting updated. User was working with the SiteScope DataBase tool connecting to a SQL DataBase. The DataBase was enabled, but not data was stored in the DataBase

SiteScope version 11.91 (2019.11)

This solution from Oracle was applied for SQL and worked successfully.

Solution:softwaresupport.softwaregrp.com > doc KM03092343

We can see that the table was created in the database, but no data was inserted .

SiteScope – Database logging has been enabled, but no data is stored in the DB

enabled debug by adding the following statements to \conf\core\Tools\log4j\PlainJava\log4j.properties

The issue is caused by the database. The error in the log file shows that SiteScope tries to create a database table which already exists. Other errors showed that SiteScope tries to insert data to a table which didn’t exist and also that it tries to insert data to a table which has wrong columns. You can resolve these issues by recreating the table. Here you go:

Step 1: Stop Sitescope service.

Step 2: Drop the empty table on the database side.

Step 3: Modify \groups\master.config and change the table name in create table and insert table to a different table name, in the example below the table to be used is called SiteScopeLog_01

_logJdbcCreateSiteScopeLog=CREATE TABLE SiteScopeLog_01 (datex VARCHAR(255), serverName VARCHAR(255), class VARCHAR(255), sample VARCHAR(255), category VARCHAR(255), groupName VARCHAR(255), monitorName VARCHAR(255), status VARCHAR(255), monitorID VARCHAR(255), value1 VARCHAR(255), value2 VARCHAR(255), value3 VARCHAR(255), value4 VARCHAR(255), value5 VARCHAR(255), value6 VARCHAR(255), value7 VARCHAR(255), value8 VARCHAR(255), value9 VARCHAR(255), value10 VARCHAR(255))



_logJdbcInsertSiteScopeLog=INSERT INTO SiteScopeLog_01 VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Step 4: Start SiteScope service.Once Database was recreated the data come to the table: SiteScopeLog_01 from DataBase: SITESCOPE_DSO

• Failover was mirrored:

• Server was removed from SMTP connector (SMTP Connector. SMTP is a protocol for transferring outgoing email messages from one server to another and also to accept email messages from other mail servers and email clients.)

10. SiteScope on Linux – Unable to start Sitescope after upgrading from 11.41 to 11.90

The new SiteScope upgrade seems to have some problems. Users are unable to start SiteScope on Linux after upgrading from 11.41 to 11.90. After the update SiteScope cannot be started anymore in the normal way,via <Sitescope>/start. The problem is that SiteScope 11.41 on Red Hat Linux has been updated to 11.90

When executing ./start, it works for some time, then it will return. SiteScope cannot be started as a background process. Nothing gets written into error.log or any other logfile. As a workaround they started SiteScope via <SiteScope>/bin/go.sh.Restarting the OS didn’t resolve the issue.

If one starts SiteScope via ./start, it first starts the service via start-service exec ../java/bin/java .. -DSiteScope=true ${FAILOVER} -cp ${CLASSPATH} com.mercury.sitescope.bootstrap.Service $$ $@ which then calls /bin/start-monitor which in the end starts the core of SiteScope via p exec ../java/bin/SiteScope -server .. org.apache.catalina.startup. Bootstrap starts so the main difference between running start and go.sh is the service process start-service / com.mercury.sitescope.bootstrap. Service,which seems to die here.

To better follow what the script does,

change the script <SiteScope>/start as follows:

change the first line



#!/bin/sh -x

   and the line 

if [ “X$1” = “X-i” ]


# if [ “X$1” = “X-i” ]

if true;;

(comment out the first line, and add the second on, then start-service is started with the -i option and also outputs error to the screen)

save the file

start SiteScope via ./start

wait some time, then capture the output on the screen

The result is



++ dirname ./start

+ ROOT=.

+ test -s ./groups/pid

+ ‘[‘ 1 -eq 0 ‘]’

+ test -s ./groups/monpid

+ ‘[‘ 0 -eq 0 ‘]’

++ cat ./groups/monpid

+ PID=0

+ /bin/ps -p 0

error: process ID out of range


ps [options]

Try ‘ps –help <simple|list|output|threads|misc|all>’

  or ‘ps –help <s|l|o|t|m|a>’

for additional help text.

For more details see ps(1).

+ ‘[‘ 1 -eq 0 ‘]’

+ true

+ cd ./bin

+ ./start-service -i

Error: Password file read access must be restricted: /opt/HP/SiteScope/java/lib/management/jmxremote.password


        at sun.management.jmxremote.ConnectorBootstrap.checkPasswordFile(ConnectorBootstrap.java:577)

        at sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:426)

        at sun.management.Agent.startAgent(Agent.java:262)

        at sun.management.Agent.startAgent(Agent.java:452)

The first error can easily be ignored:

the pid and monpid files do not exist, this the script tries to execute

  ps -p 0

which is invalid and fails.

What’s more important however is the second error

Error: Password file read access must be restricted: /opt/HP/SiteScope/java/lib/management/jmxremote.password


        at sun.management.jmxremote.ConnectorBootstrap.checkPasswordFile(ConnectorBootstrap.java:577)


  stackoverflow.com > questions > 19220442 > jmx password read access issue


Make sure the user you are using to run the java process has access to the file (owner/read permissions).


  chmod 600 jmxremote.password


however changing the permissions doesn’t resolve the issue.


Follow these commands to remove all directives with “jmxremote” in it.Change in



/opt/HP/SiteScope/java/bin/SiteScope -server -Xmx12288m -Xms12288m -Dcom.sun.management.jmxremote.port=28006 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xss256k -XX:MaxPermSize=240m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-DoEscapeAnalysis -showversion -Dsun.net.inetaddr.ttl=0 -Dnetworkaddress.cache.ttl=86400 -Dnetworkaddress.cache.negative.ttl=0 -cp "../Tomcat/bin/bootstrap.jar:../Tomcat/bin/tomcat-extras-juli.jar" -Dcatalina.base="../Tomcat" -Dcatalina.home="../Tomcat" -Djava.security.auth.login.config=../conf/jaas.config -Dtopaz.home=.. -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl -Djava.util.Arrays.useLegacyMergeSort=true -Djava.security.manager -Djava.security.policy="../conf/security/sitescope.policy" org.apache.catalina.startup.Bootstrap start



Perform a similar change in the script start-service and start-monitor

After this change the startup doesn’t check /opt/HP/SiteScope/java/lib/management/jmxremote.password anymore, and SiteScope starts up fine.