Author Posts

May 16, 2015 at 2:22 pm

PS C:> Get-Process -ComputerName FS1 successfully returns the list of running processes from that remote computer [FS1], yet other than the six default properties (VM, WS, CPU, Handles, ID, ProcessName) the remaining properties of every process are blank. I am logged into my workstation with a Domain Administrator account and had opened my PowerShell console with "Run as Administrator".

If I walk over to FS1's keyboard, open the PowerShell console, then type Get-Process, nearly all the properties have values.

Repeating those two steps on another remote computer, the same pattern occurs — all properties populated only if Get-Process is typed in a local console.

Enable-PSRemoting on the remote file server [FS1] does not cause the non-default process property fields to be populated.

PS C:> Get-WmiObject Win32_Process successfully returns the list of running processes from that remote computer [FS1], and nearly all the properties have values. Alas, some of the Get-Process properties I desire are not available through Get-WmiObject.

In summary, Get-Process does not return an "access error", does return the complete list of running process, just no properties beyond the 6 default ones.

May 16, 2015 at 2:30 pm

Get-Process uses DCOM, so I wouldn't expect Remoting to have anything to do with it. And either WMI or CIM would probably be a better way of obtaining that information; DCOM is definitely a dicier protocol these days.

If you run:

Get-Process -ComputerName FS1 | Select *

Can you paste a sample of one process' properties as displayed? And also paste the result of:

Get-Process -ComputerName FS1 | Get-Member

Please.

May 16, 2015 at 3:56 pm

Thanks for your prompt reply!

Here is the first screenshot requested

PS C:> Get-Process -Computername FS1 | Select *

May 16, 2015 at 3:57 pm

Here is the second [pair of] screenshots — could quite fit the long list on a single screen shot.

PS C:> Get-Process -ComputerName FS1 | Get-Member

May 16, 2015 at 4:00 pm

Here are a pair of screenshots, one from executing the Get-Process cmdlet remotely, the other locally. Why does the local cmdlet return the Path property of most processes while issuing that cmdlet remotely returns not a single Path property?

PS C:> Get-Process | Select Path issued from the local keyboard of the computer named FS1

PS C:> Get-Process -ComputerName FS1 | Select Path issued remotely from my administrator workstation, logged in with a Domain Administrator account, in a "Run As Administrator" PowerShell console

May 16, 2015 at 4:49 pm

Yup, that's about what I expected. Welcome to the world of DCOM, where everything's inconsistent and undocumented. DCOM filtered through .NET, no less, which is even more fun. Try Get-Service that way, sometime – it actually relies on the Remote Registry Service running on the target, if you can believe it.

My suggestion would be to either:

A) Use Get-WmiObject

B) Use Get-CimInstance

C) Run Invoke-Command -computername FS1 -script { Get-Process }

The latter gets the command running locally and then serializes the results to send back to you – you'll get something more like what you're used to, albeit with no methods. For A) or B), what is it you're not able to get?

May 17, 2015 at 5:16 am

I am giving another talk on how PowerShell can be used for detecting [u]silent[/u] malware. To provide two examples, I intended to detect malware processes that label themselves in Windows Task Manager as a Shared Host process "Svchost" but whose Image path is not C:\Windows\System32\svchost.exe. Other malware leaves the Company & Description properties of their O/S process blank. So those three process properties are what I am trying to fetch using Get-Process. That cmdlet does so from a local console, but amazingly not through a remote call.

May 17, 2015 at 7:24 am

So... translation, you need to get the path of the executable, as well as the process name?

First, I can absolutely confirm that Get-Process also doesn't return everything remotely – at least on every system I have. So this isn't you. So now we need to find another way to get what you want.

But both Get-WmiObject and Get-CimInstance have the process name and path.

Get-WmiObject -computer DC -class Win32_Process -filter "name like '%svchost%'" |
Select-Object -prop Name,Path 

Works fine for me. Is that not what you're trying to do?

(and FWIW, nothing weird about DCOM is "amazing" to me anymore!)

May 19, 2015 at 6:14 am

Based on your help, Don, this issue can be marked as resolved. Here is a summary of what our testing learned.

1) Get-WmiObject Win32_Process and Get-CimInstance Win32_Process both pull the path of the executable that launched a specific O/S process.
2) Get-Process can pull the path of the executable, and also a helpful descriptive field (Company/Publisher) not available through Get-WmiObject or Get-CimInstance
3) Get-Process -Computer name uses the legacy DCOM protocol to poll a remote computer, but does not return all the process properties, unfortunately the Path property is always blank.
4) Invoke-Command -ComputerName $targetComputer -ScriptBlock { Get-Process } uses the WinRM protocol and does return all process properties.

Hope the explanation helps others choose correctly.