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 - 9.4.0.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.
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.
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.
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
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.
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:
tag all supervised devices
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.
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.
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?
