Micro Focus SiteScope – Tips and Tricks

Micro Focus SiteScope is agentless monitoring software focused on monitoring the availability and performance of distributed IT infrastructures, including Servers, Network devices and services, Applications and application components, operating systems, and various IT enterprise components.

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

1. Micro Focus SiteScope – Tips and Tricks – Jan 2021

1. Instructions for keeping a display name for the Email ID

The display name can easily be put, as the whole email address may seem like a hassle. It has been observed that the users are unable to add through the Edit dialogue, no need to worry there are other ways as well. For setting a display name efficiently, follow the instructions given below.

A user cannot possibly use the ‘SiteScope’- Test <sitescope_admin@mycompany.com>” on the administrator’s email address, or in the From email address. The reason is that SiteScope strictly checks if you have added a valid email address or not. The email address needs to be in the format below:


If this format is not followed then the error message will keep popping on the screen. There is an unsupported way to set the display name

  1. You need to stop SiteScope
  2. Then you have to run <SiteScope>\bin\PersistencyViewer.bat
  3. After that, you need to open the Persistency file through a Graphic User Interface(GUI). You need to select a Persistency Path and then click on Open.
  4. Then you will see Filter By Type, click on:
  1. Then you select MailDefaultPreferences_
  2. After that, you need to edit the field into _fromAddress (It is an example) and press on Enter.
  3. Then you can add a display name of your choice. Do not forget to select on OK and Commit.
  4. Now you have to restart SiteScope.
  5. Then to see if this fix was effective or not, send a Test email.

2. How to deal with the unsupported or undeployed templates?

It often happens that the templates are not deployed properly or are corrupted or unsupported. There appears an error dialogue box and it says that it failed to commit. According to the users, this majorly happens when many URL monitors are being loaded while utilizing a template. The expected layout looks like:


Yet, when the procedure is initiated while utilizing a CSV file, it creates a bunch. And then the first URL monitor and then the procedure is a failure. The logs show the error given below, it is for all the consecutive URL monitors:

Error in the template ‘Bulk URL Monitor Load’ encountered:

Failed to commit – uniqueness violation – the name ‘App02’ exists in the earlier location.

You can definitely solve this error by following the instructions given below:

  1. SiteScope -> Preferences -> Infrastructure Preferences -> Template Settings
  2. And then click on check to Allow creation of template monitors directly under a template entity
  3. After that, you need to start SiteScope again.
  4. Then you will be able to make or deploy any template of your choice freely.

3. What to do when SSL configuration is unable to activate?

It often happens that SSL configuration does not run after a SiteScope version of Windows. And an error message is shown on the screen that says “Server.xml doesn’t exist. Not an upgrade scenario.” This error occurs when the Upgrader is not able to read the environment variable %SISINSTALLER_PATH% at the time of the upgrade. Due to that, the Upgrader is not able to find all the backed-up server.xml files. You can solve this issue with the help of the following steps:

  1. You need to visit %SITESCOPE_HOME%\Tomcat\conf directory to retrieve the backup of server.xml file.
  2. Then you need to replace the previous server.xml file in the %SITESCOPE_HOME%\Tomcat\conf directory with server.xml file that is available now at the following destination:
  1. Now you need to open the recent server.xml file and the find that specific section of the file that is similar to the one given below:
<Connector port="8443" server="******" compressableMimeType="text/html,text/xml,text/javascript,text/css,image/x-icon,application/json" noCompressionUserAgents="gozilla, traviata" compressionMinSize="2048" compression="on" truststoreType="%%TRUSTSTORE_TYPE%%" trustStorePass="%%TRUSTSTORE_PASS%%" trustStoreFile="%%TRUSTSTORE_PATH%%" keystoreType="%%KEYSTORE_TYPE%%" keystorePass="%%KEYSTORE_PASS%%" keystoreFile="%%KEYSTORE_PATH%%" SSLVerifyClient="true" SSLEnabled="true" clientAuth="%%CLIENT_AUTHENTICATION%%" ciphers="%%CIPHERS_LIST%%" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello" secure="true" scheme="https" debug="0" acceptCount="100" disableUploadTimeout="true" enableLookups="false" maxSpareThreads="75" minSpareThreads="25" maxThreads="150" maxHttpHeaderSize="8192"/>
  1. Now you need to replace these placeholders: %%TRUSTSTORE_TYPE%%, %%TRUSTSTORE_PASS%%, %%TRUSTSTORE_PATH%%, %%KEYSTORE_TYPE%%, %%KEYSTORE_PASS%%, %%KEYSTORE_PATH%%, %%CLIENT_AUTHENTICATION and %%CIPHERS_LIST%% with the values from the previous server.xml file that was backed-up. You can find the server.xml file backup in the destination below:

