System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Option to uninstall an application when a user or device falls out of scope of the collection

This is a buggy, Would we like the option to have ' Uninstall Application when Resource falls out of scope of this collection' when an application is deployed to a collection, this would save us having to create 2 collections ( install and uninstall) and to deployments. This would save SO much time and reduce the complicity of application management.

873 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Steven John Cuthill shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • ITrooster commented  ·   ·  Flag as inappropriate

    The description option described does not correlate to the <started> uninstall behavior listed with 1804. Confirmed with 2 Microsoft PFE's that uninstall behavior does not exist as described in 1806, 1810, 1902.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Uninstall Functionality not in 1810 or 1902 when device is no longer a member of a collection. Still need to write an uninstall into a script when performing upgrades and versions changes that require removal of the old version or create an uninstall deployment. Like others have stated the competition has automatic installation built into the system when a device or user is removed from a group. Not sure why SCCM does not and required a significant effort to perform automated changes to new application versions within an enterprise.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Adding a checkbox, uninstall application when resource no longer in collection/AD group. If the resource is removed, trigger the uninstall of the application without making a second collection. This give the admin the choice one way or another if they want the uninstall to initiate. We have a lot of licensed application, we need to guarantee that the correct uninstall runs when the PC is removed from the AD group. We currently use Radia as our Win7 deployment software, we are migrating to SCCM but there are some very serious shortcomings with the uninstall logic. Even Self Service/Available apps, uninstall when removed from the AD group in Radia. We can't always rely on the user to complete the task of uninstall the application. Looking forward to SCCM enhancements in this arena.

  • Kiran R commented  ·   ·  Flag as inappropriate

    Hi, There is no option for uninstall behavior in 1806 CB. Can u please confirm again where we have to check this.

  • Jamie Drummond commented  ·   ·  Flag as inappropriate

    This would help delete half the collections 50% in our environment and improve performance with having to many collections. Having an uninstall collection is stupid if you ask me. You should just use the agent to perform the uninstall step rather than having to manual push yourself. Supersedance will not always work if you don't want to replace it with anything else. You can still use supersedance if you are doing an upgrade and let that take priority over collection permission. A simple removal from app collection should trigger uninstall provided no other app has a dependency. We say sccm is event based why not use the removal to trigger uninstall provided it does find entitlement by other means?

  • Alessandro commented  ·   ·  Flag as inappropriate

    +1. Would like the option not tied to any SCCM approval method but tied to the Collection Membership since other tools that integrates with SCCM may use their own approval process and need SCCM only to do his job (install or uninstall the app).

  • tripdes commented  ·   ·  Flag as inappropriate

    I concur with Klaus, it would be great if we could easily identify orphaned installations and invoke an uninstall command when they fall out of the deployment scope.

  • Klaus commented  ·   ·  Flag as inappropriate

    I would like to see SCCM know the desired state of the user or the user's devices - configured by group memberships and assignments - and "make it so".
    That means installation and uninstallation as required.
    See MSI, see Powershell DSC.
    Providing a per application and or per assignment switch to activate this behaviour would be OK.
    Ideally have the admin also set the default to on or off.

  • Craig D commented  ·   ·  Flag as inappropriate

    I concur - the TP 1804 feature is not the same as this request as that concerns apps that need approval. We all seem to want this behaviour to occur even for apps that don't require approval, i.e. an option within the application deployment to run the uninstall if the application is installed but no longer a member of the install collection.

  • bdam commented  ·   ·  Flag as inappropriate

    Not quite sure TP ability lines up with this UV item. The UV is asking to uninstall when no longer targeted by a deployment. The TP uninstalled when an approval is denied/revoked. Those strike me as totally separate.

  • We aren't quite ready to update the status on this, but have plans in this area. Our initial approach may not *exactly* be collection membership but would enable automated uninstall without the need for multiple deployments or multiple collections. I know that's a little vague, but we'll be able to give more clarity in the coming months. Stay tuned....

    Thanks and please keep the feedback coming, it heavily influences our priorities and implementations.


  • Angel_PRU commented  ·   ·  Flag as inappropriate


    I understand the concern. What I am suggesting is an option that is disabled by default but allows one to enable the feature on a per app (or deployment) basis, similar to the software GPO option.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Many organization clean their collection frequently. This will create big impact to them

  • Jens Lamade commented  ·   ·  Flag as inappropriate

    Software should be uninstalled automatically by a client as soon as it is removed from a collection.

  • Mike_C commented  ·   ·  Flag as inappropriate

    Be careful with this one. The Radia (HP Client Automation / Persistent Accelerate) product has this functionality and I've been on multiple support calls because of mass software uninstalls especially if you use things like group membership or OUs for deployments. Too many "cooks in the kitchen" can easily cause uninstalls when someone renames a group, changes OU structure, etc. If this is implemented, it definitely needs to be optional.

  • Angel_PRU commented  ·   ·  Flag as inappropriate

    As stated below, the option to uninstall when the user falls out of scope available in the Software GPO based installations is a great feature. We still used user-based Software GPO installations because of the ease of use and favorable user experience, makes back-outs a SIMPLE take, remove user from new AD global group, add to previous AD global group. Having that option in the console, like we did with SCCM 2007 on APP-V 4 based packages, would make management of the deployment of APP-V 5 applications (and it could help traditional application deployments also but I agree theirs more potential for things to go wrong with traditional (MSI/setup.exe) installations) a LOT simpler and user friendly.

    Upgrades work GREAT with supersedence, adding an option to uninstall the application when it falls out of scope (which existed in SCCM 2007) would make both upgrades and back-outs simple without relying on custom collections that require a Application Deployment and Evaluation Cycle to support a back-out.

  • Carsten commented  ·   ·  Flag as inappropriate

    To clarify a little, if there is no need for license management for a given application, there is no need to uninstall it if it falls out of scope.
    E.g. I work in a municipality with a lot of apps licensed based on number of citizens. So there is no need to uninstall these apps when they fall out of scope, because license costs aren't affected.

  • Carsten commented  ·   ·  Flag as inappropriate

    I think the software should only be uninstalled when the affinity for the user, which it is deployed to, changes.

    E.g. the application is deployed to User1 who has Computer1 as primary device.
    User1 then moves to a different department and starts working on Computer 2. When affinity is changed, by usage agent or user/admin choice, and Computer1 is no longer User1's primary device, the application is uninstalled.

    So it would require that each computer checks not only what is deployed to it, but also any software deployed to any user who has said computer as primary device.

    The user who has been assigned the application will not get the application installed if the affinity isn't changed.
    That way we can use it for license management.
    Most software licensing models are computer based. E.g. one license grants one installation on one computer.
    But most purchases are user based. E.g. software is bought for the user and not the computer.

  • L U commented  ·   ·  Flag as inappropriate

    Ah the good old AD software installation days.

    But in SCCM, when an application is pushed to a user but installs in SYSTEM context, does it belong to the user or to the machine? If a corporate machine has a shared user history, we don't want a different user logging on to uninstall the software. We just want authorised users to be able to _run_ the software. We deal with this better with AppLocker and with App-V. We don't want a situation where software is installed, uninstalled, installed, uninstalled, installed ... as different people use the machine. We do, however, want to be able to pull all installations of the software when it is retired or superseded - even on machines where users are no longer using it and it would otherwise not be superseded by a user-pushed supersedent application.

    If the targeting was to a device and the device falls out of scope in AD / out of the query collection, then we would likely want the software pulled off the device. (provided it was not due to an error in collection hierarchy where the members were temporarily dropped and re-instated - does happen in operation but not often).

← Previous 1

Feedback and Knowledge Base