The "quiet shy" WMI guy aka Kim Oppalfens

“securable” Configuration Manager folders using WMI eventing – script explained

In the previous post I explained how we could fake securable configuration manager folders using WMI eventing.

In short, we created a child object in each folder with the same name as the folder.

Subsequently in WMI eventing each time an object was moved we would copy the permissions assigned to this “Dummy” object.

In this post we’ll delve into the script and see how it works.

Part1: Subscribing to the WMI Event for an object move

If an object is moved back to the root than an __instancedeletionevent occurs. Note that we don’t subscribe to __instancedeletionevent so nothing will happen by moving an object back to its root node.

If an object is moved to a different folder than an __instancemodificationevent occurs. Note that we don’t subscribe to __instancemodificationevent so nothing will happen by moving an object from one folder to another. We would need a second almost identical script to subscribe to modification events to achieve this.

Line 35 creates an SWbemSink object, which is how you subscribe to WMI events in an asynchronous manner. The SwbemSink object objWMISink will receive an event instance each time an event is fired. The “SINK_” is the prefix of the Subroutine that will be called each time an event is ready to be treated. In our case each time an event comes in we will execute the subroutine called sink_ONOBJECTREADY. As you can see the SINK_ part is up to us to decide the ONOBJECTREADY is fixed syntax.

NOTE:

Nick posted another method using a semi-synchronous manner here: http://myitforum.com/cs2/blogs/nickaquino/archive/2010/05/07/monitoring-collection-membership-with-wmi-events.aspx To me, both are equally valid. Asynchronous is slightly more performant, however semi-synchronous is more firewall friendly, and probably more in line with how most SCCM vbscripts are written, right now.

PART2: Executing the sink_ONOBJECTREADY subroutine.

In Line 74-77 we fetch the name of the folder where the object was added to.

Line 80 and 81 store the objectid and objecttype for later usage.

In Line 85, we verify which objecttype was moved to a folder, we’ll explain the code for objecttype=2 which is an SMS_package, the code for the either objecttypes is very similar so I won’t discuss these.

Line 90 stores the objecttype for later usage.

Line 91-94 fetches the unique objectid of the “dummy” object or the object with the same name as the folder which stores our security settings, and stores that ID for later usage.

Now, that we have the objecttype(Line 82), the objectid of the object moved (Line 81) and the objectid of the “dummy” object (line 94 in our sms_package case) We can continue and copy the instance permissions.

Part 3: Copying the instance permissions.

Line 211 queries for the userinstancepermissions defined on our dummy object as stored in Line 94 in PART2

Line 212 executes the CopySourceObjectPermissions.

Line 220 to 227 cycle through each instancepermission found for the source object and create a new userinstancepermission with objecttype and objectid as stored in line 80 and 81 of Part1

That’s all folks!

See, WMI eventing does not have to be difficult.

--

Enjoy the dive into the Dark Magic of WMI.

"The M in WMI stands for Magic"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx

http://www.linkedin.com/in/kimoppalfens

http://twitter.com/thewmiguy

Create “securable” Configuration Manager folders using WMI eventing of course

Hi All,

One popular request amongst SCCM admins is the ability to set folder permissions. Unfortunately folders aren’t securable objects in SCCM 2007 so the response usually was “Sorry, no can do”. Now that was before we knew/applied the power of WMI eventing. We have taken 2 baby steps in WMI eventing for ConfigMgr admins so far, and Nick Aquino already posted a script to take advantage of scripting WMI events http://myitforum.com/cs2/blogs/nickaquino/archive/2010/05/07/monitoring-collection-membership-with-wmi-events.aspx time to jump off a cliff and skydive I guess. I will come back to Nick’s post in a future blog post.

Magicians usually don’t reveal how their Magic works, but I’ll spill the beans for once on this one.

Folders aka sms_objectcontainernode objects do not have the ability to be secured. Or alternatively put they don’t have their own objectkey within the sms_securedobject class and hence you cannot create an instance of sms_userinstancepermissions to define security on them.

The following list are securable objects:

SMS_Package, SMS_Advertisement, SMS_Query, SMS_Report, SMS_MeteredProductRule, SMS_ConfigurationItem, SMS_OperatingSystemInstallPackage, SMS_ImagePackage, SMS_BootImagePackage, SMS_TaskSequencePackage, SMS_DriverPackage, SMS_Driver, SMS_ConfigurationItem (Configuration baseline).

So setting permissions on folders does not work, however we could envision creating an object with the same name as the folder for each folder we create. In other words if I create a folder “virtualapps” in my packages node, than I could create a dummy package called “virtualapps”. This package would be a securable object, and I would be able to set any permissions applicable to packages on that virtualapps package.

So that’s the general idea, duplicate your folder names as securable “dummy” objects. We will then use wmi eventing to copy over the permissions applied on the dummy object to the freshly created/moved object in the folder.

