From time to time I find myself writing PowerShell scripts for custom workflows: 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:
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:
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: The easiest way to analyze a property bag is with the Show-SCOMPropertyBag function in the SCOMHelper PowerShell module. This can be used from within the PowerShell ISE as shown below. You’ll notice not only the PB item name and value, but also the VariantType code and type name.
You might find that for large values the data gets truncated on the screen. Here is how you can access the resulting PowerShell object.
Use the -Format parameter to return a hash object.
Once you have the hash object you can access the keys/values of the hash table.
Alternate 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.