Running programs causing problems
Hi All.
I’m sure there must be an easier/better way to do this that someone else has already discovered. I’m using SCCM to install applications to user PCs that may or may not be an upgrade. Currently we have chosen to use /qb! so that the user is provided with some visual notification that an install process is occurring and will therefore be aware of when that process is finished and the program is available for use. This is particularly useful when a user calls up the help desk and requests an application to be installed.
Unfortunately, if the install is an upgrade and the user is running that program or the install otherwise requires a program to be closed before the install will proceed, the user is presented with a window requesting them to shut down that program. This window has the option to Retry, Ignore or Cancel. Rather than performing the task requested and shutting down the program they are using, our pesky users tend to click the cancel button, causing the install to fail in the eyes of SCCM. This tends to occur when the install is being pushed to a number of PCs, rather than being requested by the user.
The nicest solution to this would be the ability to disable the cancel button, but as this is a builtin Windows Installer prompt, my reading indicates that it is not possible to disable these buttons. Any suggestions on this would be greatly appreciated.
The next option is to run a notification before the install, telling the user what is about to happen, which includes killing any running applications that are going to be a problem for the install. This option is pretty much the sledge hammer approach, wouldn’t make us popular with the users and couldn’t guarantee that there wouldn’t be some other problematic program anyway.
The final option would be to have a separate collection, advertisement and program that was used for ‘pushes’ rather than request. This one would be silent and would be set to keep retrying at some schedule until it installs successfully. This seems like a lot of doubling up on deployment work and seems like it would provide an opportunity for the programs to become out of sync version wise.
Are others using one or more of these processes, or do you have an even better way of handling the situation?
Thanks for your advice and sorry for the long post.
Brett
I’m sure there must be an easier/better way to do this that someone else has already discovered. I’m using SCCM to install applications to user PCs that may or may not be an upgrade. Currently we have chosen to use /qb! so that the user is provided with some visual notification that an install process is occurring and will therefore be aware of when that process is finished and the program is available for use. This is particularly useful when a user calls up the help desk and requests an application to be installed.
Unfortunately, if the install is an upgrade and the user is running that program or the install otherwise requires a program to be closed before the install will proceed, the user is presented with a window requesting them to shut down that program. This window has the option to Retry, Ignore or Cancel. Rather than performing the task requested and shutting down the program they are using, our pesky users tend to click the cancel button, causing the install to fail in the eyes of SCCM. This tends to occur when the install is being pushed to a number of PCs, rather than being requested by the user.
The nicest solution to this would be the ability to disable the cancel button, but as this is a builtin Windows Installer prompt, my reading indicates that it is not possible to disable these buttons. Any suggestions on this would be greatly appreciated.
The next option is to run a notification before the install, telling the user what is about to happen, which includes killing any running applications that are going to be a problem for the install. This option is pretty much the sledge hammer approach, wouldn’t make us popular with the users and couldn’t guarantee that there wouldn’t be some other problematic program anyway.
The final option would be to have a separate collection, advertisement and program that was used for ‘pushes’ rather than request. This one would be silent and would be set to keep retrying at some schedule until it installs successfully. This seems like a lot of doubling up on deployment work and seems like it would provide an opportunity for the programs to become out of sync version wise.
Are others using one or more of these processes, or do you have an even better way of handling the situation?
Thanks for your advice and sorry for the long post.
Brett
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
MicrosoftBob
15 years ago
Hi Brett.
Yes, if it weren't for pesky users, our jobs would be so much simpler.
There are many different factors that play into the decision of how to accomplish this. Some companies have more intelligent users than others, some have management that tells us we must not disturb users, some have users that are simply uncooperative. Most companies have a mix of these along with the "easy" users.
The reason for the installs/upgrade is another factor -- the easiest tend to be the ones where the user actually WANTS the software. The hardest are the "forced" installs/upgrades where the software is required but doesn't benefit the user (at least not directly).
Another consideration is whether or not your users turn off their computers during non-working hours and if you have the ability to do wake-on-lan. Or perhaps your users have laptops they disconnect and take home with them each night. Or maybe they have three shifts and the computer is always in use by someone (ie no "downtime").
Still another is the level of urgency for the install/upgrade. Is this a high risk security problem? Or is it an upgrade that could be delayed for days (or weeks) without any significant negative effects?
All of this seems to prove that there is no universal solution and the scenarios you mention are all probably "correct" for different circumstances. Your distribution system (SCCM) may not have enough user interface options for your particular situation. Sometimes, the best way is to script a "wrapper" that will present a dialog box to the user before the install. It may or may not have a cancel button, depending on the situation. I personally use Wisescript for this.
Citing some specific items in your post, I prefer to use /passive (or more frequently /quiet) instead of /qb! because it will silently error out and quit without bothering the user with some sort of discrete error message that the user doesn't understand. You need installer 3.x for these options.
Regarding your dilemma about the program in use, you could specify that the install/upgrade only run when there is no user logged on. Alas, some users don't log off for weeks, or they have laptops as indicated above, etc, etc, etc.
As far as your "sledgehammer" approach, this is sometimes necessary for the users that continue to abort or otherwise circumvent the installation process. However, you just need to get management on your side in advance and you should be fine. Explain to your boss what will happen if the users keep ignoring the upgrade. Advance communication is key, both to the end users and to management. Save all email communication for evidence in case of a problem. Strive to be happy.
I hope all of this answered your question.
Yes, if it weren't for pesky users, our jobs would be so much simpler.
There are many different factors that play into the decision of how to accomplish this. Some companies have more intelligent users than others, some have management that tells us we must not disturb users, some have users that are simply uncooperative. Most companies have a mix of these along with the "easy" users.
The reason for the installs/upgrade is another factor -- the easiest tend to be the ones where the user actually WANTS the software. The hardest are the "forced" installs/upgrades where the software is required but doesn't benefit the user (at least not directly).
Another consideration is whether or not your users turn off their computers during non-working hours and if you have the ability to do wake-on-lan. Or perhaps your users have laptops they disconnect and take home with them each night. Or maybe they have three shifts and the computer is always in use by someone (ie no "downtime").
Still another is the level of urgency for the install/upgrade. Is this a high risk security problem? Or is it an upgrade that could be delayed for days (or weeks) without any significant negative effects?
All of this seems to prove that there is no universal solution and the scenarios you mention are all probably "correct" for different circumstances. Your distribution system (SCCM) may not have enough user interface options for your particular situation. Sometimes, the best way is to script a "wrapper" that will present a dialog box to the user before the install. It may or may not have a cancel button, depending on the situation. I personally use Wisescript for this.
Citing some specific items in your post, I prefer to use /passive (or more frequently /quiet) instead of /qb! because it will silently error out and quit without bothering the user with some sort of discrete error message that the user doesn't understand. You need installer 3.x for these options.
Regarding your dilemma about the program in use, you could specify that the install/upgrade only run when there is no user logged on. Alas, some users don't log off for weeks, or they have laptops as indicated above, etc, etc, etc.
As far as your "sledgehammer" approach, this is sometimes necessary for the users that continue to abort or otherwise circumvent the installation process. However, you just need to get management on your side in advance and you should be fine. Explain to your boss what will happen if the users keep ignoring the upgrade. Advance communication is key, both to the end users and to management. Save all email communication for evidence in case of a problem. Strive to be happy.
I hope all of this answered your question.
Posted by:
brettski
15 years ago
Thanks for your time for the long post MicrosoftBob. I'm glad that it sounds like others find this a complicated situation as well and that what I've setup currently seems to be inline with what you suggest. I will have to give passive another go, but I thought I tried that initially and it had a cancel button ... or something like that. I will retest.
I suspect that the 'wrapper' that you refer to is something similar to the 'notification' program that we use. We've also just started using task sequences which provide a bit more control over how the install runs vs 'chained' applications as was available in SMS.
After reading your post, I had a bit of a think about things and figure that installs can be generally broken into two groups, silent and non-silent. Some installs will fall into one or the other, and some will be in both depending on the install situation. User request applications will be non-silent so they know when the process has finished, and forced applications will be silent. The main exception to this would be when a forced install required an urgent or specifically timed install, in which case the non-silent sledge hammer approach would be used.
Thanks again for helping to get my head around the complexity of the situation.
I suspect that the 'wrapper' that you refer to is something similar to the 'notification' program that we use. We've also just started using task sequences which provide a bit more control over how the install runs vs 'chained' applications as was available in SMS.
After reading your post, I had a bit of a think about things and figure that installs can be generally broken into two groups, silent and non-silent. Some installs will fall into one or the other, and some will be in both depending on the install situation. User request applications will be non-silent so they know when the process has finished, and forced applications will be silent. The main exception to this would be when a forced install required an urgent or specifically timed install, in which case the non-silent sledge hammer approach would be used.
Thanks again for helping to get my head around the complexity of the situation.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.