Archive | April, 2013

Discovery’s at your demand , yes sir!

27 Apr


This time a short post. But I think this could be useful  for SCOM admins.

The challenge.

We all know that one of the big powers of SCOM is the self maintaining of the monitor targets. SCOM uses discovery’s for this that run at regular intervals. Lets say you install a new SQL database instance on a server that has already a SCOM agent on it. Normally you have to wait for 4 hours before the new database instance is discovered. Yes you can speed this up to restart the SCOM agent but now we have a better way.


First, all the credits go to the SCOM product team it self’s. It seems the feature was already build in but making it globally known was somehow left behind. There is a agent task called ‘Trigger On Demand Discovery’ that can help you out. But how to operate this task can be painful.

The solution

I have written a PowerShell script that does the hard work for you. Running this script and supplying the correct Discovery and target will result in a instantly run of that discovery. So now you don’t have to wait for the discovery interval of 4 hours to trigger.

How it works:

1) You fill in the $OMserver with the SCOM SDK server FQDN.

2) You fill in the $discoveryname with the display name of the discovery rule you want to trigger. Just copy and paste the displayname from your author pane in the scom console. See picture below.


3) You fill in the $targetdisplayname with the name of the main target where this discovery should run. You can find this name by looking at the target from the discovery rule you got from step 2.


And fill this in the inventory view.


The name “servicemanager.systemcenter.local” is the target display name to use.

btw. of course you can use PowerShell to do this for you…

Below the script:

It triggers the discovery task and then waits for the results and displays it. Be sure to look at the output results property because it only is okay when it contains :


The script.

## =======================================================
## Trigger SCOM discovery for a discovery rule and target
## ======================================================
## Michel Kamp

Import-Module operationsmanager
## OM sdk server
## discovery display name
$discoveryname=”Service Manager Management Server Properties Discovery”
## target display name

## —————————————————-
## —————————————————-
# connect to OM server
$credentials = get-Credential
new-ScommanagementGroupConnection -Computer $Omserver -Credential $credentials

# get task to execute
$task=get-scomtask -name Microsoft.SystemCenter.TriggerOnDemandDiscovery
# make override params
$discovery=get-scomdiscovery -DisplayName $discoveryname
$TargetInstanceId= (Get-SCOMClass -Id   $  | Get-SCOMClassInstance | ?{$_.displayname -eq $TargetDisplayName}).ID.Tostring()
$instance=get-scomclass -name Microsoft.SystemCenter.ManagementServer | get-scomclassinstance | ?{$_.displayname -eq $Omserver}
# run the task
$task_run=start-scomtask -task $task -instance $instance -override $override

# wait for result
while ( (get-SCOMTask -Id $task_run.TaskId).Status -eq “Started” )
    write-Output “Waiting…”
    Sleep -Seconds 2
# show task output
get-SCOMTaskResult -BatchID $task_run.BatchId

## —————————————————-
## end script
## —————————————————-

The End.

I already did some more investigation on this topic because I think when you can do it for a discovery you can also do it for every workflow that contains a timed interval trigger module. Can you imagine that you can now trigger every rule or monitor at your demand… so cool and so handy while debugging.  When I have it working I will of course share it with you “the community”.


Michel Kamp

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:!Au2euLDFD_ovilTTrLl-XqSmd1tj

The End

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


Michel Kamp

SC 2012 SP1 UR2

12 Apr


Hi ,

It isn’t any new news , since I twitted also 2 days ago the UR2 release of System Center 2012 SP1 is released.  ( )

As I write now not all software download links are working jet. So don’t get frustrated as I did…

For Installation experience see here for again an excellent post from Kevin Holman:

O wait what’s missing ?:

If you read the release notes you will notice that it mentions patching the Gateways but if you look at the software downloads you won’t see any gateway patch.

I don’t know if the gateway patch is simply forgotten to publish but if you have a environment that uses a gateway you will be stuck for now… because your agents behind the gateway will not be patched using the pending actions in SCOM.

Or not…

The solution is however not far away.
1) Just copy the Agents msp binarys to the agent management directory on the GW servers.

Path : C:\Program Files\System Center Operations Manager\Gateway\AgentManagement


1) So copy file KB2826664-AMD64-Agent.msp to

C:\Program Files\System Center Operations Manager\Gateway\AgentManagement\amd64

2) copy file KB2826664-AMD64-Server.msp to

C:\Program Files\System Center Operations Manager\Gateway\AgentManagement\x86

And at last the KB2826664-ia64-Agent.msp file to the ia64 directory.

3) approve the pending actions in your scom console. And you will see the agents behind your GW will be patched.

The end

Hope Microsoft will clear this confusion soon. Because I can’t imagine that the GW it self’s doesn’t have any fixes…

Happy scomming


a fast it comes as fast it goes….

11 Apr

Hi Community,

This post will be different that all my other posts. Past year I put quite some effort to blog on ideas and solutions to help the community. For every blog post I had to balance between work and the community. I am not referring on time but on information I am blogging about. Since I work for a hosted SCOM company that lives on System Center (especially SCOM) I do almost 24h a day SCOM. (8h at work and the rest in my head at home.) You can imagine the balancing challenge here.

In 2012 I received my MVP award for SCOM and so using all the resources (MVP mail groups, Presentations ect..) that are coming with this award I managed to work on even greater post with ideas that could help to extend the community…..

….. you can guess the next part coming of this post. Last week I received a email that my MVP status was withdrawn for the year 2013.  It looks like I didn’t contribute enough for the community. So now my question to the community: What is your opinion ?

If you think I have indeed contributed for you , let it know by voting on this site:

If you think the opposite please let me also know by comment or PM.

Meanwhile I will continue posting and focusing on VSAE developments…

And as always…

Happy Scomming