Summer is over, so is my vacation. I came back to office with PowerShell in Action fresh in my mind (just finished reading 1st edition) and wanted to use some of tricks I’ve learned from it. So there I was, wanting to check processes on remote machine (home-based user connected via VPN). I knew there was a property that matches executable, so I’ve just checked win32_process class and found ProcessName property that looked promising. So, let’s make it more elegant and use wmisearcher for that…:
-
([wmisearcher]"select processName from win32_process where ProcessName=’EXCEL.EXE’").Get()
-
An error occurred while enumerating through a collection: Invalid query (…)
Looks like this property is not there, even though Get-WmiObject will provide it for me. Had no time to fight with that so I eventually used Where-Object and my query was fine this time. When the problem was solved I decided to check what the heck went wrong. And so I started with Get-Member to check if that ProcessName is there or not:
-
TypeName: System.Management.ManagementObject#rootcimv2Win32_Process
-
-
Name MemberType Definition
-
—- ———- ———-
-
Handles AliasProperty Handles = Handlecount
-
ProcessName AliasProperty ProcessName = Name
-
VM AliasProperty VM = VirtualSize
-
And so it was but – wait a minute… It’s not a Property it’s an AliasProperty. Thanks to book I knew why it matters. It’s not possible to query WMI for AliasProperties – those are added to object by PowerShell and do not exist in WMI! But since definition is also there it was quite simple to re-write my query in a way that WQL would return results rather than errors:
-
([wmisearcher]"select Name from win32_process where Name=’EXCEL.EXE’").Get()
-
-
__GENUS : 2
-
(…)
-
Name : EXCEL.EXE
Bingo! 🙂 So, be careful when you want to narrow WMI results using WQL (either –filter, or –query, or [wmisearcher]) – use properties only for that. AliasProperties will not work at all, giving you errors about invalid queries.
