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 will see this message popup: “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.” However, do note that this does NOT actually apply to Windows 10 or Android apps. The product team is aware that the messaging needs to be updated to reflect that it doesn’t apply to Windows 10 and Android devices.
- If you do proceed with retiring, here is the behavior:
- App will be changed to “retired” status and hidden from view by default. You must adjust the filter in the app list page to show “All” apps, not just “Active”.
- On Demand Assignment: The app does NOT uninstall from devices, nor does older versions install. Nothing happens at all.
- Auto Assignment: The app does NOT uninstall from devices, nor does older versions install. Install of older does appear to go down and get queued. However, this fails because the newer one isn’t removed first.
- 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 – makes assignments inactive, deactivates the app, but leaves the app installed on devices.
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:
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.