Apple DEP and Intune – Part 3 – The End

So, the day was finally there, my next visit to my customer with the DEP enrolled iPads that had been causing a lot of fuss, time loss and frustration. This time, we had gathered our forces, me and one of my Apple-technicians, the customer, Microsoft Premier Intune support and we also had a “real” technician from Apple available. The goal actually wasn’t to solve anything, but to gather enough information to submit a bug-ticket to Microsoft. But the day had only started.

First of all, a quick recap (for the full background story, please review my other post Part 1 and Part 2). This customer had, due to licensing challenges in Sweden, set up a second Intune environment (Cloud-only). They already had one hybrid installation but saw the Cloud-only as a better way to handle 400 newly bought iPads (today there are a lot more than that). They connected this environment to Apples DEP services to manage the enrollment and we started creating policies and managing applications. At first everything seemed to work as it should, but the more iPads we enrolled, the more issues we got. After following several advices from Microsoft (most of them undocumented at the time) we came down to basically three different issues, but all of them related:

  1. When we enrolled the iPads using DEP (with or without user affinity – more on that later on) and assign them to different groups in Intune, the iPads in about 2/3 of the cases end up in either wrong group, the default group or in “Ungrouped devices”.
  2. Many of the assigned policies are not getting applied or we see a huge difference in what’s getting and applied and what’s not.
  3. Because of Nr.2 we have a very hard time to get our apps deployed – and also – we were not able to use apps that required MAM-policies due the difference in DEP enrollment and enrollment using the company portal. So, for example, Office was proving almost impossible to get down to the iPads.

So, we decided to start with the policy assignment and deployment. Some interesting facts, from Microsoft – and by experience of the case, that you may need to think about when using DEP and Intune:

  • Always use user-affinity, it’s a lot easier, but you may need to worry about the management of Apple IDs in some cases, but after iOS 9, at least in a few less. And “everything” works as expected. You also get “real” names on the iPads – instead of just getting a few thousand “iPad”.
  • Some Configuration Policies do not apply to DEP-enrolled devices. I’m still awaiting the final report from MS, but apparently, some isn’t valid. MAM-policies is not officially supported either (but may have changed or being changed soon).
  • The enrollment process with DEP or iOS in general works a bit different from Windows and Android. The iOS devices will try to “mend” a failed enrollment, and that could lead to some issues. This is still being investigated and I’ll come back with more info.

So, first we verified that everything – still – was in good order and everything done according to best practice. We send some more xcode-logs to MS and when they had examined them we got the following link from MS – that pretty much solved, almost, everything:

Company Portal Support on corporate owned iOS devices

We had been trying to use the Company Portal before, and this, in a way worked. But the device was in fact not DEP-enrolled at this stage, we basically re-enrolled the device using the Company portal and this was not ideal and demanded a lot of work. But now its supported to register the device in the portal without the need of re-enrolling it, and voila! Everything started to work as expected. The policies got assigned instantly, almost, and if not we could force them to sync. This made the apps install etc…

So, why did this work and why did we not try this before?

Previously when you enrolled an iOS device using DEP the enrollment process was different from the company portal. In short, a workplace join didn’t occur. This created a lot of problems, some have been fixed and some fixes are rolling out to Intune and will be keeping rolling out during the spring. The workplace join is an important step in the enrollment process, and essential for several of Intunes functions. As I said, previously, it wasn’t supported to use the Company portal – and you actually did a new enrollment and workplace join if you tried.

On the 28th December last year, Microsoft released the above article about supporting the portal for DEP-enrolled “company owned” devices. This basically workplace joins the device (as far as I know) without re-enrolling it. Therefore, you get all the nice stuff from the Company Portal enrollment, without losing the functions and benefits of DEP.

In short, everything now works. The customer is rebuilding some of the policies and are working more with AD-groups for their users than what our original wish were, but we also have more functionality now then we were expecting. In short, they are very happy and pleased with Intune.

The only thing that we still need to solve is the enrollment issues with the devices ending up in the wrong group. But because we now apply EVERYTHING to the users this isn’t a problem at the moment. But for future use, we need a fix for this. And I also believe that there will be cases were we don’t have the option of using User-affinity. I’ll continue to work on this and report back as soon as I know more.

And a few last words:

This became a much longer post than expected. But we have been working on this for months, and finally we are “done”. To be honest, most (if not all) issues were related to bugs, issues and lack of functionality that were, in most cases, undocumented or unknown. And they all got solved by Microsoft being able to combine the great functionality of DEP with workplace join and the company portal. I want to thank Dom and Don at MS support, Daniel from Apple, my Apple-techs and of course the customer. Everything basically works better if you work together. To some things up, remember this when working with DEP:

  • User Affinity
  • Use the Company Portal
  • Keep a flat group structure
  • Deploy policies and apps to users if possible
  • User Activation Lock

