Viewing the management packs and scripts that OpsMgr uses

Imagine you having a problem with a mountpoint not being discovered or a SQL database not being discovered by OpsMgr 2007. Would it not be great if you can view the actual discovery script that is being used to do the discovery.
One way of accomplishing this :
All management packs and scripts that these management packs utilize is “extracted” by the OpsMgr agents in the following directories on the agent servers

Management Packs is extracted/converted into XML format and is stored in \System Center Operations Manager 2007\Health Service State\Management Packs. If you view these XML files in an XML editor you will also see the scripts thats part of the management pack in the file itself.

The scripts is put in \System Center Operations Manager 2007\Health Service State\ and then there is folders created that starts with “Monitoring Host Temporary Files” ending in a number. Each folder contains a specifi script.

This information is usefull if you want to find out how the management packs works and what scripts is executed. I use this information alot in troubleshooting and information gathering.

Screenshot of XML management packs

Viewing what ACS collector is a ACS forwarder sending to

Did you ever wonder how you can view using the OpsMgr console what collectors the ACS forwarders is configured to sent their security events to?
One way of accomplishing this is to create an attribute discovery in OpsMgr and let it create an attribute for you with the collectors name in it.

Open the OpsMgr 2007 console and go to the Authoring pane
Drill down to Management Pack Objects > Attributes

Right click and select “Create a New Attribute”

Specify a Name for the discovery keeping in mind that the name will displayed as a column heading in the OpsMgr console

Click Next

On the Choose a Discovery method screen
1. Discovery Type = Registry
2. Target – You need to choose the Agent target, doing this you will be told: “The attribute cannot be directly added to the selected type because it belongs to a Sealed Management Pack
In order to add the attribute successfully, we will create an extended version of the type which will be located in an unsealed Management Pack”

The target will be changed to “Agent_Extended”, you must change the Management Pack to a Custom management pack in use in your environment

Click Next

On the Choose a Discovery methog

Change the Key or Value Type to Value – you wanna get the name of the ACS collector configured for the agents

The path must be SOFTWARE\Policies\Microsoft\AdtAgent\Parameters\AdtServers

The Attribute Type must be string

Frequency can be anything, the default is 3600 seconds = 1 hour

Click on Finish

Now you will have to create a state view in the Monitoring Pane in the OpsMgr console to view this attribute.

I’m using this view to also enable auditing collection directly in that view hence the name of the state view

Here is the properties of the view, note the “Show data related to” field which is the extended agent class that was created

Next step is where you need to add the attribute by customizing the view, right click on the column headings of the newly create view and select “Personlize view”

In the Personalize View select the column that is the same as the name of the attribute discovery and tick the box

Click OK,

The view will now have a column that shows the ACS collector that the agent is forwarding the security events to.

Using WMI to create alert for a specific security event

A while back I got a request from the security department, they wanted to know when someone sign onto the file print servers using an RDP connection – remote desktop. Seeing that we already have ACS deployed and these events is already stored in a database it was real easy to pull this information out of the ACS databases. What they however wanted was to be email in real-time when this happened, someone sign onto a file and print server. One approach to get this done was to use the WMI and the SCOM management group.

You will need to create a Alert Generating WMI Event rule

Choose a destination management pack different from the “Default Management Pack” and click on “Next”
On the next screen give the rule a name, as a best practise I also use “Custom – ” in front of any rules that i create, it makes the searching for rules easier.
The rule category must be “Alert” as we will create an alert

Here comes the important bit: The Rule Target must “Microsoft Audit Collection Services Collector”, the WMI query will run against the WMI namespace on the ACS collector server as that is where all security events from the forwarders is forwaded to

Click Next

On the WMI Configuration screen you will need to specify the WMI Namespace and also the Query
The namespace must be “root\default”
The query in my case is “SELECT * FROM AdtsEvent WHERE EventId=528 and String01=’10′”

Security Event 528 is when a account succesfully logs onto a computer

