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.
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:
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
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?
I am giving another talk on how PowerShell can be used for detecting silent 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.
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!)
Based on your help, Don, this issue can be marked as resolved. Here is a summary of what our testing learned.
Get-WmiObject Win32_Process and Get-CimInstance Win32_Process both pull the path of the executable that launched a specific O/S process.
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
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.
Invoke-Command -ComputerName $targetComputer -ScriptBlock { Get-Process } uses the WinRM protocol and does return all process properties.
Hope the explanation helps others choose correctly.