Physical efforts in virtualization and mobility
Quite a bit to get through in this post, ultimately what I want to discuss here is the Apple Device Enrollment Program (DEP) but this subject cannot be reached without first detailing the basic enrollment options in AirWatch, therefore I have made this a two part post which you could skip to if the lead up content is already understood.
End user agent based enrollment
This would be a scenario where the end user is either given an out of the box corporate device or chooses to use a BYOD. The steps a user would take would be something along the lines of:
Now the process detailed above is about the most manually intensive method possible and as you can see the user is required to tap and type several times and to also know or be told a few things about what they are doing. This process can though, be partially or pretty much fully automated as we will see.
The next step up from this handled in the user account setup process, where it is possible to send the user an email on account completion. This email can contain a QR code which has the server address and group ID embedded in it.
Pretty swish, but this method is relatively uncommon because of:
The final agent based enrollment method which is to use; email address.
This is probably the most common method as users will always know this info, it just requires a little more work on the back end to enable.
Pitfalls of agent based enrollment
Whichever way you look at it there is one common dependency on these three methods above and that is that they all require end user interaction. This means that things can go wrong as users may not know the information, understand what they are doing or just not bother enrolling at all because they can get away with not doing so. Another thing that can be done is to offload these tasks to an IT admin who can enrol as administrator then hand the device to a user. The biggest issue with agent based enrollment though is from a security aspect as devices can be simply un-enrolled and left in an unmanaged state.
For BYOD, agent based is the only way to go as users have every right to un-enrol their devices but for corporate devices, particularly on a medium or large scale two things are required; automation and security.
Corporate owned enrollment options
Apple Configurator is a kind of ‘offline’ MDM solution in its own right, as it can stage and apply configuration profiles to iOS devices. The trouble is, it is limited in that cannot work over the air (OTA) or as it must be physically plugged into the Mac OSX device running the configurator software. A USB hub can be used which can bank up to 30 iOS devices which can all be configured simultaneously making mass configuration and enrollment possible with Configurator. This works with AirWatch by having an (AirWatch) MDM profile imported into Configurator and into the banks of devices enrolling them en masse.
Supervision of Devices
Configurator enables ‘Supervision’ of Apple iOS devices which is a feature that enables greater security controls and configuration options. Although this is switched on via Configurator which is a tethered mechanism (in this instance at least), once enabled these additional features can be controlled OTA via the MDM solution of choice if it happens to support them. There are quite a few options that work with Supervised mode, but a few for reference would be to Allow App Removal, use of iMessage and erasing of content, but a more killer features would be things like Single App Mode which can be a very useful option for shared devices as it can lock the device to a single app. For corporate owned devices Supervision should be enabled wherever it’s practical to do so; if MDM is being applied to an existing fleet these will all need to be recalled so they can be physically plugged in to Apple Configurator, in the case of new devices being purchased however, the decision is more straightforward as these can have a supervised DEP profile assigned even before they come out of the box.
Device Enrollment Program (DEP)
First of all I want to point out that I am not comfortable with the use of the word ‘Program’ here which is what refers to a computer program. What we are talking about here is a ‘Programme’ which is more like a project or a system. Anyway, now I’ve proven my Britishness let’s talk about DEP at a high level.
Until last year there was the only option for mass enrollment and device supervision, and that was the Configurator and even that only arrived in 2013 with iOS 6. Then early last year a select few countries had access to DEP and towards the end of the year many more including the UK and may others too. DEP is a system provided by Apple which has been put in place purely to streamline corporate owned device enrolment into MDM solutions. The inner workings will be discussed in a follow up post but ultimately what it leaves the end user with is iOS version 7 or 8 device that can be taken fresh out of the box from a supplier and enrolled using a tailored version of the standard iOS start-up wizard, requiring no administrative involvement or use knowledge of the environment, other than their username and password (can be a basic account or domain).
One of the key benefits of DEP is a non-removable MDM profile can be deployed to the devices; even though both Configurator and DEP support supervision, only DEP supports this. Configuration profiles are not configured within the DEP portal this is all set within the MDM vendor console. We’ll take a look at this in part two of this post.
Samsung Knox and Android
Just for information its worth mentioning Samsung Knox which even though I am an Android Fan boy (FanDroid) it isn’t something that I have any experience of, but it is the only Android platform that supports mass enrollment in a similar way to that of DEP. This also includes Android for Work, the new Android MDM service provided by Google which aims to reduce fragmentation within the Android platform. So it is worth bearing in mind that features such as this are vendor specific on the Android Platform so we will need to wait for either Android for Work to develop or for other manufacturers to catch up.
That’s enough for part one which has been just an over of deployment options in the lead up to a more in depth discussion on DEP.