For today’s PowerShell Problem Solver, we’ll look at how to track process details that you don’t see by default from PowerShell. Although you could use great graphical tools, such as procexp.exe from Sysinternals, I’m going to assume you want to use PowerShell because you can use it to manage at scale. We’ll use the standard Get-Process cmdlet to start. I’m going to test my expressions locally first, which is always recommended. I can always re-rerun Get-Process and use the –Computername.
PowerShell Problem Solver: Getting Process Details
Running Get-Process (Image Credit: Jeff Hicks)
If you are just getting started with PowerShell, it is very important for you to realize that what you see as the result is not necessarily all there is to the output. Remember, cmdlets write objects to the pipeline and PowerShell has default settings designed to simplify things for the IT pro.
In this case, PowerShell has a default view for process objects. But there is more than meets the eye, not only in terms of properties, but also their names. Don’t assume that the headings you see in a result are the actual property names. They may not be. The only way to know is to pipe something to Get-Member.
Getting member properties (Image Credit: Jeff Hicks)
I am not interested in the process object's methods or events, so I limit the results for Get-Member. Any command that you want to run that needs a property name, you can use anything from this list.
Now, sometimes it is difficult to completely understand what all these properties mean, so I often get a single instance of an object and pipe it to Select-Object.
Viewing properties of a single object (Image Credit: Jeff Hicks)
This kind of information can help narrow down exactly what I want to see, as well as how I might build a more complicated PowerShell expression.
For example, there is a Company property.
Getting company information for processes (Image Credit: Jeff Hicks)
This can come in handy if you want to find non-Microsoft related processes.
Getting non-Microsoft processes (Image Credit: Jeff Hicks)
Some of the processes with no company name are in fact from the operating system. But I can take this a step further and get the associated command with each process using the Path property.
A process report using Out-Gridview (Image Credit: Jeff Hicks)
In this example, I filtered out non-Microsoft processes and kept only those processes with a defined path property. Let's take this a step further and use another hidden property, when the process started.
Process report with starting time (Image Credit: Jeff Hicks)
And if I have a start time, it doesn't take that much more work to calculate the running time.
Process report with runtime (Image Credit: Jeff Hicks)
Because I've defined a new property, I can use that in my expression. Here's how I can list the 10 oldest processes, assuming the company is not Microsoft.
Getting longest running processes (Image Credit: Jeff Hicks)
Finally, let's take this and scale it out so I can see what has been running the longest on some of my servers.
Now, you might think all you need to do is run Get-Process with the –Computername parameter. Depending on what properties you are selecting this might work just fine. But for the properties I'm searching for, this command:
runs without error but also doesn't display any results. I don't have much running in the way of third-party products, so I'm revised my filter. It turns out that some properties, like Company and Path only work locally. That's not a problem because I can use PowerShell remoting.
As you can see, my servers don't have anything unexpected.
Getting long running processes on remote servers (Image Credit: Jeff Hicks)
Another benefit to using remoting is that this performs very well.
Now that I know what kind of information I can get with Get-Process, I can easily build whatever querying or reporting I need.