Here this location: <INSTALLER_DIR> is where we can find all the SiteScope bits.

  1. Now all you have to do is Restart SiteScope.

There is another fix that you can possibly use. For this you need to utilize the Site Scope Hardening Tool for configuring SiteScope hardening once again.

4. How to fix Uptime background related issues?

Sometimes the users experience issues with frequent skips. Fixing the monitor’s frequency in the skips can help. Also increasing the connection limit for remote servers can prove to be helpful.

The error message displayed upon the screen remains as:

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

We can utilize the algorithm “diffie-hellman-group1-sha1″ but it often happens that using this algorithm isn’t very effective with the “SiteScope should use diffie-hellman-group14-sha1 instead of diffie-hellman-group1-sha1”

Fix 1

You need to update the line in the  /etc/ssh/sshd_config file and then you need to restart the ssh


Fix 2

The most obvious cause of the UNIX remote connection failure is because of the ‘Key exchange failure’.

To establish better connectivity you can follow the instructions given below:

This fix is specifically for SiteScope server Operating System, Linux:

  1. You need to edit the Remote Unix Connection.
  2. Then replace or change the Operating System, if needed.
  3. Now you need to add a prompt through logging in, to the Server user account.
  4. After that you will see Advance, you need to change the SSH Client to the External SSH Client.

This fix is specifically for SiteScope server Operating System, Windows:

  1. First, you need to edit the Remote Unix Connection
  2. Then replace or change the Operating System, if needed.
  3. Then you need to add a prompt through logging in to the Server user account.
  4. After that you will see Advance, you need to change the SSH Client to Plink.
  5. Now you need to add a Custom Command Line: D:\SiteScope\tools\plink.exe -ssh $user$@$host$ -pw $password$

You can also disable all the monitors related to Linux servers that were malfunctioning or lagging. 

5. How to retrieve the MIBs files and bring them back to working condition?

It often happens that MIBs malfunctions and is not able to fulfil the whole task. And sometimes we experience an error saying that “Cannot get MIB file list java.lang.NullPointerException”.

There is a quite simple method to fix this issue. In some cases, it is not the MIB files but it’s another file’s fault. Try deleting “README-MIB.txt” and check if the error still persists. After that try restarting SiteScope and then load the MIB file again. You need to perform the last activity in SNMP through the MIB. This fix has proven to be quite effective.

6. Instructions to fix the connection error for monitor when there is a remote login failure

Multiple users have come across this issue when they are unable to remote login server and there is a major connection error on the screen. This problem can be easily sorted out through the steps given below, follow them carefully:

  1. Thoroughly inspect the skip monitor carefully.
  2. Then check and review the monitor count log.

If the Server Statistics log displays an issue regarding your memory heap size and changing it, you can fix that easily through these steps:

  • You need to stop any SiteScope service or activity.
  • Then you need to go to the Registry Editor, for that you can take help of this path:


Do not forget to edit the –Xms and -Xmx values to 8192

  • That being done you need to go to master.config and do some changes or addition of this given parameter, at the very end of the list: _runGPeriod=900000 
  •  This step will help you get rid of the heap and will free the memory.

Then you need to Reboot the Server.

Now you need to start the SiteScope Service.

  • After following these steps you can change just the frequency of the ‘Pharmacy’ monitors to check if this fix worked out well.  Even after these steps if in case the error and skips persist, then you need to keep changing the frequency for URL and URL sequence monitors and for DataBase monitors too.

7. Using SiteScope URL monitor to operate web pages in JSON format

SiteScope URL monitor can actually operate and cope with the Web pages that return JSON format. SiteScope URL monitor’s speciality is that it can recover the data akin to the Chrome or the Firefox Browser. For instance, if you are utilizing the URL given below:


