Updated 8/6/20 to reflect more accurate behavior when retiring apps
Workspace ONE app management (aka Software Distribution or SFD) has end-to-end lifecycle management of applications. This includes installation, upgrade, inventory, and uninstallation/rollback. The uninstall/rollback behavior is new to many admins, especially ones coming from traditional or “legacy “management platforms. This document will walk through how Workspace ONE application framework works in relation to rollback and how to plan for it. This will be focused on Windows 10, but it does apply to other platforms as well.
Workspace ONE manages everything to do with an app version. This is powerful in that if you un-enroll or enterprise wipe a device, all corporate data (including apps) gets automatically removed. This makes a ton of sense when dealing with BYOD devices where your colleagues bring in their personal mobile devices and then enroll them in order to get access company resources. You most definitely need everything to “undo” itself when management is removed. However, when dealing with corporate owned devices (such as Windows 10 PCs), this concept is a little bit trickier in that your users don’t really get a choice to what is put on there by IT. Management isn’t optional and therefore managed apps should never really get removed. This guide will be focusing how to deal with this for corporate-owned Windows 10 devices in the enterprise.
Application Uninstall – When does it happen?
Application uninstall can happen for a number of reasons. The first way is “Explicit”, meaning you actively and intentionally trigger an uninstall on a device or group of devices. The second is “implicit”, meaning the WS1 app framework automatically triggers uninstall when certain conditions are met. When either method is triggered, WS1 uses the value specified in the “App Uninstall Process” on the application itself (Edit Application > Files tab. Scroll to bottom). For example, here is one I have for uninstall command for Office 365 Pro Plus:
There are several scenarios where implicit removal happens:
Application Install Failures
- When you deploy an application and there is a error during installation (non-zero exit code)
- When you deploy an application and the application “detection criteria” fails. This means that whatever you configured in the “When to Call Install Complete” section, did not return true. This can happen if you incorrectly configured it or if the app legitimately failed to install correctly. Most of the time this is due to the admin not getting it right the first time.
- When you change the smart group assignment and devices are removed. This will queue the uninstall for the devices that are removed. It will show you the list of affected devices on the “Preview” window before you save (Publish). This can be cancelled before the final “Publish” button is hit.
These methods are more explicit but are often not well understood.
- When you retire an app by clicking “More > Retire” you may see two different popups depending on the version:
- Pre-2006 – “Retiring a version of an application will uninstall that version of the application from all devices where it is managed by Workspace ONE. If available, the next lower version of the application will be pushed to the devices. Please proceed with caution.”
- Post 2006 – “Retiring a version of an app will uninstall the app from all devices managed by Workspace ONE. If the next lower version of the app is available and assigned, no action will be taken because the device OS does not support downgrading the app.”
- They fixed the wording to more accurately describe the behavior:
- If another active version is available then no uninstall will happen. For example, if you want to retire v2 and v1 is still active (never retired), you can retire it and no uninstall will happen.
- If only 1 version is active, then retiring an app will send the uninstall command to the device.
- When you deactivate an app, you will see this message: “Deactivating an application will uninstall all versions of the application from all devices where it is managed by Workspace ONE. Please proceed with caution.” This does work for all platforms. Here is the behavior:
- Auto / On Demand Assignment: App will be automatically uninstalled.
- Note: The application install status in the console may not immediately be reflected and may require full app sample to be received.You can either wait for the sample to come back (usually every 6-12 hours per the agent settings) or manually trigger it on the device by hitting “query”.
- What happens on reactivation?
- Auto Assignment: If the specific version of the app that you reactivated has any “auto” assignments, they will get automatically re-pushed down to devices. Only the specific version of the app gets reactivated, not all versions.
- On Demand Assignment: App will be available for on demand install, but won’t be auto pushed.
- When you delete an app you will see this message: “Deleting an Application from AirWatch will remove it from one or more devices where it is an AirWatch managed application and it will be retired in the console. Please proceed with caution.” This essentially does exactly the same thing as deactivating an app but it also completely removes the app and its content from the console. This means you can’t reactivate or un-delete an app.
Retire – Send uninstall command down ONLY if no other versions are active. If another version is active, no uninstall will happen.
Deactivate – makes assignments inactive, deactivates the app, AND triggers automatic uninstall.
Delete – the behavior is the same as deactivating but also deletes the app completely from the console.
Other ways to uninstall
- When a device is un-enrolled, device wiped, or enterprise wiped.
- When a manual un-install (Removal) is triggered from the Console. There are 2 ways:
- App details > Device Tab. Check box next to device and click “Remove”
- Device Details Page > Apps tab. Check box next to app and click “Remove”
- App details > Device Tab. Check box next to device and click “Remove”
What is “Make App MDM Managed if User Installed” (aka “Assume management” or “take over management”)?
This feature will make the lifecycle of the app “managed” by Workspace ONE if the app is installed by some other means (user manually installing it, install from previous management platform, GPO, etc) and it passes detection criteria (When to Call Install Complete). Note that this feature is configured on a per-assignment basis. You can have one assignment that has this enabled and another that leaves it disabled. If detection criteria passes and an app is now managed, the rollback implications now apply. This only applies if the app is actually “pushed” from Workspace ONE to the device.
Example: Firefox is assign to 10k devices as “On Demand” with “Assume Management” enabled. Only 1k people install it from the catalog however, so only those devices that received the install command for Firefox are managed by WS1 and can have uninstall/rollback scenarios apply.
What happens if I don’t enable Assume Management?
If you deploy an app that is already installed on a device, it will show as “User installed” and Workspace One will not take over management. This means that no rollback or uninstall will occur if any of the rollback scenarios are met.
How can I protect against accidental removal?
- Ensure you don’t remove smart group assignments after the app is assigned.
- Enable Application Removal Protection on the specific OG:
- Modify the app to not have any uninstall logic
What happens when you add a new version to an app AND click the “retire previous checkbox”?
When you add a new version and then tick the “retire previous” box, then all previous versions will be retired and no longer visible in the default app view. Remember though that retiring doesn’t actually send out the uninstall command (see above for App Retire behavior). Then new app version will be installed per the assignment type.
My recommendation is to NOT check this box and leave previous versions in the console. This allows you to go back to a previous version if needed by using either retire or deactivate feature. Keep in mind that even though the older apps will still be active and shown in the app list and appear to have the old assignments on them, they will in fact not actually be usable or deployable. The console keeps a record of the various app versions and will only make the latest available for assignment and deployment.
What happens when you “Add Version” and do NOT retire previous.
Version 1 is kept in console and assignments are still listed but they aren’t active. The new version will copy over the assignments and those will be the ones that get sent down the device. This is a little counter-intuitive since the older app version still shows as “active” and lists the assignments. However the console is aware of the newer version and won’t also show the older version to devices.
You add a new version of Chrome and don’t check the retire box. When you click “Save and Assign”, the assignments from v1 will be copied over. Generally you will want to test this new version so I would recommend removing the production assignments and only add test assignment smart groups. Then once testing is complete, add the production assignments to back onto v2 (just like they were for v1). You can go back to v1 and see how the assignments were set. This way you are able to target testing for the new version and not affect devices with the older version until you are ready to upgrade everyone.
What happens if you don’t have a valid uninstall on apps?
The uninstall action will still run, but nothing will happen on the client. This can be used as a way to ensure certain apps are never removed from devices, but you don’t lose the ability to do full life-cycle management.
What happens when you enable “Assume Management” on the assignment but leave it as “On Demand”?
This app has to be pushed from the console or initiated by the end user via the catalog for this to take effect. Rollback will only apply to the devices where the app has been pushed.
- If you have dependency app linked to a primary app, the dependency app will also be removed if a rollback scenario is met on the primary app. The only exception to this is if the dependency app is also linked to another app that is assigned to this device.
- VMware Documentation
- VMware Techzone Software Distribution Operational Tutorial
- Tips and Troubleshooting
I hope this gives a good summary of how Workspace ONE app lifecycle management works and enables you to more effectively deploy Windows 10 apps in your enterprise.
17 thoughts on “Workspace One Application Management for Win10 – How Rollback and Uninstall Works”
What happens is we remove a user from a Smart Group that is assigned to an application? Will the application be automatically uninstalled? Does this occur the same or differently is we have directly assigned a User Group to an application and then remove a user from the User Group?
Yes if you remove a user from a smart group then each device they have with that assignment will get the app removed.
Have to use user context for the deferral window to show up
What if a user with admin rights manually uninstalls the application from add/remove programs? In testing that scenario, I’ve noticed that it appears to still show as installed when the user opens the VMware Workspace ONE app to view their suite of applications.
For managed apps, the agent collects the installed status from the Software Distribution registry keys. Unfortunately for user un-installation of managed apps, the inventory never updates itself because detection criteria never re-runs. The only way it can re-run is to enable desired state management. This feature, released in 2003 re-evaluates detection criteria every 12 hours and if missing, will reinstall. When you assign the app, click “add Assignment”, then “restrictions” (on left side). Enable “Make app mdm managed if user installed” and “Desired State Management”. Also, this person has a script that sorta works around this limitation as well https://code.vmware.com/samples/7348#
How is WS1 handling app updates/patching? We’re going through a POC and it seems this functionality is rather basic (manually uploading of the new app version). Coming from an SCCM shop, this seems a pretty big oversight.
For app updates yes you are correct. The only way is to do the “add version” and deploy out to the same smart groups you had on the previous version. There are some enhancements coming that make deploying apps and patching that should help in this area. I.e. deploy version 3 of apps to all devices that have a version less than 3 (regardless of smart group).
Can I ask how you’re currently handling 3rd party app updates? We’d like to go the WS1 route but our security team has concerns on how we’d manage 3rd party app updates. They are suggesting a product like patchmypc which will keep us tied to SCCM.
I have been testing retiring Windows 10 applications in our UAT tenant as we have to do it in our Production. I am actually seeing the Windows Application being removed from my test device when choosing “Retire” in the console. The version is SaaS 220.127.116.11, is this now expected behavior?
Brooks, if I created a software distribution package and it’s assigned to an OG below my top level OG is there any way to re-assign it to the top level OG without having to rebuild the package?
Unfortunately not :(. I wish there was as I make this mistake all the time.
Greetings of the day!
Just wanted to check that can we update the new version of the application deployed via product provisioning on workspaceone or is it possible only via distribution of Application via Apps and Books
I mean technically you can add new version of things in product provisioning, but if you are doing an App you definitely want to use Apps and Books. Product provisioning should only be used for scripts and even that use sparingly given that it’s not being developed anymore and has limitations.
Is there any method to unenroll Windows 10 devices without uninstall an app that’s being managed by WS1? Example: Google Chrome with an assign policy of “Make App MDM Managed if User Installed” and “Auto” deployment in a Device with Google Chrome previously Installed.
One of my clients did some test in their production laptops and now they need to unenroll that device but without uninstalling those apps.
Thanks in advance!
Unfortunately not. This has been a long-standing feature request by customers. Many customers just put some dummy values in the uninstall area so that the apps don’t actually uninstall.
Long time viewer, first time poster. I actually ran into an issue with Applications being removed even after updating the uninstall command on an app to be “na” as you’ve recommended. I’ve found that you have to first send out another install command so that the device knows about the updated uninstall command.
I’ve got an issue right now with Desired State Management being enabled and the Final Detection Criteria not being completed causing an install followed by an immediate uninstall.
Has something changed in the backend?
Michael – You are right in that if you change an app to have “na” in the uninstall string after it has been deployed, you have to re-push it to the client for it to pick up the setting. All of the app configuration is stored in the registry at the time of installation and doesn’t update unless a device receives another install command.
Regarding desired state – hmm. The behavior where the uninstall is triggered immediately after if detection criteria fails is normal behavior and has pretty much always been the case. Desired state just means that it will automatically attempt to reinstall if it detect it is not installed (this is done via the scheduled task).