We have a WMI provider that fires an event for system changes we care about.  The PowerShell Register-WMIEvent with the "-class" option works just fine for setting up a temporary event subscriber. 

I've gone through the permanent event consumer examples ( http://blogs.technet.com/b/heyscriptingguy/archive/2010/12/07/use-powershell-to-monitor-and-respond-to-events-on-your-server.aspx), but they all use a  WQL Query in the EventFilter, which seems to just poll the class and then generate an event.  I would like to avoid the polling and resulting delay in delivery with permanent event registration.  I there a way to register for the class event directly with permanent events?

Thanks,  Jim

There's an ActiveScriptEventConsumer class that can run VBScript code in response to a WMI event, but it doesn't directly support PowerShell.  You could have your VBScript launch PowerShell.exe with enough arguments to provide all the information about the event, if that's your preference.  (However, PowerShell is a pretty heavy process, taking up around 100MB of RAM and quite a bit of time to initialize.  Depending on how often these events fire that may not be an acceptable solution, and you'd be better off just sticking with VBScript.)

See http://msdn.microsoft.com/en-us/library/aa393014(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/aa392395(v=vs.85).aspx for some more details on permanent WMI subscriptions.

• Edited by David Wyatt 11 hours 8 minutes ago

Well, however life on the event horizon is, it is not as bad as that and it is almost as lightweight as Einstein imagined.

The impact of the ActiveScript consumer is trivial.  If you do not create an event that fires continuously then the event is innocuous.  I have used thises vevents for almosttwo decades without issue when designed correctly.

The WQL event filter DOES NOT POLL.  It use SENS events to generate a response.  SENS has been part of Windows since at least W2K.  It is based in the kernel.  A great amount of Windows is based on SENS.

There's an ActiveScriptEventConsumer class that can run VBScript code in response to a WMI event, but it doesn't directly support PowerShell.  You could have your VBScript launch PowerShell.exe with enough arguments to provide all the information about the event, if that's your preference.  (However, PowerShell is a pretty heavy process, taking up around 100MB of RAM and quite a bit of time to initialize.  Depending on how often these events fire that may not be an acceptable solution, and you'd be better off just sticking with VBScript.)

See http://msdn.microsoft.com/en-us/library/aa393014(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/aa392395(v=vs.85).aspx for some more details on permanent WMI subscriptions.

• Edited by David Wyatt Tuesday, January 14, 2014 12:25 AM

Thanks for the quick replies.
The frequency of the events is very low, yet a bit bursty.  Typically 5-20 events at once, but only once a month or less. 
Good to know that the query doesn't result in a poll.  I am after a low latency on the delivery of the event (under 1 second is desired) with low overhead, such that on a loaded system there will not be resource issues that could cause the event processing to fail.

I set up a test case:  watch for when notepad.exe gets started with:

  $query = "Select * from __InstanceCreationEvent within 15 where targetinstance isa 'Win32_Process' and targetInstance.Name = 'notepad.exe' "

I used a few of Ed Wilson's blogs to have a permanent event start a VB script that starts a PowerShell script that logs to a file when it starts.  I created another PowerShell script that starts and stops ten instances of notepad.exe once every 50 seconds and logs the start time to the same file. 

Using "within 15" the average delay between starting notepad and starting the script is 8.3 seconds.  When I shorted the within from 15 to 1, the average delay is shortened to 1.5 seconds. This is why I thought a poll was being used: there seems to be a random distribution time of N+0.5 seconds, with a range of 1 to N.

Online blogs recommend that for a production system a WITHIN value of not less than 30 be used due to overhead.  If the WITHIN value is actually only an aggregation time, not a poll interval, then using a small value (0.5) for infrequent events should be okay.. correct? 

Yes - I think you are very close.  The resolution of the event is within the interval plus response time.  1.5 is likely right.  The delay just says wait a while for another even and deliver them as a batch.  You can  also control the batching.  See WQL for events.

There is more overhead to starting and stopping PowerShell.  I would do it all as a MOF with an embedded script.  This would be faster and more secure.  It would also be easier to manage. 

See WMI MOF event subscriber.

Here is an example of a MOF with embedded script.

http://sdrv.ms/1hotob9

I have a few but this is the most basic.  Compile on system and it is running permanently until you delete the providers and consumer objects.