Script Monitor Errors When String “not found” Is Parsed

When running a script on any OS environment, the tool and monitor both fail to execute the script when the output contains the string: "not found". However if the output contains: "Not found", SiteScope doesn’t fail.

The script can be manually executed without a problem and the output is being printed successfully. Why is SiteScope is failing to execute with: "not found"?

By default, SiteScope searches for certain common error strings to indicate a problem running the script. The default settings can be found in the <SS>groupsmaster.config file under the following parameters:

_scriptMonitorErrorMsgs=not found,Not Found,denied,Denied,cannot execute,such file or directory

_scriptMonitorErrorMsgs2=Failed to .* Error code:

If a script will execute correctly but report any of the above default strings, then the parameters need to be modified when the SiteScope service is stopped. Simply remove the problematic string and modify the entry in this case to:

_scriptMonitorErrorMsgs=Not Found,denied,Denied,cannot execute,such file or directory

_scriptMonitorErrorMsgs2=Failed to .* Error code:

Additionally, if there are particular script error codes specific to a script that should indicate an error, that string can be added to the above parameters so that SiteScope will error when they are parsed.

SiteScope 10.10 – URL monitor against SAP portal fails with HTTP 400 Bad Request

New installation of SiteScope 10.10 on Windows 2003

old – still avtive – instance of SiteScope on Windows 2003

URL monitoring to a SAP portal. There are a lot of so called nodes (services) with different URL. One request is working:;saplb_*=203283651

The other one doesn’t work:;saplb_*=3260050

Both are URL content monitors with the same attributes (I copied one from another).

The failing monitors respond with HTTP 400 Bad Request

Enabling DEBUG logging doesn’t reveal anything really useful:

failing with HTTP status 400

2010-08-03 16:25:16,312 [Node 651(CONS/1) ] ( DEBUG – enter HttpState.addCookies(Cookie[])


2010-08-03 16:25:17,078 [Node 651(CONS/1) ] ( DEBUG – alertDebug: f3d9e34 ALERT/GOOD/WARNING/ERROR VALUES: status(value: 400) != 200

succeeding with HTTP Status 200:

2010-08-03 16:26:18,203 [Node 250(PROD.1/2) ] ( DEBUG – enter HttpState.addCookies(Cookie[])


2010-08-03 16:26:18,578 [Node 250(PROD.1/2) ] ( DEBUG – alertDebug: 06de5f4 ALERT/GOOD/WARNING/ERROR VALUES: status(value: 200) != 200

R&D found out that it’s a user-agent issue.

For example you can check this thread :

By default SiteScope uses "User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)" (you can check it in the logs)

To Fix this issue, use "POST data" field (put one of the strings that described below) in URL Content & URL Sequence Monitors(in url sequence step form).

Try to use these :

"User-Agent: Mozilla/4.0"

"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; YPC 3.0.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

"User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9) Gecko/2008052906 Firefox/3.0"

"User-Agent: Opera/9.0 (Windows NT 5.1; U; en)"

"User-Agent: Opera/10.00 (Windows NT 6.0; U; en) Presto/2.2.0"

Try to change it and don’t forget to check it in RunMonitor logs :

User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)

Pragma: No-Cache

Accept: */*




HTTP/1.1 200 OK

Server: SAP J2EE Engine/6.20

Content-Type: text/html; charset=UTF-8

Content-Language: en-US

expires: 0

Date: Fri, 17 Sep 2010 09:29:52 GMT

Transfer-Encoding: chunked

Set-Cookie: sapj2ee_*=1120943600; Version=1; Path=/

Set-Cookie: JSESSIONID=(itnts2221_FCM_00)ID1120943600DB0.6216552420769629End; Version=1;; Path=/


The customer took the liberty to change the User-Agent information in the master.config file to avoid the need to perform this change on each and every monitor.

Changing the user agent solved the problem.

How will “persistency” work

There are 4 kind of "persistency" under .persist_dir\db_loader

1. .persist_dir\db_loader\main\dlq – samples that failed to insert into DB, because some not recoverable reason: wrong sample, duplicated samples, samples with time stamp older then data purging period. No limit for samples count there- only by disk space. No automatic purging of "old" files from there. Samples can be "tried" to be inserted again, but generally no reason that they will success to be inserted once they failed. Especially is data tables for sample time stamp already purged.

The rest persistency folders are

2. .persist_dir\db_loader\main\current – samples that are in loader memory now. Size is limited by memory restrictions of db loader

3. .persist_dir\db_loader\flattenfailure – hierarchy samples (trans_t) that are temporary failed to open hierarchy because DB connectivity problem. No limit – only by disk size.

4. .persist_dir\db_loader\recovery – samples that are temporary failed to be inserted – usually because DB availability issues. Limit is 509 files per sample type (8,192 samples in file) ~ 4M samples per sample type. After this limit, loader stops to work and refuses to read data from BUS

Error in post init process: Object Config with id= __dashboardPreference_XXXXXX is null

Error in post init process: Object Config with id= __dashboardPreference_XXXXXX is null

This error is related to the SiteScope Favorites settings. The special character "/" cannot be used in the name of favorites profile because this symbol is used by the system. As a result, the problematic profiles make errors in the logs and can’t be deleted from the UI.

These profiles can be deleted by using the Persistency Viewer. We suggest to delete them and to not use "/" symbols in the names of profiles in the future.

To delete the problem profiles:

1. Open Persistency Viewer via command line (<SS>\bin\PersistencyViewer.bat).

2. Select from the drop down filter in Persistency Viewer: "class com.mercury….DashboardPreferencesConfig".

3. Select the rows with IDs that contain "\" (e.g.e __dashboardPreference_TEST 8/27/10, __dashboardPreference_VIEW 8/27/10 and __dashboardPreference_SAVE 8/27/10).

4. Delete the rows.

Sitescope 11 and OM integration : some policies not listed in inventory

After having installed Sitescope 11 and the OM agent, some OM policies are active on the OMagent installed on the Sitescope machine, but not listed in the inventory of the managedSitescope node. It includes the following policies:

HP_SiteScope_to_Operations_Manager_Integration_by_Log_File (log file type of policy)
HP_SiteScope_to_Operations_Manager_Integration (opcmsg policy)
SiteScope_Hosts_Discovery (service discovery policy)
HP_SiteScope_to_Operations_Manager_Integration_by_Log_File (log file policy)

These policies should automatically be installed when you install SS 11 and the OM agent.These policies are then auto-deployed to the SS node, by the installation. They are active but arenot listed in the policy inventory.

There is a way to "register" them with OMW, so that you can deploy them from OM to updatethe policy inventory.

1. On the Sitescope 11 server, copy the folder ..:\Sitescope\tools\OMIntegration\Raw to theOM server. This folder contains the 3 policies:

HP_SiteScope_to_Operations_Manager_Integration_by_Log_File (log file type of policy)
HP_SiteScope_to_Operations_Manager_Integration (opcmsg policy)
SiteScope_Hosts_Discovery (service discovery policy)
HP_SiteScope_to_Operations_Manager_Integration_by_Log_File (log file policy)

2. On the OM server, open a CMD, and CD to the folder where you copied the policies.

3. Run the following to register the policies to OM : ovpmutil cfg pol upl
This will register the policies to OM.

4. Now deploy those to the Sitescope server, from the corresponding group type of policy"Agent policies grouped by type"

5. Once deployed to the Sitescope server, the policy inventory should list now the 4 missingpolicies.