This is, hopefully, the first post of at least, again hopefully, two post about my experience with Microsoft Intune (Cloud-only) and Apple DEP, and perhaps iOS in regular.
The setup are as follows: The environment is a new Intune, Cloud-only installation. Its only managing iPads at the moment for one customer with three different user groups. We are using DEP to enroll the devices, and our initial plan was (and still are) to have most of them without any assigned user. We are deploying a couple of free apps from Appstore, and also using a few policies.
The first issue we ran into was the DEP enrollment policies. We import the iPads using DEP and assign them to different policies based on user group. So far so good. (On a side note, I’m very pleased with the experience of Apple support in regards to DEP. It could be a bit tricky to sign up for it but the Irish support team is doing a brilliant job – and of course they have a beautiful accent.)
We enrolled a bunch of iPads for one particular user group and soon realized that about half of the iPads were using the Default template – not the one that they were assigned to. Strange enough, the (first) solution for this in our case was to create an additional group and put the groups for the different user groups below that.
Red is the new structure at an early stage. Blue is the old one.
This isn’t verified with the Intune-support, but will be on my list when all other things, hopefully, has been sorted.
Okay, now the iPads were enrolling to the correct group. But now we got to the second issue. We had, as a test, enrolled one single iPad from another user group – and this unit ended up with the rest of them in the group assigned to the default DEP profile. This is the second issue, but its actually two very annoying “features” that creates it. First of all, note the name of all the iPads:
When enrolled without user affinity (without an assigned user) the name of the iOS-devices (iPod, iPhone, iPad) in the portal will always be the device name in our case iPad – regardless of the actual name of the device. So, at the moment we have about 70 iPads named iPad. When enrolled with DEP and assigned to a user, we get the actual name of the iPad – but at the moment we don´t want to assign them to users.
As you can see, we can view the serial number of the iPad from most of the portal views – but as you may know, you can’t add a device to a group from these views, only create groups when you select one or multiple devices. And when you open a group and want to add a device to it – you only see the name, in our case lots of “iPad”.
All of these issues are reported using the feedback function in the portal – and verified with the Intune support. The (second) “solution” for this is in our case to only enroll one user group at a time and verify that the device is assigned to the correct DEP-policy. If devices end up in the wrong group, its easier to move them to the correct one. And in worse case, reenroll them.
Our third issue is all about policies, inheritance and compliance. And, to be fair, its actually several issues in one. Policies are for one thing not getting applied, and in some cases only a few of them are. And most of the iPads, regardless of the success in applying policies and installing apps are showing up in the console as Non-compliant. The solution(s) that I’ve received from the Intune support and found online are as follow:
From Intune support: Do not apply policies to the same user and/or device at the same time. In other Words, don’t use inheritance at all. Apply ALL policies to the lowest level necessary to apply them all to all devices/users. In our case, that means that we need to, for example, apply the same “General Configuration Policy” to ALL our Groups containing iPads – in the lowest level. This doesn’t seem to make any huge difference and hopefully we will be able to set this back to normal later on.
Found online (and later confirmed as a possible solution by the Intune support):
Do not mix the “old” MDM-policies with the new platform specific ones. Apparently Intune have a hard to evaluate them both if they are mixed. This, if not makes sense, at least is a good idea and will help bringing a bit more clarity to the policies – especially when tracking down what policies and settings are getting applied to a specific device. We have, however, not seen the error messages stated in the blogpost below that gave me the tip to change this. http://www.acloudabove.com/2015/06/08/intune-mdm-and-platform-configuration-policies-conflicts/
We do however see a lot of 0x87D11388 messages stating that “the iOS device is currently busy”.
And last but not least (for now) we have issues installing free apps from the Appstore. As for most other issues in this post, this affects most – but not all – iPads and are very irregular. Some iPads installs all apps, some (most) don’t install any apps and the rest install “Everything” between 1-3 apps. This could be an issue following the problems with policy application and compliance so we haven’t put that much effort to solve this YET. The interesting part is the two error messages we mostly receive when the apps fails.
0x0 = (According to the Intune Support) this is everything worked, but still Intune reports it as an error. This isn’t correct, because most of the iPads getting this message haven’t installed the app.
0x2EF9 = The app is already installed. This is due to the VERY long intervals between the inventory cycles (once every 7 Days). Again according to the Intune support. And the apps are actually installed in this case, but in some cases they were installed manually, and therefore the message.
0x87D13B62 = One of the most common once in the beginning, but at the moment I can’t find a single entry of this. This was a message that the Intune support had not seen Before and could not give me an answer on what it meant. And I haven’t been able to find any information online.
So – for now, we try to enroll all the iPads to one single enrollment account with user affinity. This have shown a higher success rate than the iPads without an assigned user. Also, this gives us the opportunity to use the Company portal to synchronize policies (works in perhaps 1/2 the times we try it) and also install an app from the portal (published to the user) to force a policy check in this way. This also “solves” our issue with the iPads all getting named “iPad”.
A few other short rows of information and things to know: – iOS devices fetch policies at least once every 24h, but the interval is random. – The HW-inventory runs once every 7 Days – to minimize data transfers. – You shake the iOS-devices to get the logs from the Company portal. – The iOS devices are very sensitive during the enrollment process. The smallest, and this is according to the Intune support, glitch in the network gets the device to end the enrollment process and start over again. But, it doesn’t start from the beginning, it starts from the last known state and tries to patch all the information, policies, DEP-information etc together. If this fails, or if you get a new network glitch the process starts all over again. – USE THE FEEDBACK BUTTON TO REPORT ISSUES. This is very important and the engineering and support team are monitoring this closely.
For now, that’s it. I’m waiting for the Intune support to get back to me after examining the logs of several devices. This post has two reasons, first to inform all other Intune-admins out there of the issues (and hopefully later on the solutions). But also to get some feedback and suggestions on how to solve it. Have you any experience with these issues? Please let me know and we could hopefully sort this out for more people than me.
This is frustrating (and even more for the customer) but I’ve so far learnt a lot and hopefully I’ll be Learning more over the last couple of Days.
Suggested reading: http://ccmexec.com/2015/08/intune-and-dep-some-leasons-learned/