Archive for January, 2011

Active Alerts Views are empty

January 24, 2011 Leave a comment

This came up on the technet forums a while back and I saw it again on a customer site recently which reminded me that I wanted to post about it. Basically, after upgrading to CU3, the Active Alerts views are empty. If you scope the view for selected groups then alerts will appear but as soon as you change it back to “All groups” the alerts disappear.

Resolution? When you install CU3, remember to run the required SQL scripts against the Operations Manager database and datawarehouse!

Categories: Consoles, Operator

Regular Expressions in Operations Manager 2007 R2

January 24, 2011 Leave a comment

Regular expressions within OpsMgr does have its nuances – this should help:

Categories: Authoring

The windows restart manager service on Windows 2008 causes service restarts during CU3 updates

January 24, 2011 Leave a comment

Just be careful – the windows restart manager service on Windows 2008 causes service restarts during CU3 and CU4 updates.

Categories: Updates

Audit Collection Services Reports only show the last 42 days worth of data

January 11, 2011 1 comment

There was a very interesting thread on the forums some time ago about ACS reports only ever displaying the last 42 days worth of data. It transpires that you need to modify DbCreatePartition.sql and DeletePartition.sql as there is a hard coded select statement that returns only the “TOP 42” (last 42) partitions.

Troubleshooting 21023 Events

January 10, 2011 Leave a comment

On a recent customer site, one of the Secondary Management Servers was “stuck” logging 21023 events (requesting configuration) in the operationsmanager event log. When I restarted the System Center Management Service on the MS, I noticed that the Root Management Server logged an event in the operationsmanager event log:

The request to synchronize state for OpsMgr Health Service identified by “255be352-859b-5f26-bdc0-f1a660d2cf71” failed due to the following exception

“Microsoft.EnterpriseManagement.Common.DataAccessLayerException: Invalid column name blah _2D3F1F4B_D4E0_2723_1415_9BF423A1D39F for query MTV_SelectProperty_2d3f1f4b-d4e0-2723-1415-9bf423a1d39f.”

I ran the following select statement against the operationsmanager database using the first guid (health service):

Select * from BaseManagedEntity where basemanagedentityid like ‘%255be352-859b-5f26-bdc0-f1a660d2cf71%’

This showed me it was the Secondary Management Server that was sending the “dodgy” data.

I then used the following SQL query to find out the mangement pack that was causing the problem (where the managedtypeid is the second guid in the original error):

SELECT mp.ManagementPackId, mp.MPName,
mp.MPFriendlyName, mt.TypeName, mt.ManagedTypeTableName
FROM ManagementPack mp
LEFT JOIN ManagedType mt ON mt.ManagementPackId = mp.ManagementPackId
WHERE mt.ManagedTypeId = ‘2D3F1F4B-D4E0-2723-1415-9BF423A1D39F’

This identified the problem management pack. Removing this and restarting the health service on the Secondary Management server kicked the Secondary Management Server back into life. Suddenly a whole batch of 1201 events were being logged as new management packs were downloaded.