BlackBerry Management Pack Custom connection string to BES database

BlackBerry Management Pack Custom connection string to BES database

 

In most cases the BlackBerry Management Pack is able to construct the connection string in order to connect to the BlackBerry Enterprise server database. In special cases where SQL standby servers are used or other forms of SQL redundancy, the connection string might not reflect the correct configuration. An example is that the BlackBerry management pack cannot construct a connection string that reflects a standby server. In order to allow the BlackBerry Management Pack to connect to SQL back-ends with varying configurations, the option is given to create a custom connection string by overriding the default configuration. In order to override the default connection string follow the steps below.

 

  1. The default connection string outomatically generated by the BlackBerry Management Pack has the following form: Provider=SQLOLEDB;Database=BESMgmt;Server=olxsql01;Trusted_Connection=Yes;IntegratedSecurity=SSPI
  2. The management pack cannot automatically build connection strings for failover or standby databases, so you will need to override the default connection string to the following format (You will need to determine the exact format of the connection string for your environment):Provider=SQLOLEDB;Database=BESMgmt;Server=olxsql01;Failover Partner=olxsql02;Initial Catalog=myDataBase;Trusted_Connection=Yes;IntegratedSecurity=SSPI.
  3. Once you have determined the correct connection string, in the SCOM console browse to the authoring section and set the scope as shown in the screenshot:
  4. Then select: Authoring -> Management Pack Objects -> Object Discoveries and double click BlackBerry 5.0.x Enterprise Server Discovery
  5. Select the Overrides tab and select For all objects of class: BlackBerry 5.0.x servers.
  6. In the Overrides Properties window check the checkbox next to ConnectionString and enter the new connection string into the Override Value field. Save the override in an appropriate management pack and save the changes.

SCU Asia Pacific 2015 – Singapore Expo

Since the beginning and for the fourth time annually OpsLogix is sponsoring System Center Universe Asia Pacific. As always we are proud to be attending and hope to see you there!

For the early birds out there: If you register with the SCUBLOG promotional code you will receive the following perks:

  • You are entitled to an early bird ticket rate that includes a special hotel rate with Capri which is located minutes away from the event venue.
  • Early bird ticket details:
    • US$190/ticket
    • US$150/ticket for a group of 5 or more
    • Special rate with Capri – SGD230++ /night
  • Registration steps:
    • Register here
      and select Option 3: Registration with RSVP code

 

Sizing SCOM for the Oracle Management Pack

Sizing SCOM for the Oracle Management Pack

When implementing a new Management Pack in System Center Operations Manager (SCOM) sizing is extremely important if you want to keep your SCOM environment healthy and responsive. For implementing the OpsLogix Oracle Management Pack there are a few sizing scenarios you might want to consider before importing the Management Pack.

There are also 5 main factors that determine the number of instances you can monitor from one monitoring node:

  • Number of tablespace in an Oracle instance
  • Type of SCOM server used
  • Other workflow that are run on the SCOM agent
  • Number of enabled/disabled/custom rules and monitors in the management pack
  • Hardware sizing

This post is based on V1.3.12.130 of the OpsLogix Management Pack for Oracle.

 

Scenario’s for running the Oracle Management Pack on a Monitoring node:

  1. Running the management pack from a SCOM Management server
  2. Running the management pack from a SCOM Gateway Server
  3. Running the management pack from a SCOM Agent machine

 

 

Running the management pack from a SCOM Management server

When running the management pack from a dedicated SCOM Management server you should be able to monitor 20 instances when the following criteria are met:

  • The Management Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 8 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled

 

 

Running the management pack from a SCOM Gateway Server

When running the management pack from a dedicated SCOM Gateway server you should be able to monitor 20 instances when the following criteria are met:

  • The Gateway Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 4 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled
  • For the increased workload you will need to configure registry settings and overrides on the Gateway Server as shown in the appendix.

 

Running the management pack from a SCOM Agent machine

When running the management pack from a dedicated SCOM Agent server you should be able to monitor 20 instances when the following criteria are met:

  • The SCOM Agent Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 4 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled
  • For the increased workload you will need to configure registry settings and overrides on the SCOM Agent Server as shown in the appendix.

Appendix: Adding registry settings and overrides to scom agents:

In order for the SCOM Agent or Gateway to be able to handle the larger workload the following registry settings need to be set on the server:

  • reg add “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters” /v “State Queue Items” /t REG_DWORD /d 20480 /f
  • reg add “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters” /v “Persistence Checkpoint Depth Maximum” /t REG_DWORD /d 104857600 /f

 

 

For the increased workload you will need to set the following overrides on the SCOM Agent or Gateway Server:

Navigate to:

System Center 2012 Operations Manager – Operations Console > Authoring > Management Pack Objects > Monitors

Locate Health Service > Entity Health > Performance> System Center Management Health Service Performance > System Center Management Health Service Memory Utilization > Health Service Private Bytes Threshold

Right-click and select Properties > then from the ‘Health Service Private Bytes Threshold Properties’ select the Overrides tab> click the Override… button and choose ‘For a specific object of class: Health Service

Find the server you are using as a monitoring node, select it and click OK

Check the Override box by ‘Agent Performance Monitor Type – Threshold’ and change the ‘Override Value’ (scroll to the right) to 31457280000

Save the override.

Navigate to:

System Center 2012 Operations Manager – Operations Console > Authoring > Management Pack Objects > Monitors

Locate Health Service > Entity Health > Performance> System Center Management Health Service Performance > System Center Management Health Service Memory Utilization > Health Service Handle Count Threshold

Right-click and select Properties > then from the ‘Health Service Handle Count Threshold Properties’ select the Overrides tab> click the Override… button and choose ‘For a specific object of class: Health Service

Find the server you are using as a monitoring node, select it and click OK

Check the Override box by ‘Health Service Handle Count Threshold – Threshold’ and change the ‘Override Value’ (scroll to the right) to 31457280000

Save the override.