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.
Check out the new uninstall behavior in 1804 tp.
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.
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.
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.
Adam Juelich commented
It's not in 1806CB, only 1804TP.
Kiran R commented
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
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?
+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).
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.
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
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.
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.
AdminMark Silvey - ConfigMgr Product Team (Engineering Manager, ConfigMgr, System Center Configuration Manager) commented
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).