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.
Since we just saw an e2e hack-a-thon demo on this; updating the status.
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.
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.
Many organization clean their collection frequently. This will create big impact to them
Jens Lamade commented
Software should be uninstalled automatically by a client as soon as it is removed from a collection.
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.
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.
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.
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
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).
I'd love to see it, primarily for user based assignments. It would be sweet to use automation to pull a user id from an AD group, then have sccm take care of uninstalling the app for you.
Law YT commented
Yes. i supporting the idea to give you an option rather default. We don't want all the type of applications uninstall when removed from collection.
It's just like GPO deployment where there is checkbox "Uninstall when fall out of scope" for you to choose.
For end user to auto uninstall when out of scope, probably need to build some smart logic behind to ensure it's genuine as i see occasionally something wrong with SCCM which causing collection memberships being removed and trigger uninstallation causing a nightmare. Just imagine you have few thousands users software being removed.
Iain Fairbairn commented
You do have to be careful with these kinds of features. I have seen some pretty horrible incidents where people use exclusion collections as a dead mans switch style approach to avoiding having something install or trigger uninstalls (even worse they use direct memberships for exclusion collections....). I am not arguing against the feature at all and would support its inclusion as an option however I would suggest, 1) ensure it is never the default setting to uninstall when out of scope. 2). perhaps have a tooltip and/or popup "are you sure?" type dialogue when someone chooses to switch this on.
Ionuț Maxim commented
I totally agree with HoustonAU, this would be a very neat feature.
While this can already be accomplished through creative collections, I think an integrated and supported way to do this would be much better.
If you need to do this now you can create a collection that includes all devices with the software installed but exclude devices that are in the 'Install' collection, then just do an 'uninstall' deployment to that second collection.
It works but is a bit of a pain to configure for every application.
Would be preferable to simply have a tick box on the deployment to say 'Uninstall when item is out of scope' or something similar.
I also disagree with 'Anonymous', all configuration management software is 'dangerous' if you don't know what you are doing.
I also think that this would be a very bad idea. There are multitude of scenarios where a resource might get removed from a collection, one of them being accidentally removing it from the console.
I love this idea. It would be an big step from an task-based to an status-based deployment solution.
Mike Compton commented
@Mirko Colemberg - I DO NOT feel that it is the System Center team's role, to NOT write code in case an admin uses it incorrectly. They do not have the role of policing how we administer our estates.
If they took that approach, we would not have any OSD solution, in case people accidentally deploy a client OS to their server estate.
If you regularly accidentally delete computer objects A) change the permissions of your role to prevent this and B) be more careful!
i fully support this action. Uninstall is a nightmare !
well Kind of dangerous behavior imho. but you can achieve this by creating a uninstall collection and include "all Systems" that you want to behave like this. as Long as a Client is also in the installcollection, the Software will be deployed to this Client. if you drop him out of the install collection - well the uninstall collection will be do the rest
Someone else has a similar suggestion. It's a very good one and shouldn't have the votes for it split.