Quick Tests of WQL Queries

Recently I was working on a clean-up/improvement project in the MEMCM (SCCM) console which required some WQL query work and updates. In particular, I was fiddling with some collection queries to segment some areas for a process improvement project coming up. That's intentionally vague, because the 'why' in this case doesn't really matter. What does matter is that I needed WQL to give me proper results.

But First, A Failure

Based on the "good designers copy and great designers steal" mentality combined with the fact I don't often work in WQL, I stole the bits of a WMI query nestled in a task sequence as my base/inspiration, specifically for the model number matching part. Opening up the WQL query editor in the console, I made what I presumed to be adequate adjustments, slapped in the model pattern matching, and let 'er rip.

But it would not, actually, rip.

Zero results. WTF?

After a second edit/attempt with similar results, it was time to be more deliberate about the approach.

Enter: WQL Queries on the Fly (via Powershell)

I knew I could use Powershell to more nimbly test out queries, but when most of my mediocre attempts 'just work' it isn't necessary to do so. However, in this situation something very obviously wasn't working so rather than fight it I'd just do what I really should've done from the beginning: just use Powershell.

I took the base query that was failing directly from the console query editor, and using the syntax identified in this post (and full documentation from Microsoft), leveraged the power of the Invoke-CMWmiQuery cmdlet. As noted in the documentation, you must run this from the configuration manager site drive in Powershell, but if you have access to the console, you generally have access to the site drive.

At any rate, what I learned is that for some reason my pattern matching was "sort of" working, but not backfiring a bit when actually entered as a query. Normally I'd have dug a little deeper into the reasoning, but in running a couple of manual queries I quickly discovered (at scale) the various full model names I'd been intending to pattern match. So for me, the action of removing the pattern matching (i.e. LIKE operator) quickly solved the problem.

I could've just done a few regular WMI queries right off an affected workstation to get this information from the beginning, but having the scale and data of the site at my fingertips ensured that I was actually obtaining the data I needed. Removing the pattern match component should help improve performance as well, not that this particular issue is a huge performance issue in production.