Relevance for Win32_NTLogEvent

I’m trying to figure out when a system comes out of sleep/hibernate. The best way I’ve found so far is querying the system logs. I’ve found a wmi query that I can run in a vbs that give me todays (or at least close)

strComputer = "." 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
"SELECT * FROM Win32_NTLogEvent WHERE SourceName = 'Microsoft-Windows-Kernel-General'  and TimeWritten >= '20151111' ",,48) 
TimeCreated[timediff(@SystemTime) <= 604800000",,48) 
For Each objItem in colItems 
    '~ Wscript.Echo "-----------------------------------"
    Wscript.Echo "     Time: " & objItem.TimeGenerated
    '~ Wscript.Echo "Message: " & objItem.Message
Next

Ultimately, I want to return TRUE if device has come out of sleep/hibernate within the past 30 minutes. Any ideas how I can put this in relevance? I get bad requlsts when I try:

q: string values of selects "SELECT * FROM Win32_NTLogEvent WHERE SourceName = 'Microsoft-Windows-Kernel-General' " of wmi
E: The expression could not be evaluated: Windows Error 0x80041017: Invalid query

I am not responding to the validity of the logic to accomplish what you need - rather just providing the Relevance code.

BigFix has inspectors to query the Windows Event Log directly.
https://developer.bigfix.com/relevance/search/?query=event%20logs

Querying the Event Logs can be expensive and slow, so be careful.

An example would be:

exists times written whose (now - it < 30*minute) of records whose (source of it = "Microsoft-Windows-Kernel-General") of system event log
1 Like

Oh, your statement using WMI directly has an extra “select” in the clause.

A working example would be:

number of selects "TimeWritten FROM Win32_NTLogEvent WHERE SourceName = 'Microsoft-Windows-Kernel-General' " of wmi

However, going through WMI is slower. Also the return values are strings and we will have to convert to Time before being able to use it, so there is also added complexity there.

1 Like

5 seconds… that is costly. I’ll have to mow on that one for a while. We just have an issue coming up with mainly our laptop users. We are using AD site in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine) as our relay selection method, but that doesn’t kick in unless gpupdate kicks in. They could be talking to a failover or even another sites relay for quite a while before things settle down after the PC comes out of sleep between sites. It’s just been my experience the update may not happen for hours. I need to find a good way to detect when they hop sites.

Perhaps I just need to detect IP address changes.

A better option might be to detect when the last gpupdate was run, and if over a certain time, kick that off with the BES Client.

Any relevance that looks at the event logs, either WMI or the event log inspectors, can be extremely slow. You have to be careful with it.

In my environment, we use the “Location Property Wizard” to map IP addresses to a custom client setting / property we named “Facility”; and we have several different Policy Actions (such as assigning Relay Seek Lists, manual/auto relay selection, etc.) targetted based on the client’s Facility value.

If that wouldn’t work for you, and you just want to see when the system came out of idle, you might be able to use the “power interval” inspectors described at https://support.bigfix.com/inspectors/Power%20Objects_Any.html#power state

1 Like

That looks like that could work Jason, but it looks like the power state and power history inspectors are all Win8 and up. We are currently only Win7. Unless I’m reading that wrong.

Agree with you too James. Those are slow. But I’m not sure my server team would appreciate my running gpupdate every so often… just because. I really want to keep this targeted.

That is really what I was suggesting, have gpupdate trigger automatically if it has been a while since it has been done, and based upon maybe the IP address changes, or some other criteria.

I wasn’t suggesting it should happen on all systems all the time.

How are you determining which relay the client should use? You might be able to do that directly with a Policy Action. For example if you’re basing it on IP addresses, you could say something like “onsite subnets” are 192.168.1.0 and 10.0.0.0 (replace with your real subnets). If a client is offsite, maybe you want it to use the relay with IP address “A.B.C.D”.

Relevance could be something like

not exists (("192.168.1.";"10."), addresses of adapters of network as string) whose (item 1 of it starts with item 0 of it) AND ip address of selected server as string != "A.B.C.D"

There are also bitwise comparisons you could use rather than “starts with” in case you want to use something like CIDR addresses (ie 192.168.1.128/25). I’m just trying to illustrate that you might base this off of “my IP address and relay combination do not match what I want them to be” rather than “I haven’t selected a relay since my IP address changed”.

1 Like

Just following up on this. I got my update trigger here. I’m still testing with my dev group, but all looks like it should work as expected.

@JasonWalker, relay affiliation will be based off of AD Site. We are assigning the same AD Site name in AD, then using that to trigger the affiliation. Still in the build process for all this. Hope to write something up some day.

2 Likes