Managing iOS update with Workspace ONE UEM

03/27/20: I’ve added the link below which details the version of the OS (both iOS and Android) officially supported by VMware.

VMware Workspace ONE Applications Support Policy (2960843)

04/28/20: Here’s another useful link from Apple if you need a better idea when the 90-day deferral limit hits for each iOS version.

Deferring Apple software updates

Last but not least, you definitely want to check out the link below if your UEM console is 1912 or later.

Managing iOS Updates: VMware Workspace ONE Operational Tutorial

This post is released on Thursday which is also known as Throwback Thursday #TBT!

As I mentioned in my previous posts, it is possible to block and schedule an iOS update from the VMware AirWatch / Workspace ONE console.

While no one can tell when the next iOS release will cause yet another headache for MDM administrator, it is possible to delay iOS update from a minimum of 1 day up to a maximum of 90 days easily without manipulating the Global HTTP Proxy starting with console version 9.3. From a security standpoint, 90 days should be more than sufficient for an administrator to test application compatibility and any other potential issues. This, of course, requires a supervised device and iOS 11.3 and above.

It’s also important to understand what this setting really means in a real-world scenario. I started a thread titled Delay Updates (Days) for OS in the VMware AirWatch community forum and sure enough, I’m not the only one who might get confused. I question whether delay up to 90 days starts:

A) after the latest release is available for download REGARDLESS when the device is initially enrolled, or,

B) after the device is initially enrolled in AirWatch.

Based on my discussion with VMware support, choice A is the correct answer.

Say iOS 12.3 is available for download as of 01/01/19 and we have the 90 days update delay in effect. If I open a brand new iPad pre-installed with say iOS 10.3 and enroll such device into AirWatch. The user will not be able to upgrade to iOS 12.3 or whatever the latest version available at the time until 90 days after iOS 12.3 is first released (i.e. 03/31/19.) They can, however, upgrade up to iOS 12.2 during that interval.

The same goes for devices already enrolled in AirWatch. They won’t be able to update to the latest iOS for up to 90 days after it is released regardless of when they were initially enrolled.

In other words, the restriction simply doesn’t let the device upgrade to the newest version for up to 90 days since it is released to the public.

If Apple releases iOS 12.4 on the 90th day, the device is still only allowed to upgrade to iOS 12.3.

In addition to the setting above, I highly recommend skipping Software Update during the initial device set up within the DEP profile as well.

Before enabling Delay Update (Days) within the restriction payload:

After enabling Delay Update (Days) within the restriction payload:

As of web console version 9.7, we still cannot push the iOS update to more than 3 devices at a time. Notice the option to REBOOT DEVICE and SHUT DOWN are also missing if more than 3 devices are selected. Why is that?

At first, VMware support suspected it was due to having custom values configured in the specific fields under GROUPS & SETTINGS -> All Settings -> Devices & Users -> Advanced -> Bulk Management. However, as you see from my screenshot below it doesn’t seem to be the case.

As of this writing, technical support explained this is by design due to console security reasons. However, no KB has been published on this just yet. Do you agree?