PowerShell Problem Solver: Getting Process Details
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
- PowerShell Problem Solver: Processor Loads
- PowerShell Problem Solver: Process CPU Utilization
- PowerShell Problem Solver: Process Performance For All
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.
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. 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.
This can come in handy if you want to find non-Microsoft related processes.
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.
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.
And if I have a start time, it doesn't take that much more work to calculate the running time.
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.
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. 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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.