BSM 9.x – When creating a Downtime in BSM, it’s not possible to select various CIs, for example “SiteScope Monitor” or “SiteScope Group”

BSM 9.x – When creating a Downtime in BSM, it’s not possible to select various CIs, for example "SiteScope Monitor" or "SiteScope Group"

BSM 9.20

When creating a Downtime in BSM, it’s not possible to select various CIs, for example "SiteScope Monitor" or "SiteScope Group".

By default BSM doesn’t allow to enable downtime for all CITs.

When creating a downtime and getting to the CI Selection screen, simply click on Help,

and BSM will tell what CITs are allowed:

All views that the user has permission to see may be selected. You can select CIs only of the following CI types:

• node

• running software

• business application

• ci collection

• infrastructure service

• business service

"System Monitors" or "Sitescope Group" is not part of this list, thus you cannot select it.

This post has the instructions which explains how to select (for example) SiteScope Group CI for downtime scheduling.

It can easily adapted to enable any other CI for downtime scheduling.


Select SiteScope group CI to schedule downtime

  1. Please follow instructions below to select SiteScope group CI to schedule downtime

  1. Restart BSM
  2. Go to Downtime UI (Admin -> Platform -> Downtime Management)
  3. Verify that SiteScope group is not grey out (like a snapshot below)

  1. Go to Admin -> Platform -> Setup and Maintenance > Infrastructure Settings
  2. Find options “Object Root” and “Link Root” and change them to “root” (like on snapshot below)

  1. Re-login BSM
  2. Go to Admin -> RTSM Administration -> Modeling Studio (before editing, please backup TQL)
  3. Load “BSMDowntime_topology” and add “SiteScope Group” CI type to graph.

Then connect “BSMDowntime” with just added CIT with link “downtime of”

(this link become available after your changes in infra settings (see point 6)

  1. Double-click on “BSMDowntime” CIT and go to “Cardinality” tab.

You can see logical expression of node, your new added link between “SiteScope Group” and “BSMDowntime” will be mentioned with “AND” operand. You should switch it to “OR” (like on screenshot below)

  1. After these changes do not forget to save TQL

How to limit the SLA calculations of a SiteScope monitor to one measurement

To specify a measurement of a monitor which will be taken into account for SLA calculations, these steps can be followed:

1. Go to the SLA definition.

2. Go to Define KPIs section.

3. Select the SiteScope Monitor CI associated to the metrics that should be measured and edit the KPI on the left panel.

4. Introduce the name of the measurement in the Measurement type field.


If SiteScope measurement is called status, the word status should be introduced.

5. Start the SLA if it is a new SLA or recalculate it if it is a new one.

Does partition manager has to be restarted after changing the EPMs

Partition Manager runs every hour, 24 times a day. PM likes to sleep a lot, it wakes up every hour to do its job and goes back to sleep again (snooze mode).

It depends on what changes were made, if configuration changes were done, then a restart is a good idea so it can reload them. Each time Partition Manager starts, it needs to reload PM_CONFIG. If a restart is not done, the maximum waiting time is one hour.

Creating a customized content pack for Omi

The Extensibility guide describes how to validate the mapping rules using an XML schema.

The Extensibility guide explains the creation of a complete topo sync package using an example.

NOTE : This guide does not describe uCMDB basics and relies on quite some uCMDB know-how. (E.g. what are ci-types, what are the key attributes, etc.). The OMi Extensibility guide is the right place to describe these uCMDB basics.

Creating custom Content Pack requires uCMDB know-how, therefore it’s hard or even impossible to create a SyncPackage, if one doesn’t know what to map where.

It’s possible to map configuration item types to RTSM views using the RTSM Modeling Studio, so that views are available for selection and use in the Health Top View pane.

Comprehensive details about how to create new CI types, and how to work with the concepts of the RTSM, are described in the HP Business Service Management Modeling Guide.

This guide (Modeling.pdf) is part of the standard BSM documentation.

Configure the credential of the remote shared folder used by GWs during the configuration of the Load Balancer

When configuring Business Availability Center (BAC) or Business Service Management (BSM), Gateway’s (GW) in a load Balancing mode, we need to configure a remote shared folder in the network to use it for Offline/Online data used by reports as recommended by the Deployment Guide.

Sometimes the user needs to run BSM Service as "Local System account" for security reason or when the shared folder belongs to a different domain then BAC/BSM machines.

Since BAC/BSM run as a service, it is possible to make the shared directory accessible when the Operating System (OS) starts by sharing the remote Folder and Grant to BAC/BSM host the full control privilege, by adding it with $ symbol at the end: "servername$" then give him full credential.

Edit Local Machine policy using the MMC console and add the user "NT Authority\System" as part of the users that may Logon as a service on the Local machine.

Try to connect to see if BSM has access to the directory after configuring apache as described in the Deployment Guide.

The above example is for "Local System account" but it’s the same for any different user.

BSM cannot start due to error “Local host name unknown”

BSM 9.20 on RedHat

The error message in Business Service Manager (BSM) could be found in file:


STATUS | wrapper | 2012/11/15 09:42:22 | Launching a JVM…

ERROR | wrapper | 2012/11/15 09:42:36 | JVM exited while loading the application.

INFO | jvm 1 | 2012/11/15 09:42:36 | Error: Exception thrown by the agent : Local host name unknown: bsmgw.static.lab: bsmgw.static.lab: T$

STATUS | wrapper | 2012/11/15 09:42:40 | Launching a JVM…

ERROR | wrapper | 2012/11/15 09:42:40 | JVM exited while loading the application.

INFO | jvm 2 | 2012/11/15 09:42:40 | Error: Exception thrown by the agent : Local host name unknown: bsmgw.static.lab: bsmgw.static.lab: T$

FATAL | wrapper | 2012/11/15 09:42:40 | There were 2 failed launches in a row, each lasting less than 300 seconds. Giving up.

FATAL | wrapper | 2012/11/15 09:42:40 | There may be a configuration problem: please check the logs.

STATUS | wrapper | 2012/11/15 09:42:40 | <– Wrapper Stopped

The symptoms without using the logs are :

In the web browser on http//<BSM_FQDN>/topaz/


The requested URL could not be retrieved

The following error was encountered while trying to retrieve the URL: http://<BSM>/topaz/login.jsp

Connection to failed.

The system returned: (111) Connection refused

The remote host or network may be down. Please try the request again.”

In the web browser on http//<BSM_FQDN>/

“It works!”

The local hostname resolution is not working correctly.

The cause could be in local hostname settings or in the DNS server.

Due to manual manipulations using the graphical tool Network Administrator the network settings could be reset.

To fix it check:

Local host name

DNS server local settings

Hostname resolution using IP and full dns name

Ping locally the machine using ip, short dns name full dns name.

Some of the commands that can be used to find the cause:


hostname | nslookup

nano /etc/hosts

nano /etc/sysconfig/network

nano /etc/resolv.conf