Share This Post

Using WMI eventing and SCCM in real life – Part 1

In the first couple of posts I introduced you to the power of WMI eventing and its uses for a ConfigMgr administrator, the last 2 posts where about creating securable folders, an often asked for feature. In the next few blog posts we’ll make the implementation of this feature somewhat more elegant.

Our current “solution” requires a “dummy” object, that holds our security access list, to be created each time a folder is created. In one of my future posts, I’ll show you how we can automate that. And at present when you create a subfolder it does not “inherit” any security access list settings from its parent folder, which needs to be resolved as well.

The most annoying factor however is probably that the script needs to be running all of the time for this to work. Which means that the server needs to be logged in all of the time, and that someone needs to remember to relaunch the script after a site server reboot, not exactly the most elegant implementation. Having a script running all of the time, kind of ruins my magical act as well

The “cloaking device” a.k.a. activescripteventconsumer

In our quest for the ultimate magical act we are now shopping around for a cloaking device that can hide our script from plain sight, yet still be triggered by the wave of the magic wand. On this quest I happened to stumble upon the Magician’s Shop Delivery Network, which had an __activescripteventconsumer on sale. The promo flyer stated: “The ActiveScriptEventConsumer class runs a predefined script in an arbitrary scripting language when a magic spell is spoken.

This class is one of the standard event consumers that WMI provides”

The script being run is defined in __ActiveScriptEventconsumer instance, the magic spell used is defined in WQL (Wizard Query Language) in an __eventfilter instance. And the link between the magic spell (aka Event) and the the script to be executed is defined is defined in a __FiltertoConsumerBinding instance.

That seems to do the trick, it takes vbscript code in the ActiveScriptEventConsumer and binds it to an event. The nice thing about all of this is that everything including the vbscript code is embedded in WMI. So having our actions eventtriggered can now be setup by running a simple mofcomp “FolderSecurity.Mof”.

 

Having everything embedded in WMI also solves our issue that the script has to be running all the time. The eventconsumer will get started each time the Windows Management Instrumentation service is started, and will continue to run for as long as the service is running. So this runs even if no user is logged on, which already gives you an indication that it needs a special account to run. To achieve this all eventconsumers run as localsystem, which is nice from a SCCM perspective as localsystem has full permissions in a standard SCCM installation.

In the next post I’ll explain how to build the mof file and how to install it.

Share This Post

Leave a Reply