Managing app versions effectively is crucial for maintaining system stability and user productivity. In this blog post, we’ll explore how the versioning works in Workspace ONE App deployment.
Adding New Versions
When you upload a new .msi file for an existing application (with the same GUID), Workspace ONE automatically recognizes it as a new version under the same application hierarchy. However, for .exe applications, you have the flexibility to add them either as a new application or as a new version of an existing application.
Assignment Behavior
Effective deployments are determined based on assignment groups. The highest active version takes priority if it has an assignment. If it doesn’t, the next active version with an assignment becomes effective. If both versions are active and the assignment of the higher version is removed, the assignment of the lower version becomes effective.
Adding a New Version with NEW Assignments
| Condition | Result |
|---|---|
| If the new assignment contains devices (assigned with the previous version) | When you add a new version with a new assignment which include devices assigned with the previous version (It doesn’t matter whether the devices are in the same smartgroup of the previous version or not), the assignment for the previous version becomes inactive, and the new version’s assignment becomes effective. The assignment count for the old version will drop to zero, but the install count might take time to adjust since devices still have the old version installed. Example Scenario: ● Old Version: Assignment → Device A ● New Version (Added): Assignment → Device A, Device B Result: Both Device A and Device B will have new version. |
| If the assignment doesn’t contain devices (assigned with the previous version) | If Device A already has the old version installed and Device B gets the new version through an assignment, Device A will remain unaffected, while Device B will receive the new version. Example Scenario: ● Old Version: Assignment → Device A ● New Version (Added): Assignment → Device B Result: Device A (Old Version) Device B (New Version) Retiring a version at this stage If you retire the new version, it won’t impact Device A (since it was never assigned the higher version), but Device B will have the higher version removed. Example Scenario: ● Device A (Old Version) ● Device B (New Version) -> Retire New Version Result: Device A (Old Version) Device B (Uninstalled) |
Tip:
To maintain existing versions on devices while you want to test a beta version on some devices, you will need to create a new SmartGroup which contains only devices for testing purpose and make a new assignment with that SmartGroup. (Here you don’t need to use exclusion groups in the assignment tab of the new version)
Retiring Versions
When you retire a version, the next highest version becomes active and resulting in two different scenarios:
| Condition | Result |
|---|---|
| If the next-lower version has an assignment | Current version will be removed, and the lower version will be installed. |
| If there is no assignment for the next-lower version, or only one version exists | Software will be uninstalled |
Retired versions will still be visible in the UEM console if you filtered by Retired.
Use Case:
If a new version introduces bugs and hinders productivity, you can retire it and push the previous, stable version back to devices.
Thing to note about the removal of unmanaged application
If both an unmanaged and a managed version of the same application are deployed on a device (even if they are different versions), the unmanaged app will not be removed when the managed app is uninstalled—unless the uninstaller command for the managed app is satisfied to remove the unmanaged app as well. So, to keep the application installed on devices while removing it from the UEM console, you need to modify the uninstaller command and remove the assignment or retire the version. For .msi files, this can be done by replacing the default uninstallation routine with a custom script or command.
Unretiring Versions
Unretiring a version restores it to an active state. If multiple versions under the same application hierarchy are active, the highest version will be deployed to devices, if the assignments are present.
Deactivating Versions
Deactivating a version makes all versions of the app inactive, including active and retired versions. The app will be uninstalled from devices, but it remains visible in the UEM console when filtered by ‘inactive.’
Use Case:
If your organization shifts strategies and no longer requires certain applications, deactivating them can help reduce clutter without permanently removing them from your UEM console.
Deleting Versions
Deleting an app version has different outcomes depending on its state:
| Condition | Result |
|---|---|
| If the version in Active state | The version is changed to retired state and the software is uninstalled from devices. |
| If the version is already in Retired state | The version is permanently deleted. |
You can delete specific versions of an application from the console, depending on your needs.
Activating Versions
Activating a version from an inactive state makes it active and deploys it to devices based on assignments. If there are multiple active versions, the highest version is deployed.
Note:
If you activate one version of an app when there are multiple inactive versions, the deactivated version becomes active, and the other versions enter retired state. If you unretire (activate) another version, the highest version among the active ones will be installed, based on the assignment attached.
Excluding Devices
Excluding a device from a specific version removes the software if the device is part of an assignment for any active version. If the uninstaller command is configured to remove the application, it will uninstall all versions. To avoid this, modify the uninstaller command to an invalid one to prevent the software from being removed (make sure to disable user notifications to avoid ‘uninstallation failed’ alerts).
Example Scenarios with Exclusions
| Scenario | Testing Results | Example |
|---|---|---|
| 1 | Assume the device is already installed with lower version. Adding a new version will deploy it on device A. And then Exclusion of device A will cause the higher version uninstalled. But lower version (which is now active) won’t install until the higher version is retired | Initial State: ● Lower Version: Assignment→Device A ● Higher Version: Assignment→Device A (now Device A gets higher version installed) Action: Put Device A in the Exclusion Group of Higher Version Result: Higher Version is uninstalled on Device A |
| 2 | In this case, Device A has the lower version installed. When a new version is added with the Device A being excluded (making the assignment at the same time), the lower version is uninstalled. The removal may not show in the ‘effective action’ panel but will be executed through the older version’s uninstaller command. | Initial State: Lower Version: Assignment→Device A Action: New Version (Added): Assignment→Device A, Exclusion -> Device A Result: Lower Version is uninstalled on Device A |
You can find details of the WS1 Application Lifecycle Management below as well.