Get-Process does not return all properties from remote PC

Tagged: 

This topic contains 8 replies, has 2 voices, and was last updated by Profile photo of Jeffrey Wagar Jeffrey Wagar 2 years ago.

  • Author
    Posts
  • #25309
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    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.

  • #25310
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #25311
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    Thanks for your prompt reply!

    Here is the first screenshot requested

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

  • #25313
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    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

  • #25316
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    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

  • #25319
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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?

  • #25324
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    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.

  • #25328
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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!)

  • #25392
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar
    Participant

    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.

You must be logged in to reply to this topic.