There are several ways we can create a file monitoring script using PowerShell. There is also a cmdlet in PowerShellPack called Start-FileSystemWatcher to monitor file /folder changes. However, none of these methods survive a exit at the console or wherever the script is running. This is because all these methods create a temporary event consumer. As I’d mentioned in an earlier post, Trevor’s PowerEvents module makes it very easy to create permanent event consumers in PowerShell. In today’s post, we shall look at how we can do that.

A few weeks ago, I wrote about WMI Timer events using Win32_LocalTime and then mentioned how to work around the DayOfWeek issue. In today’s post, I will show you how to use WMI timer events to create complex scheduled tasks.

As system administrators, you may have to create scheduled jobs for performing various sysadmin tasks. We generally use Task Scheduler for such jobs. However, using the regular OS task scheduler, there is no easy way to create a scheduled task that occurs — for example — every Thursday of every fourth week of a month in the third quarter of every year.

The WMI query syntax for event queries is a bit different and deserves a discussion. So, before we delve in to the types of event queries, let us first look at the syntax for WQL event queries. As we discussed earlier, we use SELECT statement for event queries too. We can combine this with other keywords such as WITHIN, HAVING, and GROUP to change how we receive these WMI events.

Here is how a MSDN article shows the syntax for WMI event queries.

In my earlier post, I showed how Win32_LocalTime WMI class can be used to capture timer events. As mentioned there, WMI events can be quite helpful in creating complex scheduling tasks. For example, you can specify to run a script every Thursday of every fourth week of a month in the third quarter of every year. However, there is a bug in Win32_LocalTime that currently blocks this.

I created a support incident with MS and reported this bug to them. I got a response that this indeed is a bug and they provided a workaround to solve this temporarily.

This is not a part of the WQL series I am doing. I happend to take a look at the WMI timer events while providing feedback to an upcoming (cool) PowerEvents module by Trevor (@pcgeek86). BTW, this module will be released on November 30th. So, watch out for the annoncement.

Coming to the subject of this post, in WMI, there are 3 types of events possible. They are Timer events, Intrinsic events, and extrinsic events. My WQL series will soon cover intrinsic and extrensic events. Very few people have written about WMI timer events in the past but this particular post on The SysAdmins blog discusses good amount of details.

In this post, I will write a bit about basics of WMI events and how Register-WMIEvent cmdlet can be used. To start with, here is an excerpt from Microsoft Scripting guide that introduces WMI events:

Just as there is a WMI class that represents each type of system resource that can be managed using WMI, there is a WMI class that represents each type of WMI event. When an event that can be monitored by WMI occurs, an instance of the corresponding WMI event class is created. A WMI event occurs when that instance is created.

If you look at the above diagram (captured from the associations tab of Win32_Process in CIM Studio) and as I showed you in my earlier post, Win32_SessionProcess, in32_NamedJobObjectProcesses, Win32_SystemProcesses are the associator or association classes. Whereas, Win32_Process, Win32_LogonSession, Win32_NamedObject, and Win32_ComputerSystem are the associated classes.