Then surely you will receive

   "one": "two",
   "key": "value"

All of these can be tested and used on the JSON code being returned. Just a fact to remember that the Internet Explorer is not suitable for JSON format at all when it initiates to convert the response into xml or html, it fails bitterly.

8. How to tackle the problem of SVC startup on failover?

To solve any problem we need to find out the reason behind it. Sometimes SiteScope 11.51 restarts and a problem arises in the SVC startup on the failover server.  It is being observed by even the users who have recently upgraded to SiteScope 11.51. They have come across at least two unpredictable restarts all of a sudden in SiteScope upon the primary server. You can try using the fix given below to solve this issue:

  •  You can try to rejuvenate the system by clicking on the Restart button in the UI. It shows the Sheduled_restart in the logs that will show it was accurately restarted or not.

To inspect if this element is performing well, you can follow the steps below in the SiteScope 11.51

1. You need to make sure that the failover preferences are doing fine. They should work efficiently in both the direction (between Primary <-> Failover).

2. You need to find on SiteScope Primary Graphic User Interface (GUI), and then go to the Failover Preferences.

3. And on the Failover GUI, go to Failover Preferences.

4. Then you need to enable ha.loglevel=DEBUG inside the C:\SiteScope\logs\high_availability.log and failover.

a. You will need to edit the properties file in C:\SiteScope\conf\core\Tools\log4j\PlainJava\log4j.properties

Change ha.loglevel=ERROR to ha.loglevel=DEBUG/ 

5. On the primary GUI, go to the Infrastructure Preferences and then run the Restart SiteScope button on the bottom side. This is a very useful step that activates PLANNED_SHUTDOWN for this process as per the high_availability.log

9. How to solve the automatic restart of the SiteScope login window when OBM is down?

It often happens that When OBM is down and the SiteScope service is restarted and then the Welcome screen pops up. It occurs in both browsers and the SiS local client. Whenever OBM is activated, the login page is shown at the computer screen. This happens often when SiteScope is unable to interpret OBM/APM. In the error.log we can observe that the SiteScope initiates with OBM is that after:

[SiteScope Main] (SiteScopeGroup.java:633) INFO  – Starting topaz manager

Here the hindrance in the interpretation is evident.

[SiteScope Main] (ApacheHttpUtils.java:512) ERROR – problem while sending data to URL: https://<OBM>:443/topaz/topaz_api/tmc_info_query?type=integration_support error: java.net.ConnectException: Connection timed out: connect, currentRetry: 0

This continues till this shows up:

[SiteScope Main] (SiteScopeGroup.java:635) INFO  – Topaz manager started.

If by any chance OBM is not responding then SiteScope will just remain in the background: 

INFO  – Starting topaz manager

trying to reach the OBM GW server.

Monitoring process detects the lack of action after 30 minutes by default. It is programmed in a way that it will understand that SiteScope has paused and automatically restarts it.

service: Thu Nov  5 14:47:48 2020   Monitoring process, no progress change was detected

service: Thu Nov  5 14:47:48 2020   Shutdown request process successful

2020-11-05 14:47:58,978 [SiteScope Shutdown Watch] (SiteScopeShutdown.java:51) INFO  – Shutting down SiteScope reason SiteScope service is shutting down(requested by the service)…

When this procedure starts again with:

INFO  – Starting topaz manager

And after a dutiful restart past 30 minutes, OBM will react.

10. How to fix the monitor SiteScope WMI con errors?

It often happens that the WMI SiteScope monitor is not reported in OMI and the user faces difficulty while performing the tasks. This issue can be solved by following the steps given below:

  1. You need to make sure to select the Send Event on the monitor. Kindly check the audit log regularly that the modified value should be the recent one.
  2. Then we need to run the Command Prompt: find “IPSERVERADDRESS” audit.log* > CAMBIOS-14.98.TXT
  3. Then in the audit log you will see the ‘Send Event’.
  4. Now change ‘Selected’ to ‘non-selected’ can be easily found in the audit log like:

Update: ‘_prioritySelection’ updated from ‘EVENT’ to ‘MEASUREMENT’.