Monthly Archives: February 2013

How to search for more then 500 objects in the SCOM console group and report add objects fields.

The other day I needed to add a large amount of objects (860) to an availability report. After the report ran I noticed that only 500 objects were present in the report view, as it turns out this is by design.

In your registry you need to browse to the following key:

Location: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console

Create a new DWORD value key that is named MaximumSearchItemLimit, and then assign it a decimal value to reflect the number of objects that you want to display. For example, use a value of 1000 if you want to limit the maximum number of objects to 1000 instead of the default of 500.

Name: MaximumSearchItemLimit
Type: REG_DWORD
Value: 0 to 65535

Close and re-open your console.

You will now be able to search the number of objects that you set the value to.

Note: This needs to be applied on each machine running a console that you want to remove the restriction from.

Upgrading to SCOM 2012 SP1 – Setup could not detect the current data warehouse scenario.

After a bit of a battle we managed to upgrade our environment to SCOM 2012, after letting everything settle we fired up the SP1 media and immediately had the following error.

Unable to Proceed
Setup could not detect the current database scenario.

1

Luckily for us after a bit of research, (Thanks to Stefan Roths’s blog for pointing us in the right direction) the resolution was quite simple, checking the registry HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
The following keys were empty DataWarehouseDBName and DataWareHouseDBServerName

After populating the relevant values for our DB server and Data Warehouse database the install allowed us to proceed.

Restoring SCOM databases

Recently I’ve had to recover a SCOM environment. This process required me to restore the SQL backups of both the OperationsManager and Data Warehouse databases.

After stopping the SDK service on our RMS, trying to restore the backup from the management studio under Tasks > Restore  > Database I came across a frustrating error “Exclusive access could not be obtained as the database is in use.”

A bit of research led me to an easier way to perform the restore, as well as check what is blocking the exclusive access,

First in SQL management studio select your master database and click new query:

USE MASTER
ALTER DATABASE DATABASENAME SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

-This will make it so only one connection to the database can be made.
-Run the following command to see where any recurring connections to database are coming from.

EXEC SP_WHO2

-Check this list, looking under the DBName column.  If the database is listed, check the ProgramName, and HostName column to see who is attempting to connect.
-If it is not a service, or other application that would automatically reconnect which can be shut down, note the number in the SPID column to kill the connection, and immediately begin the backup.  Replace SPID below with just the number.

KILL SPID
RESTORE DATABASE DATABASENAME FROM DISK = ‘X:\PATHTO\BACKUP.BAK’
GO

-If this completes successfully, we can set the newly restored database back to multi user mode.

ALTER DATABASE DATABASENAME SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

After restoring your OperationsManager database you will also have to re-enable your SQL Broker as it is required in order for your SCOM discoveries to work.

To check if your SQL broker is enabled run the following query, returning a value of ‘0’ means that the Broker is disabled.

SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

To enable the Broker user the following queries:

ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER

 

 

Alerting when an account is set to not expire

We had a requirement to alert when an account was created in AD with the “Password will not expire” flag on and when an existing account is changed to a password that will not expire for audit purposes.

It can be done using the following alert generating rule:

Expire1

Expire2

 

The reason for the %%2089 is that events on the domain controller are generated using codes which are then converted to English in the event viewer. Something to bear in mind when creating rules to look at DC event logs.

Note: This event is for AD 2008 only.