Systems Management Question

How do you deploy/uninstall a program with SCCM if user interaction is required?

10/15/2014 12970 views
Dear all,

Case: I have a couple of machines with Adobe Acrobat XI installed. I would like to remove this via SCCM 2012 application deployment. Usually, this can be done unattended with msiexec /x /q.

Problem: This only works, if Acrobat is not running, else msiexec will terminate with error 1602. This could be solved by running msiexec non-unattended (in this case the user would be asked to close Acrobat) or by a batch that checks for the process and then asks the user to close it. However, execution of the uninstall-command via SCCM usually happens in the context of SYSTEM, in the background. The user (non-admin, of course) will not see it and have no way to interact.

Question: How do you deploy a package or application with SCCM and at the same time have the process displayed for the logged on user?

Surely I am not the only on facing this problem with SCCM. How do you solve this?

Thanks and regards
Answer Summary:
3 Comments   [ + ] Show comments


  • As I remember it can by done by checking option "Allow users to interact with this program" in SCCM Program Properties.

    • That's it! I thought of this as well, but got the impression that with applications, other then packages, this can only be checked if the installation behavior is set to "Install for User" (which I don't want). My fault: you simply need to set the logon requirement to "Only when a user is logged on", and then the program is being run as SYSTEM, but the user can interact with it.
  • How about only running the uninstall when no user is logged on? The application won't be running to cause the issue.
  • Actually, it is running a service that needs to be stopped. I believe that you can use the quiet switch "/QB-" and it will ask the user to stop the service if it's running - but I could be thinking of something else.

All Answers

Solution: as proposed by rad33k above, this can be done via the Deployment Type's User Experience tab. Set Logon requirement to "Only when a user is logged on" and check "Allow users to view and interact with the program installation".

Thanks, rad33k, unfortunately I do not know how to mark your comment as the correct answer.
Answered 10/16/2014 by: triadenfisch
Senior Yellow Belt

  • You are welcome - I'm glad that I could help.
    I think that you can add a summary of the question (at the bottom of your main post you should see: "Click here to enter a summary of the best answer(s) for this question (optional)"
This content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.
It is not a complete answer to your question, but why not kill the process before uninstalling? You could wrap the uninstall in a batch file or a vbscript file and kill the process before running the uninstall command...
Answered 10/15/2014 by: CraftyByte
White Belt

  • Not what I want; I want to give users the change to save their work.
One of the advantages of using AD groups to populate SCCM collections is that the group can be used for other, related purposes.

To wit, at clients I have worked with, the group's members would receive a message, via a generic HTA to which parameters are passed (group name, message text and so on), that the application would be updated on day 'x' at time 'y' and that they will need to not have it running at that time. They may receive a follow-up message on the day with 'z' hours warning. The message text would make it clear that the application would be terminated if it was running and that the loss of any unsaved work would be the responsibility of the user.
Answered 10/16/2014 by: VBScab
Red Belt

  • Sure, could do it like this. But I know my users, and many of them tend to ignore information like this or forget about it. Yes, that is not really my fault; but I like to give them the best service possible, so I want to take a safer approach, one they cannot ignore.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