Share This Post

“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

In the first partof the Script, you can see the event query in Line 26, we are subscribing to instance creations of the SMS_objectcontainerItem. Each time an object is moved to a folder an instance of SMS_objectcontaineritem is created.

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.

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.

Share This Post

Leave a Reply