Archives

I was asked by BDNA, to follow in Wally’s footsteps and give the second BDNA ConfigMgr Guru webcast. And I’ll be followed by the ConfigMGr SQL God John Nelson himself in the 3rd session.

Now, I have been in good company before, but oh my, this is close to insane. As the quiet shy guy, as you all know, it doesn’t take much to make me just stand there like a little wallflower saying nothing, but these 2 are intimidating to say the least.

I’ll be presenting on

Maintaining your Application Deployment History when Re-deploying a Workstation

Plenty of ways to do this, and we’ll throw out quite a few different ones. Session is followed by some Q&A aka brainstorming on this topic.

Now, registrations have been going really, really well. (620 registered attendees so far with a week to go). The BDNA folks are aiming at 700, since I am an eager beaver, I am asking you guys to help spread the word on this event as I am aiming at 1.000.

If we hit 1.000 registered attendees, I’ll be ending the presentation with discount codes for both SccmAutodoc, and my freshly to be released tool ConfigMgr Instant Delivery (to be released next month).

Our general feeling was that the fact that the admin console limits you to submitting 100 items to be categorized at one point it time most likely made people stop uploading data all together. Because of that I quickly hashed together a script to upload all your uncategorized items at once. The catalog processing process requires a software title to be reported 4 times before it is added to the queue for categorization.

I'll share the script to upload you data from Asset Intelligence, and me and Brian, one of my fellow MVP's kindly request everyone to start uploading all of their titles. At the summit we had 2 large companies submit over 60.000 software titles and we are busy convincing some other large companies to do the same. A couple of large companies impact however will be neglectable to all the smaller ConfigMgr shops to follow suit and start submitting as well.

For those of you that don't use Asset Intelligence yet, we urge you to strongly consider start using it.

One other adjustment I made to the sample is modify the error-handling catch block to accommodate for COM exception handling. There is a fair chance that triggering these methods fails. It might fail because you don't have the necessary permissions, because a firewall is blocking access to WMI, or because the machine you are targeting is not online. Any of these type of failures will result in a hard error in the existing SDK sample as it will trigger a COM exception which isn't handled by the catch block in the sample. To trap COM exceptions you need to use a specific exception type called System.Runtime.InteropServices.COMException.

Quite a few people have been hit by an issue where statview.exe, or the status message viewer in ConfigMgr2007 is taking 99 or 100% cpu and is taking a long time before displaying the status messages. The general fix for this has been to open the taskmanager and to set the process priority of the Sccm statview.exe to "Below Normal".

Below you'll find a script to set the status of these processes by vbscript. (Vbscript gladly re-used, with very minor modifications from this blog from the scripting guys, credit where credit is due, thanks guys.)

Now, the script is nice in and by itself, but still requires you to run it every time you open the status message viewer. That's where WmiEventing comes in, lets just create a scripteventconsumer that modifies the process priority each time it is launched.

The ActiveScriptEventConsumer

The active script event consumer allows you do define a filter, where we filter on process creations using the __instancecreationevent class.

In here we filter on processes named statview.exe.

Subsequently, we create an activescripteventconsumer, that embeds the above script from the scripting guys.

Lastly we bind the filter to the activescripteventconsumer.

Below, you'll find the mof to have this implemented, just compile on any machine that has the ConfigMgr admin console by running Mofcomp -Autorecover statviewfix.mof

In this step-by-step guide, they essentially go into the WSUS Console to create an Auto-Acceptance rule. First of all this should make any ConfigMgr admin shiver, as it should have been drilled into your head that you are supposed to do software updates management from the ConfigMgr administrator console.

Now, I have never understood why they didn't solve that in a more elegant manner. The solution works, however has a couple of drawbacks. First of all the original article was written by the FCS product team and hence initially their has been some debate whether this was a supported solution. That has all been sorted out now, and the solution is officially supported.

Additionally in a multi distribution point environment, the actual definition updates will always come from the Software update point, whereas normal software updates come from the distribution points. In other words, this impacts scale quite a bit, and forefront definitions come out at a very frequent pace meaning they are hitting you software update point harder than anything else.

The main problem, is that in SCCM 2007 we have no "easy" way to create an Auto-Acceptance rule. However, the SDK contains an end-to-end sample on software updates that:

Downloads specified software updates

Puts them in a Software Updates package

Distributes the package to all distribution points

And subsequently deploys these updates to a collectionid you can specify when running the end-to-end application.

A couple of weeks ago John Marcum asked whether this couldn't be used to auto-approve forefront definition updates as he didn't like the current implementation.

I shot off my big mouth (should have known that staying quiet and shy gets you into less problems), saying that this shouldn't have to be terribly difficult, and hence John called my bluff asking to have it built. Did that and delivered on it 2 weeks ago, and after John and me running some thorough tests, it seems to work fine. I will be sharing a link to the tool at the bottom of this post. All I did was

Modify the SDK Sample to work with FCS and FEP 2010 updates as opposed to the original security updates in the provided sample

fixed a bug where the tool would crash if a software updates package existed with the same name, essentially killing the ability to re-run the tool.

Added a test for whether the updates had already been download to avoid downloading updates 2 times

Made the code to reuse the same deployment and update package each time around as creating new ones each time a definition would come in in would just generate way too many objects.

That worked out fine, however left me with a command line tool that needed to be ran for new definitions to be approved, which beats approving them manually, but fails horribly in stacking up against the WSUS auto-acceptance rule approach. So we needed some eventing to solve that issue. I could have reverted to my new found love of "WMI eventing" however I figured that approving new definition updates didn't need to be instantaneous, so instead of using WMI evening, I relied on status filter rules for this particular "eventing" need.

I configured my Software Update Point to sync with microsoft update every hour, and created a status filter rule for the deployment to occur after each successful Wsus Sync.

IMPORTANT: Read the SDK EULA.RTF in the zip file before using this. This remains a sample, and it is your responsibility to test this before using it! No warranties or support of any kind is given with this free tool.

In the first couple of post 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.

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.

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.

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.

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

write a script that subscribes to these events

Once an event is fired, identify the foldername of the folder that had an object added (based on the containernodeid)

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

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.

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.

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:

At my MMS 2010 presentation in Las Vegas last week I promised I would start blogging about WMI. Given my pretty strong background in SCCM / ConfigMgr most of this WMI blog will be related to SCCM. This product has been one of the prime and still is one of the largest consumers of WMI.

WMI and WQL are used by:

Dynamic Collections

Queries

Hardware inventory

DCM

The Admin console

And to store the client settings on a ConfigMgr client

Plenty has been said and written about a lot of these uses, yet one thing has been left out over the years, yet it was there staring us in the face from day1. WMI eventing has been around for nearly a decade, and we could have made great use of it over that time, so that’s what I’ll focus on in the next coming weeks.

What is WMI eventing?

Very simply put, WMI eventing allows you to perform certain actions each time any WMI class or instance is created, deleted or modified. This might seem like a benign thing, but once you put your head around the power this could bring to any ConfigMgr / SCCM environment I promise that each and everyone SCCM Administrator reading this blog will be shouting: “The M in WMI stands for Magic because schedules are boring and events are sexy”.

WMI eventing has 6 different event classes called:

__instancecreationevent

__instancemodificationevent

__instancedeletionevent

__classcreationevent

__classdeletionevent

__classmodificationevent

The names are rather self-explanatory and as you might have figured out they generate an event for instance or class creation, deletion or modification.

That’s it for now, in the next post I will start by explaining how you work with WMI events by using Wbemtest.