Avatar of filip

by filip

Parsing error in a custom MOF file during extending the Hardware Inventory Classes

February 8, 2016 at 1:42 pm in Uncategorized by filip

Hello All,

At the moment I’m implementing SCCM 2012 SP2 for a customer.

They have a specific requirement for creating collections based on registry keys and values.

This can be done by extending the Hardware Classes for the Hardware Inventory process.

There are already several good blogs which can be followed to achieve this (such as: http://it.peikkoluola.net/2013/06/20/extend-sccm-client-hardware-inventory-with-a-custom-attribute-value/) and I had implemented this already several times.

Only this time, I saw some errors when importing the configuration.mof file:


It seemed something was wrong with my syntax.

The RegKeyToMof.exe had always compiled perfect code to paste into the MOF file.
What could be wrong with it now?

There is a utility which can be used to verify the integrity of MOF files: mofcomp.exe.
This executable comes with a parameter that will check your mof and show if errors occur: -Check

When running the mofcomp.exe with the check parameter, I got the following (more detailed) error message:


It seemed as if an opening brace is missing at line 275; let’s go ahead and check that line:


The registry key we are trying to import is called M@gStation.
The ‘@’ in the name is fooling the interpreter that this isn’t just the classname, but the definition of a new class.
The RegKeyToMof.exe takes over the name of the registry key as the classname.
In most cases this isn’t an issue, unless it contains special characters.. D’OH!

After renaming the ‘@’ to ‘a’, no more errors were noticed and the integrity of the mof file was confirmed:

First using the mofcomp.exe:

Secondly after having placed the configuration.mof in the appropriate inbox

Hope this helps someone out there J

Avatar of filip

by filip

SCCM 1511 available on MSDN

December 8, 2015 at 11:29 am in Uncategorized by filip

Hello All,

The new version of System Center Configuration Manager (v1511) is now available for download on MSDN


So far it is not yet GA on the VLSC portal, but surely this will not take long after this release.


Below is a link to a good blog describing new features and upgrade instructions:





Avatar of filip

by filip

How to Schedule an Orchestrator runbook using SCSM

October 8, 2015 at 8:20 am in Uncategorized by filip

Hello all,

I’m back again with an orchestrator trick J

I’m currently doing some work for a customer that wants to start using their Orchestrator infrastructure to get rid of the different scripts and scheduled tasks that are running around in their environment.

As we all know Orchestrator is not really intended to use as a task scheduler, but the customer is always right so a solution was needed J

There are known workarounds to trigger an Orchestrator runbook on schedule:

  • Using the schedules within Orchestrator
  • Using the task scheduler

The first option is not an option I would recommend as this means that you always need to have that runbook in a running state.

The schedule activity runs as a monitor and this requires your runbook to be started.
A runbook server can only have a limited amount of simultaneous running runbooks, so it is best to avoid this as much as possible.


The second option would have been an option i fit weren’t that the customer wanted to get rid of the scheduled task and started leveraging their System Center deployment as much as possible.


This got me thinking: why not use an SCSM workflow that will trigger the runbook using SCOJobrunner?

Before we can begin, there are some pre-requisites which you need to fulfill:


  1. First lookup the GUID of the Runbook to trigger using the ListAllRunbookGUIDs.PS1

  2. Open the Authoring Tool


  1. Once the Authoring Tool has launched, select to create a new Management Pack
  2. Give the MP a descriptive name 


  1. Select to create a new workflow

  2. Within the New Workflow Wizard, enter settings as appropriate :
    1. Enter a Name and description for the workflow

    2. Enter the schedule on which you want to trigger the workflow

    3. On the summary window, click the Create button


  1. Once the workflow is created, drag the Powershell script action onto the workflow pane and click on the powershell action

  2. When the Powershell action is selection, the details pane should be shown as below.


  1. Within the Details pane, click on the ‘Script Body’ line.
    An ellipses button shoud appear


  1. Click on the button to open the script body field.
    Paste the following script into the body field (the GUID is the GUID retrieved in the first step, update the path to the SCOJobRunner.exe to match your environment)


  1. Click Ok to save the Script body field
  2. Update the Activity Name field to give your action a descriptive name in the workflow overview (this is optional)

  3. Next, save your management Pack
  4. When you browse to the location where you chose to save the management Pack, a list of files will be shown.

  5. Copy the DLL file to the install folder of your SCSM Workflow Management Server

  6. Next up, the newly created management pack needs to be imported in the SCSM.
    To do this, open the console and navigate to the Administration Pane.
    Right-click ‘Management Packs’ and select : Import

  7. Select the XML file and click Open

  8. The following Import windows will be displayed. Click the ‘Import’ button below

  9. The wizard will indicated the output

  10. To verify that the workflow is present, navigate to the Worklow section and enter the name you choose in step 6a. The workflow will then be shown



This will now start triggering your runbooks on the desired schedule.


Happy automating !



Avatar of filip

by filip

Monitor the status of an Orchestrator runbook using SCOM

August 14, 2015 at 2:26 pm in Uncategorized by filip

Hi all,

I’m currently working for a customer that has an Orchestrator runbook that should always be in a running state.
It monitors whether a certain type of Incident Request has been created in SCSM and if so, it sends out an email message.
If this particular runbooks stops, then no more email notifications are sent out for this type of IRs.

The Orchestrator database resides on a cluster of which frequent failovers happen.
Sometimes during such a failover (when a failover takes too long) Orchestrator looses its connection to the SQL instance and the runbook is stopped.
The customer only notices that the runbook has stopped when users start complaining that they no longer receive email notifications for new Incident Requests.

Since they have SCOM deployed as well, such reactive “monitoring” is of course a big no no Glimlach

Therefor I thought to build them a script based monitor using Silects MPAuthor, which will notify us if the runbook stops.
In the following steps, I will show how I created the monitor and which scripts have been used to query the Orchestrator webservice.

First, I needed to write the scripts needed to query the webservice.

The result will be placed inside a SCOM propertybag so that the Health service can receive the result:

This is what I finally came up with:

$API = New-Object -ComObject “MOM.ScriptAPI”
$PropertyBag = $API.CreatePropertyBag()

$user = “<<Serviceaccount>>”
$pass = ConvertTo-SecureString “<<Password>>” -AsPlainText -Force
$creds = New-Object System.Management.Automation.PsCredential($user,$pass)
$url = >:81/Orchestrator2012/Orchestrator.svc/Jobs()?$expand=Runbook&$filter=(Status eq ‘Running’) and (Runbook/Name eq ‘>’)&$select=Runbook/Name,Status">http://<<OrchestratorFQDN>>:81/Orchestrator2012/Orchestrator.svc/Jobs()?$expand=Runbook&$filter=(Status eq 'Running') and (Runbook/Name eq '<<RunbookName>>')&$select=Runbook/Name,Status
$request = [System.Net.HttpWebRequest]::Create($url)
$request.Credentials = $creds
$request.Timeout = 120000
$request.ContentType = “application/atom+xml,application/xml”
$request.Headers.Add(“DataServiceVersion”, “2.0;NetFx”)
$request.Method = “GET”
$response = $request.GetResponse()
$requestStream = $response.GetResponseStream()
$readStream=new-object System.IO.StreamReader $requestStream
$Output = $readStream.ReadToEnd()
$Result=$Output -match “<d:Status>Running</d:Status>”

Once we have the script, we can almost begin building our monitor in Silect but first we need to do some more preparing on the server which will execute the script.
As you know, a monitor runs on specific targets.
Within MPAuthor, we will also be asked against which target we will run our monitor.
A target can be defined in several ways. I like to create a custom registry value on our monitor target.

As I want to run the monitor locally on our Orchestrator server, I went ahead and created the following key:

With this in place, we can now open up MPAuthor and start the madness Emoticon die tong uitsteekt

Create a Blank Management Pack

1. Give your MP a logical name

2. Specify where to store it

3. Accept the default referenced other MPs

4. Select to create an empty Management Pack

5. On the Create page, review your settings and click the create button

Create the Discovery rule and Target

1. Right-click the Discoveries node and select a new registry target

2. Select the server where you want to browse towards to lookup the custom the registry value which we created earlier

3. In the browse windows select our ‘SCORWatcherNode’

4. Once select, it should look like this

5. Give your target a logical name

6. Give your discovery a logical name

7. Select the Windows Computer Class as your target base class

8. On the expression page , accept the default expression

9. On the discovery schedule, enter which schedule suits your needs best.
I choose 4 hours

10. On the Create page, review your settings and click the create button

11. Once completed, you should now see your Discovery and your Target


Create the Monitor

1. Right-click the Monitors pane and select create newscript monitor

2. On the Script page, enter a name for the script and paste in the script which was mentioned above

3. The second screen can be a bit confusing.
It starts off with a 3-state monitor.
In this case, we only need a 2 state monitor, therefor only keep the UnderWarning and OverError states (these statenames can be customized as well, I kept them at defaults for this example).
You have to click each state and modify the criteria for the selected monitor.
The Propertyname should match the propertyname you entered in the propertybag of the powershell script.
As we have a 2 statesmonitor, we should do this for both states

4. Now select to target our script monitor against all instances discovered by our newly created target. Parent monitor should be Availabilityclip_image043

5. Give your monitor a logical name

6. On the Scedule page, select a schedule that suits your needs.
I’ve choosen to run our monitor every 10 minutes

7. On the Alert page, setup the way you want alerts to be generated.

8. On the create page, click the Create button

9. We now can see the monitor has been saved in the MP

Importing the MP into SCOM

From MPAuthor, we can import the newly created MP directly into SCOM but for this example I’ve imported it manually

1. Open the SCOM console and navigate to the administration pane

2. Right click the Management Packs node and select Import

3. Select the xml file for the management pack which we just created and hit the import button. After a while, the following should be shownclip_image057

4. Next up, I connected to the Operations Manager eventlog of the orchestrator server to see if the MP got downloaded.
After a while, I saw that so far everything was going smoothly

5. Now that the MP has arrived at the server which will run the monitor, we have to wait until the discovery has picked up our registry key which indicates the target for our monitor. To follow up on this process, you can go back into the monitoring pane and change the scope to point to our Target class. After 5 to 10 minutes, our Target should appear

6. If we then open up the health explorer, we will then see our monitor and in this case it has already gone into a monitored stateclip_image063

7. To test the monitor, I stopped the runbook and after a while it went into error (as expected) and place our server into redclip_image065

8. If we go into the alerts view, then we also see the alert

And that’s it.
That’s how easy it is to monitor the state of an orchestrator runbook using scom and some MPAuthoring magic!

As a follow-up article, I’ll show you how you can define a recovery task which will call an orchestrator runbook to rectify the problem and to restart the runbook.

Please feel free to re-use this logic for any kind of script monitor you need.

If you got any questions/remarks, then don’t hesitate to contact me

Hope it helps Glimlach


Avatar of filip

by filip

Hello World !

August 14, 2015 at 11:03 am in Uncategorized by filip


Hi Everyone,

My name is Filip Theyssens and I have been following the SCUG blog for over a couple of years now.
At the moment I’m working together with Dieter Wijckmans on a project and as a good SCUG ambassador he kindly invited me to start blogging as well.

At the moment I’m working as an independent consultant for several service providers in Belgium.
My main focus is on several products of the System Center suite, so you can expect some blogs about SCOM, SCCM, SCSM, SCORCH and (since recently) Azure Pack from me Glimlach


I hope you’ll enjoy reading my posts and should have any questions, then don”t hesitate to send me message!

See you guys soon!