Intune iOS App deployment confusion

Brass Contributor

I'm having a difficult time getting a grasp of when/why to deploy App Store apps or VPP apps, and when to use device or user licensing for iOS devices.  I've glanced and gleaned from different sources, but it doesn't seem easy to get succinct information other than lots and lots of testing and experience.

 

To level-set, here are the things that I understand (possibly incorrectly):

  • 'with enrollment' means that the device has been enrolled with Intune, regardless of ownership.
    • for iOS, this means through Apple ADE/DEP for corporate-owned, or manual install/login to Company Portal on BYOD (and corporate-owned that aren't in ADE/DEP).
  • 'without enrollment' means that the device is not enrolled with Intune, but App Protection Policies may still apply to some apps
  • In order for an iOS device to be 'supervised', it needs to be enrolled through ADE/DEP, or Apple Configurator.  Simply installing Company Portal and switching the device to Company owned does not enable supervision
  • iOS/iPad OS apps can be added to Intune either as App Store apps or through Apple VPP.
  • Apps deployed with 'Available' intent can only be targeted to user groups
  • To silently install apps (without needing the user to be signed in to the App Store), the app must be deployed with device license.
  • If a 'Required' app is deployed with a user license, the user must be signed into the App Store with an account (and accept that the organization can grant them temporary licenses for apps)

 

Questions:

  • When the term 'user affinity' is used in the MS docs, does this simply mean all scenarios other than devices used as kiosks?
  • I've experienced that the Company Portal (deployed as part of the Apple ADE enrollment process) does not automatically get updated; we've had users who have had versions several months (up to a year) old.  Does the Company Portal need to also be pushed as Required to these supervised devices?  Or is something wrong (should it be updating automatically when installed during automatic enrollment)?
  • For 'free' apps such as Microsoft OneDrive, Outlook, Office, etc., should we prefer VPP-licensed apps over App Store ones?
    • Are there any differences that I should be considering (I understand that the VPP ones are "loaned" to the user and can be revoked).
  • We've experienced that app protection policies (APP) apps were applying to Microsoft apps and discovered that (1) the users installed the apps manually through the App Store and (2) IntuneMAMUPN app configuration policies were not pushed previously.
    • Can these app configuration policies be pushed to manually installed App Store apps, or must the be deployed through Intune.
    • If they must be pushed, must they be VPP apps or can they be App Store apps?
  • I understand that 'Available' intent apps can only be targeted at user groups.  If we wanted to prevent certain apps from being available on certain devices (e.g. BYOD), how could that be accomplished.  For example, since availability of an app assigned to the user, and the user has both a corp and BYOD device, how would we be able to prevent the user from seeing/getting the app from the Company Portal?

 

Thanks in advance!

Bryan

3 Replies

@Bryan Hall yeah, you're pretty much spot on there. 

 

User affinity is where the device is allocated to a particular user, shared devices (no user affinity) do not need to be set to kiosk (single-app) mode, this is ideal where devices are shared between multiple individuals, such as students, that require a host of applications.

 

No idea, currently having the same problem with Company Portal, assigning it as a required (VPP) app appears to cause a conflict/issue (check under Device-Managed Apps or Apps-Monitor-App Install Status) it does actually get the app to update. Still trying to figure out where the blame lies for this 'issue' at the moment. Technically it's a VPP app, issued from a token that is set to automatically update yet seems to be stuck at the version that was installed when the device was provisioned.

 

This is subjective, however I prefer to assign (to devices) any apps that are required, such as Teams or Office suite. This negates the need to issue a managed apple ID, and removes any reliance on the end user to operate an Apple ID. I don't believe you can assign non-VPP (or LoB apps) to a device...?

 

App protection policies (APP) apply to (Intune-licensed) users, these apply to MAM-aware apps regardless of app ownership. APP can be split between BYOD or Managed devices, with app configuration policies (containing the IntuneMAMUPN) being applied to managed devices.

 

Under App assignment use Available for enrolled devices and then (separately) implement device restrictions that would prevent users from enrolling personal devices maybe?  

 

Hopefully these help, please feel free to ask if anything's not clear, and I'll update this if I find anything else on the company portal issue.

 

 

 

 

@r0bu Thanks for taking the time to respond.

 

I have a ticket open with MS regarding the Company Portal deployed during ADE-enrollment to see if that version is supposed to update itself.  So far they have not stated whether it should or should not behave that way.

 

Without it being pushed as a VPP, required app, the out-dated Company Portal will prompt the user to Update, which will bring them to the regular App Store, but it won't let them install that one and will provide the error "Cannot Update App.  Intune Company Portal cannot be updated because it was refunded or purchased with a different Apple ID".  But if we do push out the VPP Company Portal as required, it will install.

 

In our scenario, Company Portal isn't used regularly by the user base (some may have never even opened it after the initial enrollment).  So we've observed that the versions of the Company Portal appear to still be on the version that was installed during initially enrollment.  It could be that under normal circumstances and regular usage, if the Company Portal is periodically opened, it will be within the supported version range that it will update itself.  I have no proof of that though, just speculation.

Hi @Bryan Hall,

I've since received this response from MS support

The reason that the application is not updating is due to the VPP handling the deployment of the Company Portal application in the profile and not Endpoint/Intune.

To remedy this issue, simply deploy the VPP version of the Company portal to the devices using Device licensing in the assignment.

Doing so allows Endpoint to take over update control and will force the Company portal application to update to the latest version on the devices.

 

The assignment won't deploy the company portal to the device as it will already be deployed by the Enrollment profile/VPP, it will just handle the update.


I hope this helps?

 

Rob