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.

Advertisements

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

Error: Failed to send data by channels – post message failed

In LoadRunner or Performance Center 11.00, during the middle of a running a scenario or load test, the LR Controller or PC output starts reporting error code -30935 "Error: Failed to send data by channels – post message failed." and no additional successful transactions are registered for the run.

The error occurs on the Load Generator machine(s) when one of the threads under lr_bridge.exe that updates the eve files is not getting enough CPU time slice to be able to send events to the Controller. Enabling an additional flag in the mdrv.dat file on the LG machine will maintain the read and write threads for the eve files on the same main thread, thus allowing it to have all the CPU time needed.

Disable Web Diagnostics for J2EE/.NET. If the behavior remains, go through the next steps.

On all of the Load Generator machines where the Vusers are being executed, edit the <LR or PC Installation>\dat\mdrv.dat file by adding the line listed below in bold:

[lr_trans_server]

ExtPriorityType=transaction_server

WINNT_EXT_LIBS=trans_server.dll

WIN95_EXT_LIBS=trans_server.dll

LINUX_EXT_LIBS=libtrans_server.so

SOLARIS_EXT_LIBS=libtrans_server.so

HPUX_EXT_LIBS=libtrans_server.sl

AIX_EXT_LIBS=libtrans_server.so

LibCfgFunc=TransactionServer_configure

GetLoaderInterfaceFunc=get_ts_interface

AddLoaderClientInterfaceFunc=add_ts_client_interface

GetLoaderCommandLine=trans_server_extra_ext

Loader=1

ExtMessageQueue=0

SecurityMode=On

ExtCmdLineOverwrite=-eve_thread_run_on_main_thread

Save the changes in the mdrv.dat file then re-run the scenario or load test.

Ajax TruClient script be run as Thread instead of Process

Currently the replay of Ajax TruClient scripts do not support multithreading mode, that is, scripts could only be replayed in "Run as Process" mode.
Ajax TruClient is a GUI based protocol and during the replay a separate instance of Gecko (Firefox layout engine) is created for each Vuser. If you run 50 Vusers you will have at least 50 processes, just like if you open 50 instances of Firefox browser. That’s why the protocol consumes so much resources (RAM and CPU).

Ajax TruClient script fails in non interactive mode

In Windows XP, Ajax true client script replays fine in interactive mode, but fails in load mode when replaying "wait for object" with the "

Error -203256: ** 16: Wait for …** failed – target object was not found".

There is an issue with Windows XP that is connected to some dlls that are duplicates in the Gecko dir under LoadRunner and in the System32 dir.

This might create some problems during load replay

Add "<LR install folder, full path>\bin\gecko" to the beginning of the path environment variable

Internet Explorer freezes randomly when recording a Secure Web application

[Net An. Warning (1590: d10)] Request Connection: Remote Server @ xx.xxx.x.xxx:443 (Service=) Failed attempt #1. Unable to connect to proxy (@ xx.xxx.x.xxx:xxxx): sid = xxxx, rc = 10056)

[Net An. Warning (1590: d10)] Request Connection: Remote Server @ xx.xxx.x.xxx:443 (Service=) Failed attempt #2. Unable to connect to proxy (@ xx.xxx.x.xxx:xxxx): sid = xxxx, rc = 10056)

In secure http communication, the "handshake" syncs the server and the client up with the encryption methods and keys that will be used for the remainder of the communications. A successful handshake creates the new "secure key" that the remainder of the connection will be using.

In this case, the client tries to set up a secure connection (ssl handshake) every time, instead of using the "secure key" that was created during the first successful handshake, for the remainder of the session. The ssl handshake succeeded on the some attempts but was failing on other requests, and that is why Internet explorer was freezing randomly at different steps in the business process.

Open "Registry Editor" in Windows (Start menu > Run > regedit)

Navigate to:

HKEY_CURRENT_USER/Software/Mercury Interactive/LoadRunner/Protocols/WPlus/SSL/OpenSSL

Set the value for "ReuseSSLSession" to 1

By doing this, we are ensuring that the "secure key" created during the first successful ssl handshake, is reused for the entire session instead of the client trying to do a ssl handshake every time.

The connection was ended because of a network error. Please try connecting again to the remote computer again

While recording with RDP Protocol, RDP Client is throwing the error "The connection was ended because of a network error. Please try connecting again to the remote computer again"

The Encryption Level of the RDP-TCP connection on the Terminal Server is set to FIPS Compliant.

To disable the FIPS encryption level by changing the Encryption level setting in the RDP-Tcp Properties dialog box, follow these steps:

1. Click Start, click Run, type tscc.msc in the Open box, and then click OK.

2. Click Connections, and then double-click RDP-Tcp in the right pane.

3. In the Encryption level box, click to select a level of encryption as Client Compatible.