Using the WMI Admin Tools to Check on Permanent Events

Using the WMI Admin Tools to Check on Permanent Events

  • Comments 7
  • Likes

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use the WMI Administrative tools to check on Permanent WMI events created by Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. We continue to get new sponsors for the second Windows PowerShell Saturday event that will be held in Charlotte, North Carolina in the United States. The event will occur on September 15, 2012, and registration will be opening soon. I am impressed with the lineup of sponsors. There should be some great giveaways, but most importantly, there are going to be some GREAT speakers—including the Microsoft Scripting Guy (me). You will want to bookmark the PowerShell Saturday website because not only does it contain information about the Windows PowerShell Saturday event in Charlotte, but it will also have information about the event for October in Atlanta.

Note   This is the fourth blog in a five part series about monitoring a folder for the creation of files that have leading spaces in the file names. On Monday, I wrote Use PowerShell to Detect and Fix Files with Leading Spaces, the scripts from that blog will be used today and again on Friday. On Tuesday, I wrote Use PowerShell to Monitor for the Creation of New Files. This blog talks about creating a temporary WMI event to monitor for the creation of files in a particular folder (a query that is crucial to Friday’s blog). On Wednesday, I wrote about using a VBScript script to launch a Windows PowerShell script in How to Use VBScript to Run a PowerShell Script. The reason for this blog is that the WMI class that is used for the permanent event consumer uses a VBScript script and not a Windows PowerShell script. From a reference perspective, you should check out the An Insider’s Guide to Using WMI Events and PowerShell. This guide is a great reference, and it provides great assistance for understanding this powerful technology.

The first thing you need to do is to download and install the WMI Administrative Tools. The tools are an old HTML application with a very small file size (4.7 MB). In fact, the package is so small, I do not even save it locally. Rather, I run it from the download page. Installation is a simple click, click, and you are done. The only default change I make is that I make the application available for everyone and not just for the installer. The splash screen is shown here.

Image of menu

After you install the tools, you will find them in the WMI Tools folder on your start menu. There are two tools for working with WMI events. The first is the WMI Event Registration tool, and the second is the WMI Event Viewer. Because these are old HTML applications, they use Active X controls that are blocked by default. Therefore, you need to unblock the control before the tool becomes useful. The Allow blocked content message is shown here.

Image of menu

After you open the WMI Event Registration tool and allow the blocked content, you need to select the WMI namespace with which to work. The tool defaults to root\cimv2, but permanent events reside in the root\subscription WMI namespace, and so it is necessary to change that location to see the ActiveScriptEventConsumer. I also create the EventFilter in the root\subscription namespace, so it will not be necessary to switch WMI namespaces to see the EventFilter registration.

Note   Keep in mind that this is the WMI Event Registration tool, not the WMI Event Viewer tool. This means that you can edit, delete, and create WMI Event Registrations by using this tool. Unfortunately, there is no Read-only mode for this tool.

The following three things must be present and associated correctly for a permanent WMI event registration to work:

  1. An Event Consumer must be registered.
  2. An Event Filter must be registered.
  3. The Event Consumer must be associated with the Event Filter.

In the image that follows, the ActiveScriptEventConsumer appears in the root\subscription WMI namespace. Notice in the right pane, a green check mark appears next to the __EventFilter class with the instance name of “NewFile”. The green check mark appears under the column that states that it is registered. This image illustrates the Event Consumer to Event Filter binding.

Image of menu

To dig into the details of the ActiveScriptEventConsumer, right-click it in the WMI Event Registration pane. Check out the following:

  • The Script File Name. It should point to a VBScript file that is accessible to the event consumer.
  • If you are not using a script file, you can instead type the text of the script command in the Script text box. This is a great way to make a permanent event consumer portable (so that it does not rely on an external file).
  • The name of the ActiveScriptEventConsumer and the path and the relative path.

These properties are shown in the image that follows.

Image of menu

To review the Event Filter, use the Select arrow to choose Filters. Expand the __EventFilter node and ensure that the EventConsumerClass associates with the __EventFilter. To do this, look for the green check mark under the Reg column. In addition, make sure that the Instance name matches the name of the ActiveScriptEventConsumer detailed earlier. This result is shown here.

Image of menu

To check the properties of the __EventFilter, right-click __EventFilter in the left column, and then click Edit Instance Properties from the Action menu. From here, you will want to check the following items:

  • The event namespace
  • The name of the Event Filter
  • The query being utilized
  • The namespace of the event filter, in addition to the Path and the RelPath properties

These properties are shown in the image that follows.

Image of menu

When all three items related to permanent WMI events are checked, it is time to proceed to testing. This will be the subject of tomorrow’s blog.

That is all there is to using the WMI Administrative Tools to monitor for new WMI events. I invite you to join me tomorrow when I wrap up this five part series and discuss creating a permanent WMI event via a Windows PowerShell script that will monitor for new files created in a folder. If the file name has spaces at the beginning, it will automatically rename the file. It will be an exciting conclusion to an exciting week. So stay tuned, same script time, same script station (yes, the Scripting Wife and I went to see Batman). Take care.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • <p>Excellent blog post - excellent tool.</p>

  • <p>@JRV cool thank you. I am glad you enjoyed the posting. You are also right, the tool rocks.</p>

  • <p>Hi Ed,</p> <p>this toolkit is 10 years old!</p> <p>Why have I never had it before??</p> <p>Because I didn&#39;t knew it and I probably hat no use for it ... right!</p> <p>But this is still an excellent way to look inside the box ( WMI event box :-)</p> <p>Great!</p> <p>Klaus.</p>

  • <p>@K_Schulte yes the tools are old, but powerful and it is why they are still around. There have been many movements to write something to replace these things, but nothing so far. BUT if you think about it, in one way these things ARE replaced by Windows PowerShell. PowerShell does WMI EXTREMELY well and has made the class discovery tool nearly obsolete.</p>

  • <p>@K_Shulte,@ed</p> <p>Yes they have been around but not really replaced except for the code generator which generates class wrappers for VB and C#. &nbsp;I will post a link if I can find it.</p> <p>PowerShell does this thing because the Management class does exactly that. It generates a wrapper for any class it can see. &nbsp;This is rule based code generation but this time it is built into the Net Framework.</p> <p>CIM or OMI is the next step in this evolution. &nbsp;I have been waiting for it for some time now. &nbsp;OMI will now wrap the CIM spec in a set of implementation rules along with an access strategy.</p> <p>Anyone has followed the development of XML over the years will understand how powerful standards movements can be.</p> <p>What Admins are now seeing is the edge of a philosophical and experiential world that has been developing for decades.</p> <p>We need to take the conversation for Admins to a new level. The developer community has been at that level of awareness for a number of years now. &nbsp;Admins can also gain from learning a new language. PowerShell is the gateway. &nbsp;The future, in my opinion, is unlimited.</p> <p>Hubba! Hubba! Hubba!</p>

  • <p>Good stuff.</p>

  • <p>I have a question guys. I tried to use the tool access my server remotely, with supplying www.myserveraddress.com in the machine name field. Is this the right thing to do for using it ? </p>