iOS 5 – Changes to MDM Usage Policies

I have already covered the new (enterprise relevant) features in iOS 5:
http://mobilitydojo.net/2011/10/04/ios-5-anything-in-it-for-the-enterprise-conclusion/

Right after releasing that post Apple just launched a couple of changes to how these features work, or rather the policies relating to the usage of them. (The features themselves are still on – don’t worry.)

So far Apple has been very secretive even by their standards regarding how Mobile Device Management has been implemented. Since several MDM vendors have had support for iOS devices for a while now, and supported pretty much the same feature set, it was obvious that they didn’t just all come up with this out of nothing. And they certainly didn’t. This was actually with the help of a documented API, but the thing was that the documentation wasn’t exactly publicly available. You had to apply and be approved before receiving the docs, and then you could implement an MDM solution for your customers.

As of last week they have made the docs available for a broader audience. It’s still not totally public – you will need an iOS Developer Enterprise account which should set you back 299$ a year. It’s not available for hobby developers either, unless they happen to have a Dun & Bradstreet number, which I’m guessing most hobbyist don’t have. If you happen to have an Enterprise account you can just sign in and actually read everything you need to know to develop your own iOS MDM solution.

Of course not everyone will be interested in developing their own solution for managing iOS devices. After all there a couple of vendors who have been down that road already, and you don’t need something homegrown just for the fun of it. Enterprises have been able to use the MDM API for a long time already, even if they are not aware that they are using it. But so far you have had to enroll to an iOS developer program as a company to obtain the necessary certificates for authenticating to the “Apple Push Notification Service” (APNS). While APNS will work with a iOS Standard Company account you still have to send over necessary details to Apple proving you’re a company entity and pay up 99$. (There is a misconception that the iOS Enterprise program is required – it’s not. Basic MDM will work with Standard accounts, but distributing in-house apps requires an Enterprise account.)

The good news is that Apple is now waiving this fee, and you can get your APNS cert for free. The process is outlined here:
http://www.apple.com/ipad/business/integration/mdm/

Basically your company needs to generate a Certificate Signing Request (CSR), you send it to your chosen MDM vendor who will in turn sign the CSR. The signed CSR will have to be submitted to Apple, and Apple will give you a certificate in return. (You will need a valid Apple id to sign in naturally.) Previously the entire process was performed by the customer without involving the MDM vendor at all, but this new process means that MDM vendors have to implement some new bits and bytes on their end to handle the signing part. While this means there’s still a step or two the customer needs to do it still sounds like an improvement to me. (The process to get your developer account approved by Apple could take 1-2 weeks if you’re unlucky.)

Trying to draw the line between the consumer market and the enterprise market it is also stated quite clearly in the License Agreement, (you didn’t think for a second Apple would skip a chance to present legalese did you?), that only company owned/controlled devices are allowed to use MDM. A normal end-user customer cannot sign up to a generic hosted MDM solution; the MDM control should only be used where an employer<->employee relationship is in place. Oh, well, consumers have iPhone Configuration Utility (now updated to support iOS 5) for configuration and iCloud for remote wipe so they will hopefully be able to get by without MDM Smile

Ice Cream Sandwiches For The Kids!

I was thinking about a pun about it being for grown-ups, but that might have been interpreted as me saying Android is all grown up. And I haven’t decided on that yet Smile

After a slight delay Android version 4.0, code name Ice Cream Sandwich has now been launched. This is the next major iteration of the operating system, and this time it should work both on tablets and regular phone form factors. As the number indicates it is not a mix of the 2.x and 3.x branch, but the next branch. All APIs and features from 3.x is included in 4.0.

The main focus of the release is on user interface improvements, as well as general updates of the apps and polishing the OS further. You can find screenshots all over the Internet of course of this.

As usual I don’t care about these things. Well, of course, as a user of devices I care about the interface, but this blog does not concern itself with such matters. A perhaps important feature for people reading this blog is that since Honeycomb features are supported this means that you now get full device encryption on the phone devices and just not the tablets.

Read more

EAS MD – Looking to The Clouds

I’ve grown quite fond of my EAS MD utility, and it’s also been great fun sharing the code powering it for the past weeks/months. When I originally started out coding it I was fueled by what I felt were shortcomings in the official diagnostic utility provided by Microsoft; http://testexchangeconnectivity.com. It only supported Exchange 2003 protocol level, had no means of dealing with security policies, and in general didn’t provide a whole lot of options. It worked OK, but not for the scenarios I wanted to test.

When you’re a programmer at heart this means there might come a moment when you get a feeling of “why not build what I want myself instead of accepting the tools available as is”. Not to mention that other people aren’t going to accept your “whining” either and will eventually challenge you to do better. (I wasn’t pressured by anyone else than myself when it came to this issue though.)

So I sat down with the intention of providing a tool for myself with the options I wanted, and decided quite early in the process that it would be something available for everyone (if I got it working that is). After deliberating the matter with myself I eventually decided that I would do it as a Windows application which seemed like the easiest implementation to do. ActiveSync basically being a plain web service it could obviously have been done on other platforms as well, but often the supporting APIs have less features in mobile frameworks than full desktop .Net, and if I had wanted to do it for something like the iPhone I would have had to learn Objective-C at the same time. It’s easier to just have to learn one new technology at the time :)

Today I have come full circle, returning to where we started, and present a web version of EAS MD to you :)

Read more

RSS for Posts RSS for Comments