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. 

The Basics

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:

Implicit Removal

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. 

Assignment Changes

• 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.

Explicit Removal

These methods are more explicit but are often not well understood.

Application Retire

• 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.

Application Deactivate

• 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.

Application Delete

• 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. 

In summary,

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”
    

Other Scenarios

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.

Example:

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.

Dependency Apps

• 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.

More Resources

• 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.