So far for the general introduction. Now, how do I know when an item is being added to a folder. That’s easy enough the link between a folder (sms_objectcontainernode) and the object is stored as an instance of sms_objectcontaineritem. So subscribing to objects being added to a folder is as simple as executing the notification query:

SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'SMS_ObjectContainerItem'

See WMI eventing doesn’t have to be difficult at all.

All that is left to do is

1. write a script that subscribes to these events
2. Once an event is fired, identify the foldername of the folder that had an object added (based on the containernodeid)
3. find the “dummy” object of the same name and objecttype (oh yeah, forgot to mention that sms_objectcontainernodes do have an objecttype so that the names only need to be unique within the objecttype
4. Copy the instancepermissions of the “dummy” object over to the object that was added to the folder (or targetinstance.instancekey in WMI eventing ling)

That’s it 4 easy steps and we are good to go. You can find the script to do this attached to this blogpost.

I will go over the code in Part2 of this blogpost and explain what it is I am doing.

Donwload the script from skydrive here: http://cid-2c4ac2127eae73d5.skydrive.live.com/self.aspx/Public/bloglinks/inheritfolderpermissions-standalone2.vbs

--

Enjoy the dive into the Dark Magic of WMI.

"The M in WMI stands for Magic"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx

http://www.linkedin.com/in/kimoppalfens

http://twitter.com/thewmiguy

Looking at WMI eventing from within Wbemtest – Part 2

Hi All,

In Part 1 of this blog series we opened up Wbemtest and subscribed to advertisements being created that did not have “MassDeployment” in its comment field.

In this part we’ll look at what the subscription shows us when an advertisement is actually created.

Below is the screen you’ll seen when waiting for the event being triggered.

The screen will display the below when an advertisement is actually created.

As you can see an event has now been triggered, you can double click the __instanceCreationEvent=<no key> entry to open the event data.

If you check the “Hide system properties” checkbox than you’ll see the following screen.

The most interesting part is that each instancecreationevent has an embedded object called TargetInstance. This is a representation of the WMI object SMS_Advertisement that has just been created, and here comes the interesting part, if you double click on TargetInstance and click “View Embedded” than you can actually see all details of this newly created object. This single fact makes WMI eventing hugely interesting.

In my next posting I’ll explain how you can use WMI eventing from something slightly more flexible as Wbemtest.

--

Enjoy your first baby steps into the Dark Magic of WMI.

"The M in WMI stands for Magic"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx

http://www.linkedin.com/in/kimoppalfens

http://twitter.com/thewmiguy

Looking at WMI eventing from within Wbemtest – Part 1

Hi All,

I have spent quite a while looking through WMI in both SMS and ConfigMgr and my favorite tool to do exactly that is still good old Wbemtest. Wbemtest is probably the notepad of the WMI explorers, no fancy interface, no whistles or Bells, but it gets the job done, and is available on every Windows station.

In this post we will look at how to subscribe to Wmi events, in the ConfigMgr WMI namespace of course using wbemtest. I hope that this post will let you guys think about the enormous possibilities this opens to ConfigMgr admins.

Lets start by launching WbemTest.exe

This launches the wbemtest window like this, where you click the Connect button:

The connect window lets you define where to connect to:

1) The namespace obviously needs to reflect your environment so it should look like \\ConfigMgrServercomputername\sms\site_Sitecode

Where configmgrServerComputername and Sitecode are variables that need to represent your environment

You can specify an alternate user than the logged in user in domain\username format here with its password.

These credentials need to be in the distributed com users group on the ConfigMgr provider server computer and in the Sms Admins group when running wbemtest from a remote machine.

When executing locally specifying credentials is not possible.

Once connected you’ll have this window open

Now click the Notification query button as this is where you launch event subscription queries:

Now in your notification query box type the following text:

SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA "SMS_Advertisement" AND TargetInstance.comment != "MassDeployment"

And Click APPLY.

Let’s analyze what this notification query does:

1. It will subscribe to an event class call __instancecreationevent (double underscore at the front), which means it will warn me when instances are created in the namespace that I am currently in
2. the “Within 5” means that the wmi eventing system will check for new events every 5 seconds, so it will take a maximum of 5 seconds before I am told that a new instance has been created
3. “Where targinstance ISA “SMS_Advertisement” is rather obvious and means that I am only intrested in advertisements being created
4. TargetInstance.comment != “MassDeployment'” means that I am not intrested in advertisements being created that have the text MassDeployment in their comment field.

Their you have it, that’s how to subscribe to WMI events from wbemtest, in part 2 of this post (which should be online tomorrow, we’ll look at evaluating the results of our subscription).

--

And don’t forget schedules are boring, events are sexy!

"The M in WMI stands for Magic"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx

http://www.linkedin.com/in/kimoppalfens

http://twitter.com/thewmiguy