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.
There are a lot of comments here, so not sure if this has been posted already or not.
What I've done in the past is:
1. Deploy the Uninstall to all Computers as Required. (that should be fine if you are sure no users have it installed manually)
2. Create a separate "install" collection, which you Exclude from the uninstall.
3. Deploy the same application to the install collection you Excluded.
That way, when a computer is in the Install collection, it will get the install. When removed from the install collection, it woul get the uninstall.
This is a mere workaround, your idea would be nice if implemented.
this is more or less implemented by using the Application Approval workflow for device per user.
* Collection with all deployments
* Approve Application = Install
* Deny Approval = Uninstall
With this scenario you even do not need a collection per App. :)
Is there any progress in this?
L U commented
We 'require' installation of an application with a deployment to a collection that shrinks as the machines upgrade old software to new.
And there is an additional 'available' deployment of the same application, to all machines, but the'uninstall' button stays greyed out (even after hardware scan, collection refresh, required deployment no longer applies because device has fallen out of scope).
Because the 'available' deployment remains, we don't want to uninstall, but we do now want to have the 'uninstall' button become active. This does not happen (CB 1910).
(later - ran app deployment evaluation cycle, and button changed to offer uninstall.)
Great feature, can't wait to see it implemented! We have over 7k collections with software for all platforms. Having this feature will reduce that number to 3,5k. Wonderful, that would be simply wonderful.
Nathan Nitzel commented
Can we get an update of status from Microsoft on this please?
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, Microsoft Endpoint 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