Check for running .exe, give the User the option to postpone
It would be nice to have an integrated solution for that. I would like to have the option to add the programs ".exe" names to the application in sccm. during deployment, if the .exe is currently running, it should ask the user to close it or give the options:
- postpone deployment
- close the application and start update immediatly
if the .exe is not running, it should just go ahead and install it without asking.
and also a silent version of this: check if the .exe is currently running, if no -> go ahead and install. if it's running -> try again another time.
and yes there are some powershell solutions available for that, but it would be nice and easier to have an integrated solution
There are many comments on this feedback item. We’ve read over them many times while building this feature and feel that we’ve hit the core functionality for this request in the 1702 release and so today we are marking this feedback item as complete.
We look forward to all of your passionate commentary, and votes, on the parts of this feedback that aren’t included in the current release to help us decide where to focus our efforts next.
As always, thank you for your passionate support and feedback.
Sascha Stumpler commented
Works great but please display the application name instead of (or additional to) the name of the executable. Because not every user is able to identify the application by the name of the executable.
Take IE for example: https://i.imgur.com/VgZ44I5.png
Glenn Turner commented
Perhaps Microsoft could work with Oracle and fix their Java installer so that it just works, even when iexplore.exe is running. I'd chip in to help pay for that.
Ok thanks for that feature.
Let's improve it a little bit:
1. Possbility to give a more "Clear" Name for the User instead of the somewhat.exe
2. Change the State from Failed to something else like "Close Apps" in Software Center
3. Don't show a cryptic return Code if i click on Failed in Software Center, instead show again the app i should Close
4, Give the Admin the Option to close the app and give a Countdown/Message to User
Glenn Turner commented
Perhaps also prohibit new launches of that process until the install is finished.
You can just have a global condition that java.exe is not a running process.
Greg DeGuire commented
As others have said, everyone should be using or investigating the Powershell AppDeploy Toolkit but, also as others have stated, this stuff ought to be in the native product.
Travis Adams commented
to expand on Roger's idea, also have the option to add a timer "this install will occur in 15 min please close app x" would be nice and have it count down.
Stefan Baresch commented
Some installations only runs if another application (most Browsers or the Application itself) are closed.
Ist would be great if we had the possibility at the Deployment Type which process(es) must closed to perform the installation/update.
It would also great is we had the possibility to inform the user to close it safely.
technically speaking you could check for a process running with a customer global condition. the fall out from that would be a failed deployment but if its required it will retry again eventually. its not a perfect workaround but it is a workaround. you could also use the PowerShell application deployment toolkit.
José Vasconcelos commented
This just a another thought about this: when deploying applications or packages, there could be field with the name of the process (or processes) that we should consider. SCCM will not do this job for us... we should provide as much information as possible to each deployment, to avoid errors and issues, to have a higher success rate in our deployments. In very large organizations I can image that this is a problem but if somehow SCCM allow us to control the behavior (kill, force to kill, etc) that each process will run for each deployment, this would be a great new feature.
Mitch beck commented
This is why AppDeployToolkit is awesome. We are starting to use it with more of our Application Catalog packages.
The use of PowerShell App Deployment Toolkit is very cool. Some Features as interaction with the user and postpone an Installation could be native.
Kenneth Merenda commented
I can't agree enough. We use PSAppDeployToolklit for everything, but it would be so much better to have that functionality built into SCCM.
Please Mircrosoft, every enterprise customer I'm working with want all of the features that are in the Powershell App Deployment Toolkit!
Things like end user notification if and what apps is running, close all apps needed, ability to defer installation, block application while deployment is running. It is all Powershell, it cannot be that hard to incorporate this into SCCM!
Mr. Sina commented
Most customers don't care if the program that they are working with has an update. They just want to use it to do their job. EXE-check is nice to have but it should be as silent as possible and among other things needs a directive for disconnected users opened exe's.
OMG! You could release the next version of SCCM with just this feature and I would be happy. By far this is the number one feature we need ASAP.
Nathan McNulty commented
I agree with Matt Schultz. This feature should allow checking any conditions that must be met prior to executing the install command. Using scripts and Global Conditions are great. Having some pre-built examples like checking for IE would help those less familiar with WMI or PowerShell.
We currently use PowerShell Application Deployment Toolkit as well, but native tools would be preferable for my staff that don't know enough PowerShell to effectively use it.
John Williams commented
I really like this idea. I think it could also be extremely useful when deploying security patches. With many lab type of systems running automated jobs, it would be great for patching to occur, but the reboot wait until a specified process (or processes hopefully) would stop. Once stopped, invoke the reboot.
Microsoft to buy App Deployment Toolkit and integrate it in SCCM :)
Matt Schultz commented
I would extend this so that the criteria for postponing could be any criteria that can be used for application detection (run a script, use global condition, etc.). That way I can not only check for a running EXE, but maybe a combination of EXEs, detect if the user is on a particular subnet (don't run if on VPN, for example).