And one last thing: The error code 0x87d103e8 when deploying an app usually means that you, during the wizard, entered an Apple ID. Wait for the apps to get deployed before entering it – if you use one. This for some reason mess things up, when the Apple ID already is entered when the apps get deployed.

If you have any questions, please let me know.

As a Solution Architect, Simon inspires customers, partners and colleagues to create the best possible workplace for their users. His main focus is the Windows platform – but todays workplace consists of so much more than that. As an MCT he is passionate about teaching and sharing knowledge. He’s a frequent speaker, blogger and podcaster – as well as a penguin fanatic.

Tagged with: , , , , , , ,
Posted in Intune, Okategoriserade
11 comments on “Apple DEP and Intune – Part 3 – The End
  1. covertparadox says:

    Do you know if DEP provisioned devices need to be factory reset whenever changing Apple DEP MDM server or even Enrollment Profiles? We are switching from Intune to SCCM for authority and was curious what I needed to do for devices which we have in stock but have not setup (we are using user affinity)

    • bindertech says:

      Hi, and thanks fo reading my blog! Sorry for this late reply. No, you don’t need to do anything thing in regards to alread enrolled devices when you update DEP-information. BUT! You will have to re-enroll all devices if you are changing from Intune to ConfigMgr as the authority. Hope everything turned out OK for you.

  2. dustinadam says:

    this seems odd, but i cannot find an answer anywhere: we’re working on migrating from maas360 to intune/sccm (hybrid). its all working well but i can’t figure out how to do the following:

    We are enrolled in apple dep, the integration with intune is working, and i can complete the onboarding by resetting the device just fine, but it is prompting for an apple id to install the company portal app, and i dont want users using apple id’s or having to work them through setting one up. is there a way to deploy the company portal app after initial dep enrollment without the device prompting for an apple id?

  3. dustinadam says:

    yeah, that sucks. thats gonna screw up Q1 royally for me lol. I’m being tasked with migrating 500+ iOS devices from Mass360 to InTune, and our current MDM doesn’t ever require our users to enter an Apple ID during enrollment or for app deployment. Well… $#it

    Microsoft seems to indicate that they now support it, but on in the Azure portal, and that SCCM support is coming “soon”:

    • bindertech says:

      Yes, its a feature we have been waiting for a while now. My guess, and I’m quite confident, is that it will be included in the next release of ConfigMgr that should be out shortly. Are you an educational user you may have some options though. But if you arent I’m afraid that you’ll need to wait. Or manage a bunch of AppleIDs. Its possible and I have many customers that does that, but its time consuming to say the least. But I’m more than happy to help if you want any suggestions or advice

      • dustinadam says:

        yeah, I reached out to our Microsoft Account Rep and put in an email to the InTune team thats working on migrating tenants to Azure, once I get feedback I’ll post it back here for your benefit as well.

        And no, we aren’t in education, so I can’t leverage the Managed Apple ID’s.

        I appreciate the response though, I guess I’ll go work on something else until the fix is released 🙂

  4. Keith says:

    Our company has recently purchased about 5000 iOS devices and we are starting to see them enroll. For these devices we have user affinity set up and are just deploying to them a simple security policy for passcode and the Exchange profile. We have a few devices that are having problems with Exchange, they don’t show up in the Exchange server so we can’t approve email. When these issues happened before Apple DEP we would simply remove the Exchange account and reset it up. However since its pushed from Intune we are unable to remove that profile. Also going into the company portal we can see the iPhones listed but the option to remove the company portal is gone. Is the only way to remove these accounts to do a factory reset?

    • bindertech says:

      You can remove the management profile as well, but that’s rarely what you want. Unfortunally those are the only ways. I would recommend to investigate the Exchange issues first and foremost. In theory, you should also be able to move the iPad to a different group or collection to remove the policy and then remove the account. Let me know if I can assist in any other way.

      • Dustin Adam says:

        well, looks like most of our woes have been resolved with 1702. I have one last question though, in the article above you mention that when enrolling ios devices with user affinity (which we are), they get a friendly name? we aren’t seeing that behavior, is there a config setting that i’ve missed somewhere?

      • bindertech says:

        Yes, I think lost of thing are solved in 1702 (and the eqvivalent with Cloud-only). Also, we are getting lots of new exiting features in the latest TP for ConfigMgr – so I advice you to look into that. Friendly name can take up to 7 days to appear Im afraid. If they still are named “iPad” after that I would look into it a bit further.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

I’m speaking!
I’m going!
Follow me on Twitter!
%d bloggers like this: