Tag Archives: Auditing

Let SCOM check for Updated Management Packs

21 Apr

The challenge

Using the SCOM native console the import from the Microsoft Management Pack Catalog is a nice feature. I like also the feature to check and import updated MPs that you have already imported in your management group. But what I really miss and don’t understand : why did the product team removed the monitor that gives us a alert when a new MP version is in the MP catalog ?. This monitor was build in MOM 2005 but removed in the begin of SCOM 2007.

The solution

So since we are SCOM author diehards we are going to build our own MP update monitor. I am going to use VSAE to build it all. But wait even if you aren’t a SCOM author diehard it still worth reading this post because this time I will share the VSAE project and even the MP with you at the end!!!


So I used my good old friend ‘Fiddler’ to backward-engineer what the scom console is doing when I press the ‘check for updated management packs’ button. It seems it sends a SOAP request to a webservice. The SOAP request contains a MP list of the MPs that you have already imported. The answer result of this request will be a MP list with the updated MP versions or an empty list if there aren’t any updates for you.

Building time

Below I’m going to give you a overview what I have done. You can look in the VSAE project for details on it. If you have any questions just let it know and I will help you out.

1) The datasource

So now we are going to make a datasource that runs a PowerShell script. This PowerShell script is simulating the webservice request.

Below a snippet of the code. (the full code is in the VSAE project). What I am doing here are 3 steps:

1) Build a SOAP request message that contains all my MP version meta data from all MPs that I have already imported in my management group.

2) I call the “ManagementPackCatalogWebService.asmx” and execute the method “FindManagementPacks”

3) as last step I check if there are any MPs returned and set the $Status flag according the result. And I return the scom property bag.

# step 1

$MPSoap = get_MP_List
$ret = Do-SOAPRequest -SOAPRequest $MPSoap -URL $MPCatalogURL -SOAPAction $SOAPAction

# step 2

## show MPs that have a Update
$MpList = $ret.Envelope.Body.FindManagementPacksResponse.FindManagementPacksResult.CatalogItem | where { $_.IsManagementPack -eq $true} | select-Object DisplayName

# step 3

## check MP returned

if ( $MpList.Count -eq 0)

  # Create the property bags
$pb = $oAPI.CreatePropertyBag()
$pb.AddValue(“MpList”,($MpList | Out-String))

The script above we are going to use in the datasource below


2) The Monitor

Now we are going to compose a 2 state UnitMonitorType that uses this datasource. The health state check is done with the “Status” value in the returned property bag.


Having this UnitMonitorType composed we can now use it in the real monitor KPI. See below for the KPI. The target is the Management server. I choose this target because I have only one MNG server in my test lab but if you have more it’s better to choose the RMS emulator target.


Now when the monitor is unhealthy it will generate an alert message constructed below:



The result

Building and importing the MP in your SCOM management group will show you the result below:


And of course a nice ALERT message also:


So now the part you are waiting for..

As promised I will share the VSAE project and the MP it self. Please notice that it is a show case alias prototype MP and so it is far from complete. For example not all display strings are applied and no knowledge is supplied. But that’s up to you to complete…. In my production version I have even build in a recovery/console task that also automatically imports the updated MPs.. Just a idea for you to work out…

MP download and VSAE project download: https://1drv.ms/f/s!Au2euLDFD_ovilTTrLl-XqSmd1tj

The End

Feel free to comment or contact me if you have any questions.


Michel Kamp

Audit SCOM SDK Usage Operations

5 May

This weekly blog post will be about the idea and wish I have a long time now: I want to see what a SCOM operator is doing with SCOM. So an Audit trail of the SCOM SDK idea was born.

The Idea:

Its very simple , as a SCOM administrator you have the world for your self. You can create rules , modify overrides , import / delete Management Packs , add users as you wish. If something went wrong they can blame you for it. That’s no problem because you are the the only one that know how to fix this.  But what when you are not the only one with administrator privileges. Who is blaming who ? And if blaming isn’t the issue how do I know What , Who and When something has changed (the 3 audit W’s)  ?


On the web there are plenty of solutions that try to solve this. Most of them are using SQL triggers to catch the functions the operator is doing and a separate DB to store the generated audit records. This solutions have a very big impact on the SQL engine and I think by applying the triggers to the tables you lose your Microsoft Support Warranty. And what will happen by applying a SCOM service pack …. So this is not the way to go.

I was thinking , since SCOM uses ADAM/AD LDS  for user&operations authorization why not just go this way. Every call to the SCOM SDK (the native scom console, web console,power shell , connectors,ect…) will be checked for authorization . This is done by the Active Directory Lightweight Directory Service (AD LDS), formerly known as Active Directory Application Mode (ADAM). And the nice part of this is that there is a tool that lets you read and edit this authorization store. The tool is called “Authorization Manager”. You can find it as a MMC Snapin. I will show you this later on. For SCOM the authorization catalog can be located on disk as XML file or as a SQL tables. Not going into the details , SCOM 2007 SDK uses a file store and (yes) SCOM 2012 SDK uses a SQL table store. And now the reason we dig into this all: The Authorization layer has a AUDIT trail build in !!!. Simply enable it and setup the correct audit policy and we are getting audit records…

That’s however in theory ….

The real world

Of course I have tried it out before I wrote this post. And yes we are getting audit events and yes it are events for every SDK operation and NO they do not contain parameter information. (95%not) So we can see what operation is executed but can’t see the parameters supplied with the call. For example add user X to role Y. We see the add user role operation but don’t see X and Y in the audit event. Does this make my ideas useless ?  I think not. I found out that there are still some events useable. And hopefully I can get the SCOM product team so far implementing the missing parameter logging.

Some LAB testing

I will now show you how to get the audit events.

Login to the OM2012 MNG server. Open the MMC console. And add the “Authorization Manager” snapin.


The first time you will see this below:


Now we are going to make the connection to the OM SDK Authorization Store. Remember for OM2012 this in SQL.  Right click and choose “Open Authorization Store..”


Now choose Microsoft SQL. And type in the Store name. I say it very easy but believe me this one cost me hours to find out (maybe because my IQ ;–) ). There is almost no documentation on Authorization manager and SQL connection. And for sure no information where the SCOM store is located. But never mind that’s your luck , because I share it with you guys.

The connection string format I got from http://technet.microsoft.com/en-us/library/cc770467(v=ws.10).aspx and looks like:

mssql://Driver={SQL Server};Server={SCOMSQLSERVER\INSTANCE};/OperationsManager/AzmanStore

Replace SCOMSQLSERVER\INSTANCE to the SQL server and Instance where your SCOM database is on.

Replace OperationsManager with the database name you have used for the operations manager database name while installing SCOM 2012.

For my LAB it will be :


Press OK and you are ready.

You will see the store and all it groups. Browse to AzmanStore\Microsoft System Center\Role Definitions and you will see the screen shot below. And I am sure you know it from the operations manager console!


Now press right button and select properties –> Definition. And you will see all the SDK operations (tasks) a SCOM administrator role can do. So every time the SDK receives a operations from for example the native console it will first check if this operation may be executed by this user. You can even add or change some operations.  So you can add for example Rule__Get to a normal operator so the operator can now see the rule properties. REMEMBER IF YOU DO YOU MAY LOOSE YOUR MICROSOFT SUPPORT.


If you are curios what all the operations availably in SCOM are, Go to the Add… and press Operations. Now you will see the complete list of operations. And this one is huge..


So explained all of this you may forget it quickly now. They only thing we have to do is set the auditing flag on the store. Right click on the azmanstore and choose properties.


Now go to Auditing and enable the 2 auditing boxes.


I just wanted to show you all of this because it is fun core level stuff. But as it seems this 2 boxes are enabled by default. So the next time you can skip this part too. Sorry if I wasted your time

The only real step we have to do is enabling the security auditing policy. So lets do that. First this. The audit records are written to the server eventlog where the SQL server instance is installed. So if you have a 2 box scom installation , one OM , one SQL. You must login to the SQL server to proceed. If you have a 1box scom installation you login to the OM server.

Open the Local Security Policy editor. And enable “Audit object access” for Success and Failure.  Press OK and the events will flow in.



So lets look at the events. Open the windows event viewer and go to the security logs. This will show a huge number of events. Better is to create a custom view by only selecting events with Source  MOMSDK Service Security or Task Category (3).


Now if you look at a event you will notice that it has some basic information about the operation and the user plus session it belongs too. The part that is missing for a lot of operations are the parameters belonging to the operation (Data access method) if this was supplied we where done. However I found some operations that give the missing parameter information. For example when you create a new MP you will see this event. Look at the extra info given. 


Same for the MP delete


I haven’t looked at all the operations but as far I can see now there are not a lot of operations with extended information. Again I hope it will be added soon with a service pack release.


With the solution described we can see What is done and Who has done it and When its done. The only part missing is some extra information on the What part. So we can really see what this operator is trying to do. But better than having nothing it’s a good start.

To be continued:

I am trying to convince the OM product team to look at this. Meanwhile I have a other idea I will try to work out to solve this.  I will try to post it soon.

Hope you had a good time and again…