Tag Archives: Get-WMIObject

Find the Account that Starts a Service

There was an email I wrote to a team member last week. The point behind it was to help the team member determine what service(s) might be running under a certain account. The Get-Service cmdlet has never provided this functionality, so I mentioned that they use the Win32_Service WMI class (with Windows PowerShell, of course).

This suggestion led to me write and send them a list of command examples to include local vs. remote computers, pulling computer’s from a text file and Csv file, and using Active Directory. It seemed like a fairly solid list, and so I thought it should be posted here. I won’t bother including any output, because it’s fairly easy to figure out what’s going to be returned — the name of the service, the account used to start/run the service, and the remote computer name, in some of the commands that run against remote computers.

This first example is how to run the command against the local computer. This will return all the services on the local computer to include the account that is used to start the listed service.

PS> Get-WmiObject -Class Win32_Service | Select-Object Name,StartName

This example shows how to run the same command above, against a single remote computer. The only difference is the addition of the -ComputerName parameter and the Server01 parameter value.

PS> Get-WmiObject -ComputerName Server01 -Class Win32_Service | Select-Object Name,StartName

In this example, we run the same command above, except we do run it against two computers. In order to know which computer returned which result, we include the PSComputerName property.

PS> Get-WmiObject -ComputerName Server01,Server02 -Class Win32_Service | Select-Object PSComputerName,Name,StartName

Here’s one way to use a text file. The Get-Content cmdlet executes first, because it’s in parenthesis. The results of this command are then provided to the -ComputerName parameter.

PS> Get-WmiObject -ComputerName (Get-Content -Path C:\computers.txt) -Class Win32_Service | Select-Object PSComputerName,Name,StartName

This example does the same thing as the command above; however, it does so by piping the results of the Get-Content cmdlet to the ForEach-Object cmdlet. Within each iteration of the foreach loop, it runs the Get-WmiObject command. In testing, there wasn’t much different in the time it took to complete this example when compared to the last one.

PS> Get-Content -Path C:\computers.txt | ForEach-Object {Get-WmiObject -ComputerName $_ -Class Win32_Service | Select-Object PSComputerName,Name,StartName}

This next example utilizes a Csv File. In a Csv file, we have (column) headers; therefore, we need to indicate to PowerShell the column we’d like to use. Let’s assume we have a Csv with three columns of data with the headers Location, NameOfComputer, and Year. We’ll need to make sure we’re instructing our command to only use the data in the NameOfComputer column.

PS> Get-WmiObject -ComputerName ((Import-Csv -Path C:\computers.csv).NameOfComputer) -Class Win32_Service | Select-Object PSComputerName,Name,StartName

Here’s the same example as above, but this one uses a pipeline and ForEach-Object cmdlet, much like we did with the text file. While there’s little difference in the time it takes to complete, I would recommend that we don’t use a pipe when it’s not necessary, or when it’s doesn’t give us an advantage.

PS> Import-Csv -Path C:\computers.csv | ForEach-Object {Get-WmiObject -ComputerName $_.NameOfComputer -Class Win32_Service | Select-Object PSComputerName,Name,StartName}

Let’s incorporate Active Directory (AD), since it’s another place where we can get computers. This first AD example returns all the computers from a specific Organization Unit (OU) and runs them through the Get-WmiObject cmdlet. As in previous examples, this command will return all the values before it provides them as the value to the -ComputerName parameter.

PS> Get-WmiObject -ComputerName ((Get-ADComputer -Filter * -SearchBase 'OU=Engineering,OU=Workstations,DC=mydomain,DC=com').Name) -Class Win32_Service | Select-Object PSComputerName,Name,StartName

In my coworker’s situation, one of the computers in the OU was down, so we needed a way to filter around that problem. Here’s two ways to do that; however, the second option is the better of the two. If you’ve never heard it before, hear it now: filter as close to the left of your commands as possible.

