AirWatch not updating internal apps on locked supervised devices

We have been struggling with AirWatch not updating internal applications on locked supervised devices, the device needed to be unlocked before application will update.

We have tested this from AirWatch 9.1 - and observed identical behaviour.

After some troubleshooting we have identified the root cause.

When a new application is published to the devices two commands are queued.

  • Install Provisioning Profile
  • Install Application

The Install Provisioning Profile command is first in queue and Install Application is second.
The Install Application command is ONLY issued after Install Provisioning Profile command is successful.

From Xcode logs we can clearly see that Install Provisioning Profile command CANNOT be issued to locked devices.
The device will respond with NotNow if locked.


If a command is Queued in AirWatch it will be sent to the device every 5 minutes by default.

We have manually deleted the Install Provisioning Profile queued for the device from the database.

Avoid issuing database commands unless you are sure of what you are doing

SELECT * FROM [Airwatch].[deviceCommandQueue].[DeviceQueue] WHERE  DeviceID IN (12345) AND StatusID = 1
DeviceQueueID DeviceID CommandID StatusID TransactionID CreatedBy CreatedOn ModifiedBy ModifiedOn DeviceProfileVersionID CommandTarget RecommendedExternalApplicationID Message AppIdentifier ContentID ApplicationID InternalBookID ProductAssignmentID ValidationToken WorkflowID VppAccountID
4210508 12345 13 1 0C5C6FD1-199F-4195-88E7-4FEB0F26B971 352 24:40.9 4 39:41.7 7965 NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
4210509 12345 21 1 82040DAB-CCE7-4113-BD3F-984F7C1CDAA6 352 24:40.9 4 39:41.7 NULL NULL NULL NULL NULL NULL 1156 NULL NULL NULL NULL NULL
delete FROM [Airwatch].[deviceCommandQueue].[DeviceQueue] WHERE  DeviceID = 12345 AND DeviceQueueID = 4210508

Once deleted the command has disappeared from the troubleshooting tab in the console and application successfully updated on a locked the device in ~5 minutes.

Nice! Sounds like a feature request for VMWare :slight_smile:

Further info:

According to Airwatch, it is a feature not a bug; “Install Provisioning Profile” command pushed when assignment has “Remove On Unenroll” enabled.

So if we don’t want the Install Provisioning Profile command pushed, then we can’t remove on unenroll, kinda defeats the purpose of an internal app, at least for my org.

Latest from AW - product request PR-196866 to unbind setting “remove on unenroll” and application provisioning profile push been created on 04/04/2018. AW provided no ETA on it.

Currently we trying to get an acceptable workaround from them.

Will keep this post up to date.

So just a thought, but I know that internal apps require provisioning profiles to be installed for the application to launch and function normally since they don’t go through the normal Apple App Store process. If the Provisioning Profile command is not sent as part of the install, does anyone have logs of when the profile command is sent down to the device for the application to function?

The provisioning profile is already a part of the application, it’s built into the IPA. What AirWatch does is actually unzip the IPA pull out the provisioning profile and deploy it alongside the app. This behaviour is unique to AirWatch and is not really required for the application to run on the device (unless provisioning profile is different to what is built into the app).

AirWatch have updated the description of the “Remove on Unenroll” setting in AirWatch 9.5 however the deployment behaviour is identical to previous versions

That’s what I was thinking, but wasn’t really aware about the “unzipping” portion. Thanks for the explanation @daniil_michine

@Grego - We’ll talk to our TAM/TAS/whatever they’re called now and let them know that we support this request as well.

A bit of info from yesterday’s testing (AW v9.1):

Confirmed the “Remove on unenroll” behavior, this flag is only set on application deployment.
Meaning that if an app deployed with this flag as disabled the only way to enable the flag is to update/redeploy the application.

Another small update:

Say you have 2 internal apps to update, one with “Remove on unenroll” flag enabled (let’s call it app A) another with disabled (app B).

If you deploy 2 about the same time (time window short enough for probability user unlocking supervised device being low) then result on locked supervised device will depend on sequence:

(1) B
(2) A
result - app B update got to locked device, A caused AW issuing “Install application profile” and stuck

(1) A
(2) B
result - app A update caused AW issuing “Install application profile” and stuck, B also wont install on locked supervised device.

Stumbled into this issue updating multiply apps at the same time.

Issue can be avoided by splitting assignments for the same app based on tagging:

  1. tag all supervised devices
  2. create assignment with “Remove on unenroll” disabled and place this assignment at the top (highest priority)

Wrote powershell script to place tags on devices, tested deployment - solution seems sufficient for a time that we are waiting for vendor to introduce proper fix.

we have the same issue with internal app. try to do step 2 from Grego…all devices have tag.
its doesnt work …

Hi @Dimitrij

What does not work? (please elaborate)

  • Tagged devices do not show in the Smart Group?
  • Device does not install the application while locked?

Hi Andrew,

tagged devices I can see in this group but application it not installed automatically (deploy type --> automatically), as reason I see that devices have " Install Command Ready for Device" or “Unknown” score.
I cant remove this TAG over 400 devices and add it later again.

Issue still exists in Workspace ONE UEM 9.7

I open case by Airwatch and share this topic…no realy solution…

The reference bug number is : ARES-2992, ARES-2831, the issue will be fixed on 1902.

1 Like

Hi All,

Tested on cn138, it is (1903) and on (1811) - issue is still there.

Checked with VMWare state of requests raised May last year (PR-196866, AAPP-2388 ):
no ETA for PR-196866, AAPP-2388 is still under development

regarding ARES-2992, ARES-2831:
item ARES-2831 has been merged with the ARES-2992. It is under active development but no ETA as well.


We seem to be having a similar issue in our environment. We use a large number of public apps as well as internal, is it only internal that Airwatch has trouble with? Or should we disable Remove on Un-Enroll for VPP apps too?