Nice! Sounds like a feature request for VMWare
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:
result - app B update got to locked device, A caused AW issuing “Install application profile” and stuck
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.
we have the same issue with internal app. try to do step 2 from Grego…all devices have tag.
its doesnt work …
What does not work? (please elaborate)
- Tagged devices do not show in the Smart Group?
- Device does not install the application while locked?
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.
Tested on cn138, it is 19.03.0.0 (1903) and on 220.127.116.11 (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?
we have this issue only with our internal apps.