PS> Get-WmiObject -ComputerName ((Get-ADComputer -Filter * -SearchBase 'OU=Engineering,OU=Workstations,DC=mydomain,DC=com' | Where-Object {$_.Name -ne 'Server22'}).Name) -Class Win32_Service | Select-Object PSComputerName,Name,StartName

PS> Get-WmiObject -ComputerName ((Get-ADComputer -Filter {Name -ne 'Server22'} -SearchBase 'OU=Engineering,OU=Workstations,DC=mydomain,DC=com').Name) -Class Win32_Service | Select-Object PSComputerName,Name,StartName


Add CMD’s ver to PowerShell

One of the great things about Windows PowerShell is that it can run Windows native command line tools, such as ping, ipconfig, and others. There are times, however, when there are exceptions. While recently working in the console, I brainlessly entered ‘ver’ (without the quotes), and it didn’t return what I expected. Instead of printing ‘Microsoft Windows [Version 6.3.9600]’ to the console, it reported that ver wasn’t recognized.

PS C:\> ver
ver : The term 'ver' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ ver
+ ~~~
    + CategoryInfo          : ObjectNotFound: (ver:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

While I wouldn’t recommend opening CMD to run the command, because seriously get out of that habit already, you can switch to CMD from inside the PowerShell console, as demonstrated below.

PS C:\> cmd
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.


Microsoft Windows [Version 6.3.9600]

PS C:\>

Still, this wasn’t quite as native as I wanted. For whatever reason, I wanted to type ver, and get the identical output I was used to seeing,… regardless of the fact that the ver output doesn’t really tell me much.

The first thing I did was launch the ISE and create an alias for ver. Keep in mind, that you may need to add -ErrorAction SilentlyContinue to the New-Alias cmdlet, if you run the script more than once inside the ISE. The problem here is that you’ll receive an error if you try and create an alias that is already being used. Either that, or you can add the -Force parameter and make New-Alias act like Set-Alias (and overwrite the alias even though it’s not really changing it).

New-Alias -Name ver -Value Get-TMVersion

Next, I constructed a function called Get-TMVersion that the alias ver would use. Inside the function, I created a single variable, $OS, and assigned it the results of a Get-CimInstance command. If for some reason you’re still using PowerShell 2.0, this can be replaced by the Get-WmiObject equivalent: Get-WmiObject -Class Win32_OperatingSystem.

Function Get-TMVersion {
    $OS = Get-CimInstance -ClassName Win32_OperatingSystem

Once I have this data stored in a variable, I can begin checking for a value in the variable, and then, building out my results to match the native Windows command. The If statement checks to see if the Name property of $OS begins with the string Microsoft Windows. Providing it does, it sets a second variable, $Version, as seen in the example below. Once that’s complete, it then echos a blank line, the $Version variable, and then echos a second blank line. At this point, $Version should be identical to the ver command’s standard output.

Function Get-TMVersion {
    $OS = Get-CimInstance -ClassName Win32_OperatingSystem
    If ($OS.Name -like 'Microsoft Windows*') {
        $Version = "Microsoft Windows [Version $($OS.Version)]"
    Write-Output -Verbose `r`n$Version`r`n

Here’s the function in action.

PS C:\> ver

Microsoft Windows [Version 6.3.9600]

PS C:\>

Boring, but it works. I should note that this function would probably be best served to include some error checking, in case setting the $OS variable errors out. In addition, I suspect there are probably other ways to produce the same resul–… (pause, keyboard keys clicking) …ugh, here’s a couple variations of yet another, simpler way.

PS C:\> cmd /c ver

Microsoft Windows [Version 6.3.9600]
PS C:\> cmd /c ver;echo ''

Microsoft Windows [Version 6.3.9600]

PS C:\>

It seems I could have just dropped a tiny bit of text into my function and called it a day. If you’ve ever read anything else I’ve written and posted, then you may have noticed a pattern. I seem to do things the hard way, long before I figure out a simpler way. I like it that way, though. If anything, it keeps me thinking, and therefore, improving my PowerShell skills overall.

Function Get-TMVersion {
    cmd /c ver
    Write-Output -Verbose ''