Now String01 is the more difficult part, the value 10 refers to the LogonType and 10 equals RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance) logon type and this is what i need.

An easy way to find out what the different strings are that ACS breaksup a security event is to run a select statement agains the ACS database server for all events with id 528
Select * from AdtServer.dvAll where eventid=528
This query will then return all the events and you can see the fields and what database columns they are stored in

Click Next

On the Configure Alerts screen you need to create and specify the alert description and alert name
The alert description allows you to custom-define what you want the alert to say. In my case i used

The User: $Data/EventData/DataItem/Property[@Name=’PrimaryDomain’]$\$Data/EventData/DataItem/Property[@Name=’PrimaryUser’]$ signed onto server: $Data/EventData/DataItem/Property[@Name=’String04′]$ using an RDP session from IP Addres: $Data/EventData/DataItem/Property[@Name=’String02′]$

The fields above is reference like that, if you run the query against the ACS database server you can substitute the SQL columns for the values in ‘ ‘ quotes to get that information into the alert description.

I left all other fields default and clicked Create.

Example of alert in the console

Combining 2 ACS databases into the ACS reports

The ACS collector to ACS database is sad to say a one to one relationship. This means you can only have one ACS collector writing to a single ACS SQL database. Yes you can have each ACS database hosted in a seperate SQL instance on the same SQL server. The big question is how do you read the security event data from the different databases and display them in the SCOM console
The way I accomplished this was to create a database and then create a view for each of the ACS database servers in that custom database.
Query use to create the views
USE [CombinedSecurityEvents] – This is the database that i created
CREATE VIEW [dbo].[scd5_dvall] AS – this is the view name for the one ACS database server
select *,’SCD0005′ as ‘COLDB’ from [operationsmanagerac].[adtserver].[dvall] –

The ‘SCD0005’ as ‘COLDB’ in the select statement is a reference for which database these events cames from. You can call this anything you want
I then created a SQL view that pulls all this information together and this view is then used in my ACS reports.

USE [CombinedSecurityEvents]
CREATE view [dbo].[combined_dvall] AS – The view is called “combined_dvall”
select * from scd5_dvall union all select * from scd6_dvall

Viewing the database with in my case the three views

So in the select statement above I have to views called scd5_dvall pointing to the one ACS database server and a second view called scd6_dvall that points to the second ACS database server. The union statement “combines” the contents of these two views.

So if you then view the data in SQL management studio – The COLDB column is highlighted, this is just a control column for me to see that all events from both ACS databases is returned:

In my ACS reports i then use the following query structure

select count(*) as count, convert(varchar, [collectiontime],101) as date
from combined_dvall – this is the view that i created above.
where [collectiontime]>=@datefrom
group by convert(varchar, [collectiontime],101)
order by convert(varchar, [collectiontime],101) desc

The report that utilizes the query

SCOM Dashboard

Above is my version of a SCOM dashboard. This dashboard is actually report that was created in Visual Studio 2008. The idea for this dashboard is based on another persons work here, the dasboard is based on the SCCM dashboard that is then customized for SCOM and is running on SharePoint using webparts. This SCCM dashboard is still in beta and it seems there is no plans to do one for SCOM. My dashboard is build using Visual Studio 2008 and is hosted on the SCOM reporting server running SQL reporting services 2008.

The Agent Status pie chart is using the following query – copied from
SELECT ‘Responding’ as Status, COUNT(*) as TotalMachines FROM ManagedEntityGenericView INNER JOIN ManagedTypeView
ON ManagedEntityGenericView.MonitoringClassId = ManagedTypeView.Id
WHERE (ManagedEntityGenericView.IsAvailable = ‘True’) AND (ManagedTypeView.Name = ‘Microsoft.SystemCenter.Agent’)
SELECT ‘Not Responding’ as Status, COUNT(*) as TotalMachines FROM ManagedEntityGenericView INNER JOIN ManagedTypeView
ON ManagedEntityGenericView.MonitoringClassId = ManagedTypeView.Id
WHERE (ManagedEntityGenericView.IsAvailable = ‘false’) AND (ManagedTypeView.Name = ‘Microsoft.SystemCenter.Agent’)

