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.

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.

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.

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.

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.

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.

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