Is wrapping Get-WMIObject a bad idea?
I made a function to wrap Get-WMIObject so that I can use it in a pipleine and so that it is adding an extra attribute
function Get-Services (){
[cmdletbinding()]
param(
[parameter(ValueFromPipelineByPropertyName,ValueFromPipeline)]
[string]$Name
)
$services = Get-WMiObject -Class Win32_Service -ComputerName:$Name
$services | Add-Member IsSystemAccount (($_.StartName -ne "LocalSystem") -and ($_.StartName -ne "Local System") -and ($_.StartName -notlike "NT AUTHORITY\*") -and ($_.StartName -notlike "NT Service\*")) -PassThru
}
I then use this:
Get-ADComputer -SearchBase "OU=Server Farm,DC=test,DC=org" -Filter * | Get-Services | Where {-not $_.IsSystemAccount}
Before I had a giant function that performed the search, and the WMI request and the filter. But as I added options that are simple in the pipeline, the function became huge. I had flags for if services started by system accounts should be excluded, how to search for machine. It became a mess. So I did the above, and now I'm worried there is some reason that Get-WmiObject doesn't work in a pipeline by default.
Am I just being paranoid?
Posted Apr 5, 2017, 7:20 PM UTC
33
if you are going to use the pipeline, you must use the
Process{}block in the function. You also need to run yourAdd-memberon every service returned so that needs to run through aforeach-object.Another change was to make
$Namea[string[]]and to wrap the entire process in aforeach. That is so it will support both a pipeline and something like this:Yea after posting i realized I'd only tried it with a single computer name. Thanks! So with the process command and the name as n array it works great. I managed to invert my system account check somewhere so I changed that.
Your's looks prettier...but I got mine to work too :)