Hi @ajamaya,

To get the name of a process running on a device, the application would first need to be installed on your target device. You then can run the Get-Process | Select ProcessName on the device and it will return all running process names.

Another alternative would be to use a like filter and wild cards to conditionally return a process name.  In this example, I’ll receive a return for any processes named like “paint”:
 Get-Process | Where-Object { $_.Name -like “*paint*” }

Regarding your last point about patching applications that must be shut down in order to update, you have a few options.

Once you have your target application name(s),  Kill Open Process Catalog Worklet will allow you to input a process name within the $ProcessName variable to force close it.  You could set this worklet up to run 15 minutes or so before your primary patch policy schedule to ensure the application is closed and ready to update.

Another option would be to configure your third party patch policies depending on the applications patch behavior listed here: https://help.automox.com/hc/en-us/articles/5352033229076-Third-Party-Patching-Best-Practices

With this method, you’d scope separate policies based on the application’s patching behavior and prompt the user to close their apps using native Automox notifications. This community post goes into more detail about this method:

Our Automox University also has some great courses you can review on how to set policies like this up:
https://university.automox.com/third-party-patch-policies

A final option would be to set up a worklet that prompts the end-user that updates are required, and then closes their apps before running the update using sourced installation media.  This Catalog Worklet is a good example of this method: Windows - Software Lifecycle - Update TeamViewer with Notifications

I hope this helps! Have a great day!

Thanks! I was hoping to get the process names of every app that automox supported otherwise I would have to download all of them to get the process name. I have been combing through our supported internal software list and compiling as much as I can. 

Got it!  I’m not aware of a cheat sheet such as this, but I’m checking with the team to see if this is something we currently store. 

Where there any titles in particular that you were looking to scope?

Good morning @ajamaya !

Attached is a list of the process names for third party apps that must be shut down in order to patch.

Have a great day!

I’d try to scope this to smaller bites vs shooting for perfection in one go. More on IT Agility that speaks to that here: https://listen.automox.com/episodes/heroes-of-it-episode-01 (great first episode)

For example you could use the Automox Activity Log to filter on “unable to patch because it is currently running” for last 30 days. After doing that, export to a CSV file, then used the Excel Text to Columns feature using “:” (colen) as the delimiter. Then grab content from columns B and C. Paste all those into a single column, then de-duplicate it. Cleanup some of the left over parts you don’t want. Which should be a much smaller list of apps that did not patch for that reason.
 

You could then use a formula like this where H2 is the cell with the “detail” data containing that exact context. The wildcards are just helping count anywhere it sees that exact text in the “detail” data:

=COUNTIF(F:F,"*"&H2&"*")

Doing it this way will give you a quantified data point to start focusing yourself on the most impactful apps first. Then just go pull the process list from one system, build process around it to close the app or provide a different patching strategy (some of which may require forcing apps closed). Repeat that process. Doing it this way, and hypothetically spending 1 day on each one, lets me tackle this in 11 days. 

Here is what mine looked like:

My strategy is to target normal patching for a period of time, then after a threshold is hit, force closing apps on individuals. 

Personally I  love using the API to pull pre-patch reports that include the patch age in # of days. Learn about that one here: https://developer.automox.com/openapi/axconsole/operation/getPrePatchReport/ Using that data I’m able to run patching cycles and drive “how much should I care” reports based on # of days past an expected threshold. This has been a game changer in how I’m channeling what to work on to produce meaningful impact on my patching effectiveness. Asking myself questions like is it an overall problem with a particular system, group of systems, or patch.