How to Analyze a SCOM Property Bag
From time to time I find myself writing PowerShell scripts for custom workflows: discoveries, rules, monitors, tasks, etc. Often times the project at hand requires a property bag full of juicy data to be used in the workflow. There are a handful of other blogs that describe what a property bag is but here I’ll show you how to make your property bag experience just a bit easier.
When you want to harvest data with a PowerShell script and then return that data to the workflow (to be used any number of ways ) name value pairs get returned in what is called a property bag. A property bag is simply XML structure that looks like this:
<DataItem type="System.PropertyBagData" time="2018-08-30T20:33:12.2154943-06:00" sourceHealthServiceId="c0c09ff6-3834-fc37-4bb9-1633c62eda56">
<Property Name="Fingers" VariantType="3">10</Property>
<Property Name=”Toes” VariantType="3">10</Property>
<Property Name="Eyes" VariantType="3">2</Property>
The XML dataitem includes the following information:
- This is a property bag.
- A timestamp indicating when it was submitted to the management server.
- The name/value pairs contained in the property bag.
The VariantType describes the type of the value that is returned. The typical variant types are:
0 = Empty
1 = Null
2 = Short
3 = Integer
4 = Single
5 = Double
6 = Currency
7 = Date
8 = String
9 = Object
10 = Error
11 = Boolean
12 = Variant
13 = DataObject
14 = Decimal
15 = Byte
16 = Char
17 = Long
The property bag is a pretty simple animal but sometimes it can produce unexpected results. When that happens it helps to be able to see what the property bag contains when testing your script. Here’s a sample script which creates a property bag and displays the dataitem to the screen:
#Script: Test.ps1 # Here we create the com object $api = new-object -comObject 'MOM.ScriptAPI' # From the com object we spawn the bag. Now we can stuff things into the bag. $bag = $api.CreatePropertyBag() # Here I've added an assortment of different type things to the bag. # They each have a name and a value. $bag.AddValue('ONE',[string]"My String" ) $bag.AddValue('TWO',[Decimal]9876543210987654321) $bag.AddValue('THREE',[double]987654321 ) $bag.AddValue('FOUR',[int]4444 ) $bag.AddValue('FIVE',[float]55.66 ) $bag.AddValue('SIX',[byte]56 ) $bag.AddValue('SEVEN',[datetime]"03/04/2012" ) $bag.AddValue('EIGHT',[long]987654321 ) $bag.AddValue('NINE', $null ) # Here is how I would ordinarily return the bag so # that the SCOM workflow can use the contents of the bag. $bag # Here is how I can display the contents of the bag to the screen. This is # useful only when testing the script manually. $api.Return($bag)
Run the script from an ordinary PowerShell console (not ISE):
It’s pretty easy to get the data to display on the screen but it’s a messy blob of confusing text. This example is small. Imagine if you had dozens or hundreds of name/value pairs in your bag. It would be a nightmare to comb through all of it. You could copy/paste the text from the console into a text editor and try to reconstruct all of the broken lines but that’s an awful waste of time.
Solution: Output that data to a text file and format it easily with Notepad++ . (NPP can be found easily with a quick search of the innerwebs. Yes, innerwebs.)
Output the property bag to an .xml file. This is easy with the redirection operator:
Open the file with Notepad++. The file is still ugly. Let’s fix that.
Format the data with the XML Tools plugin:
Note: You may have to manually add the “Plugin Manager”. This is pretty easy. It involves extracting a few DLLs into the Notepad++ Plugins directory. Once Plugin Manger is available, you can add tons of plugins with a few clicks, including XML Tools. There’s a blurb about it here.
Note: Line 1 is a result of the script statement:
Lines 2 – 12 are a result of the script statement:
You'll also notice that in line 10 the variant type is "20". It was cast as a "long" which PowerShell equates to "System.Int64" and I would expect it to end up as VariantType="17". I don't know what type "20" is and I don't have time to research it. Anyone want to hunt it down? I'm sure it's in some schema doc somewhere. This is an example of getting something unexpected in the property bag.