The agent health bar chart is using the following query – copied from
SELECT [State] = CASE ManagedEntityGenericView.HealthState
WHEN 1 THEN ‘Healthy’
WHEN 2 THEN ‘Warning’
WHEN 3 THEN ‘Critical’
ELSE ‘Unknown’
, COUNT(1) AS GroupCount
FROM ManagedEntityGenericView INNER JOIN
ManagedTypeView ON ManagedEntityGenericView.MonitoringClassId = ManagedTypeView.Id
WHERE (ManagedTypeView.Name LIKE ‘Microsoft.Windows.Computer’)
GROUP BY ManagedEntityGenericView.HealthState
ORDER BY GroupCount

The alert severity bar chart is using this query – own work
SELECT COUNT(1) AS activeAlerts, ‘Information’
FROM Alert WHERE ResolutionState = ‘0’
and severity =0
group by severity
SELECT COUNT(1) AS activeAlerts,’Warning’
FROM Alert WHERE ResolutionState = ‘0’
and severity =1
group by severity
SELECT COUNT(1) AS activeAlerts,’Critical’
FROM Alert WHERE ResolutionState = ‘0’
and severity =2
group by severity

The gauge for agents is using this query – copied from
SELECT COUNT(*) AS NumManagedComps FROM (
SELECT bme2.BaseManagedEntityID
FROM BaseManagedEntity bme WITH (NOLOCK)
INNER JOIN BaseManagedEntity bme2 WITH (NOLOCK) ON bme2.BaseManagedEntityID = bme.TopLevelHostEntityID
WHERE bme2.IsDeleted = 0
AND bme2.IsDeleted = 0
AND bme2.BaseManagedTypeID = (SELECT TOP 1 ManagedTypeID FROM ManagedType WHERE TypeName = ‘’)
GROUP BY bme2.BaseManagedEntityID
) AS Comps

The top 10 Alerts grid uses the following query – copied from
SELECT TOP 10 SUM(1) AS AlertCount, AlertStringName
WHERE TimeRaised is not NULL
GROUP BY AlertStringName, AlertStringDescription, MonitoringRuleId, Name

HealthService event 4506 and AD Integration

So I’ve created an “Auto Agent Assignment” rule on one of my management servers. On the RMS server which is solely responsible for publishing and updating AD I get quite a few of the following events in the OperationsManager event log
Eventid 4506
Description: Data was dropped due to too much outstanding data in rule “_Domain_ManagementServer_Domain running for instance “RMS servername”….

This event will happen when you’re Auto Agent Assignment Rule is returning to many records to be inserted into the Security Group.

My rule was returning all devices with *xyz* in the device name.
To fix this I changed the assignment rule to only return servers with *xyz* in the name and the operatingsystem containing *Server*
SO: (sAMAccountType=805306369)(name=*xyz*)(operatingsystem=*Server*). This caused the RMS server in-time to update and change the security Local Domain group for the management server.

If you still get these messages you need to further breakdown and filter the devices. One option will be to split the devices between more than one management server.

Agent Installation Error Codes

Below is explanations of some of the failure codes that you get when installing SCOM agents

80070005 = No access with the account
800706ba = RPC server not available, basically this happens on the branch servers. If you ping the server it returns where it must have been A quick way to fix this is to add both records in the hosts file on the SCOM server that you are installing the agent from, must be in format

80070643 = prerequisites ie SP1 of Windows 2003 is not installed on the server

The agent installation logfiles for the agents is in the following folder: C:\Program Files\System Center Operations Manager 2007\AgentManagement\AgentLogs on the SCOM server. In here there is a file for each of the agents that you are installing.