Powershell recursive WMI query

powershellscriptingwmi

I'd like to start at the top of a WMI namespace, recurse through all the objects, then recurse through each object's property list, filtering out and returning to console only those properties that have mem in their names.

This is what I have so far:

gwmi -namespace "root\cimv2" -list |???? |get-Member -MemberType property | Where-Object { $_.name -match 'mem'}

Notice the big |???? in the middle there. If I remove that, the the command seems to run, but fails to find properties I know should be found. Why? I think it is because I get different output from the following two commands:

gwmi "Win32_operatingSystem"  |get-Member -MemberType property (73 lines of output)
gwmi -namespace "root\cimv2" -list  |where-object { $_.Name -eq 'Win32_OperatingSystem' } |get-Member -MemberType property (10 lines of output)

What I want is a one-liner that recursively concatenates this process:

gwmi -namespace "root\cimv2" -list
(manual selection of a WMI class from the list of 1000+ which appear) 
gwmi "win32_OperatingSystem" | get-Member -MemberType property | Where-Object { $_.Definition -match 'mem' }

Thanks, and if a working answer is given, I will accept and upvote it (annoying when people never do that, isn't it?).

Note added 2009/11/14: I haven't awarded the answer yet because no one has yet provided a one-liner which solves the problem.

Best Answer

I think this will do what you are looking for in one line. the CIMV2 namespace is there by default but if you wanted to select a different one, you can use gwmi -namesapce.

The "trick" is nesting a where-object in side the foreach-object

gwmi -list | % {$_.Properties | ? {$_.Name.Contains('Memory')}} | select Origin,Name

Related Solutions

WMI Rights required to read root\MicrosoftIISv2 in IIS7 with IIS6 compatibility mode

Resolved.

The WMI and IIS Metabase rights have to be set as you would do on an IIS 6. So they were correct for me.

The specifity is on the IIS Metabase. First of all, in IIS 7 the W3SVC rights are completely inherited from the root while you have to set the W3SVC/AppPools rights on IIS 6 if you want to handle the application pools.

Since there's a 'compatiblity', the main difference resides in IIS 7 metabase file system. On IIS 6, the read rights on the inetsrv folder (which is the default for Users) and the Metabase ACLs are sufficient.

On IIS 7, the rights have to be set on the IIS Metabase AND the IIS 7 configuration folder : %SYSTEMROOT%/system32/inetsrv/config (and .config files then). By default, only Administrators (thats why it is perfectly working with the Administrator right) and some other reserved groups can access this folder.

Another point, if you need to execute methods like a Stop on an application pool, this feature require the Write rights on the configuration folder.

Powershell – Kill process, then uninstall application–Can I do this with PowerShell, over 400 computers, from a txt file

While this is technically possible, there's probably a better way to go about it.

And speaking of better ways to go about it, You could do this in a GPO with a few lines of code as a startup or shutdown script, which is how I handle this. With a few more lines of code you could log the results of checking for the presence of this thing and/or uninstalling it, which would undoubtedly be useful in your compliance efforts.

If a GPO-linked startup/shutdown script's not an option for whatever reason, I think I'd use PSExec to kill the process on a list of computers read in from file and then script the uninstall in an appropriate language. Seem to me that this is a lot easier in VB, for example.

a=WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2318C2B1-4965-11d4-9B18-009027A5CD4F}\UninstallString")

If a<>"" Then

WshShell.Run(a&" /S"),1,True
i=i+1

end if

(Goodbye Google Toolbar, in that example which I wrote or copied a few years back. Copied, probably. I am rather lazy.)

Without debugging the PS script you copied, I'd point out that you might be running a different PS version, different PS modules installed/loaded and/or there might be some dependencies that your XP machines don't have in place that's causing problems.

Related Topic