Physical efforts in virtualization and mobility
So you’ve got a whole bunch of iPads out in the field hosting various applications and iOS9 comes out; one of the application vendors tells you his application isn’t quite ready for the latest OS and that you should hold off on updating your fleet. Problem – If you look for an option to disable iOS updates in your MDM suite you won’t find it, this is not a limitation of your MDM provider but more a control that Apple hasn’t provided to them. So if you ask your MDM vendor they will probably say it’s not possible, and as far as I can tell this is indeed the case. I’m going to keep looking but for now the best we can do is suppress the notifications that pop up advertising to all and sundry that a new version is available, but even this is not an out-of-the-box setting so I’m going to explain how it’s handled in AirWatch.
Now there’s nothing to stop users navigating through the menus to check to see if there is an iOS update, finding one and proceeding to download and update it themselves, so this is about as good as it gets for now. According to the comments this short article it is possible to use applednld.apple.com via a proxy server (although I think it should be appldnld.apple.com – note no ‘e’ on apple) to disable access to the download location but I didn’t have any joy with this. If I ever get any further with this issue I’ll post an update with the final solution.
DEP was discussed at a high level in the previous post; it is a facilitator for corporate owned iOS devices to be quickly enrolled into MDM solutions, all of the major MDM vendors support this.
First off, an account is required to manage the DEP portal and the devices within it. This is essentially another Apple ID which is created at https://deploy.apple.com – I think it is worth pointing out here that I tried using the same account that was used for management of the APNS certificate to start with and this wasn’t allowed so be prepared to manage two accounts going forward, one for DEP and one for APNS.
Now this process will be pretty much the same for any MDM provider but true to form I’m using AirWatch here. What we are doing is linking the MDM solution with the DEP account which contains the devices, once complete all of these devices should appear in the Device Lifecycle section of AirWatch (it may not actually contain any devices at this stage so this may happen later). So head over to the AirWatch console and navigate to:
System > Devices and Users > Apple > Device Enrollment Program > Configure
In order to link the two systems a token needs to be uploaded from AirWatch to DEP so from within this section, select to download the MDM public key file and then click the link to be taken straight to the DEP page and log in with the account created previously.
Once within the DEP portal you may be startled by how sparse it is, there really isn’t very much one can achieve in there over and above the initial setup.
Considering DEP holds your organisations inventory of iOS devices you may think you could run reports and so on from here but this is not the case. DEP will provide a very high level overview of what is in inventory and some rudimentary details of the MDM server(s) (yes you can add more than one) that is linked to the DEP account, other than that all other management and reporting is handled within the MDM tool.
Finally there is the opportunity to assign devices if they are actually ready at this point, which can be assigned via either order number of by serial number. At this point it should be explained that DEP only ties into affiliated Apple resellers, if you do not purchase them from such a supplier DEP will not be an option for you so ensure you ask this question of the supplier before committing to an order. Personally I would always use the Order option as you will get the whole lot dumped in there with no messing about, in fact once up and running the supplier can simply drop devices into the portal (you will receive an email notification) and so long as the ‘assign automatically’ box was ticked on the server setup in the previous section, no further administrative action is required on your part. If you like though, you can not do this and paste in the serial numbers to DEP and have them enabled that way.
(Back to the) AirWatch Console
So here we are back at the AirWatch Console and we are now in a position to create the first DEP profile via completion of the DEP wizard. First of all you’ll be prompted to upload the Apple Server token file that was downloaded from the DEP portal previously to complete the linking process.
The wizard will then guide you through the creation of the first DEP profile; after which, additional ones can be created manually. As I have been through the wizard previously on my deployment I can’t re-invoke it without a lot of phaffing about so below I have will go through the settings as part of the manual profile setup which is the same but just displayed differently on screen. The profiles are split into three sections, Authentication, Features and the Setup Assistant:
Authentication can be simply enabled of disabled, the default is ‘On’ which will result in an authentication prompt for the user as part of the enrolment process. Below is how this section will change if Authentication is set to ‘Off’. The device can be ‘Staged’ in this mode, so enrolled and ready to go but not tied to any particular user. The options here are for:
Note, if Single or user device is set an AirWatch basic account would be selected and used to enrol the device which can help place the device into a specific Organisation Group.
Going back to the first screen shot above, the next option is the Device Ownership Type. Now I’m struggling to think of a scenario where anything other than Corporate Dedicated would be used here with the other two options being:
Employee Owned (BYOD) devices just don’t fit in into the DEP model at all, not least because end users wouldn’t be able to purchase and link them into DEP (happy to be corrected on this)
Corporate Shared would be better using no authentication and staged as the below screenshot shows but instead selecting the ‘Multi-User device’ staging mode. Users can then authenticate as and when each time the ‘check out’ a device so it can be returned to the pool for the next user.
Lastly in this section, the device ownership is selected for the profile along with the organisation group where you want the device to land once enrolled. These options will change again based upon previous selections, for example if Multi-User Device is selected, ‘Corporate Shared’ will be enforced and greyed out.
Here we set the Profile Name, Department and Support number which are compulsory free text fields followed by some DEP specific MDM settings.
Require MDM enrolment – Yes there is an option disable enrolment as part of this process, I really don’t know why you would disable this but the option to skip is here folks if you chose to. This is pretty smart because if there are ever any issues with the iPad or there is a change of ownership, you can send the device a full device wipe instead of an enterprise wipe; it will then be back to an out of the box configuration maintaining the enrolment settings and enforcement into the MDM server.
Supervision – As mentioned in the previous post which covered supervision, for the Corporate Owned model, which DEP is aimed at I would always enable this to expose the enhanced management and security features to the MDM profiles
Lock MDM Profile – Again mentioned in the previous post, for Corporate owned, this would normally be enabled so that the secure profile cannot be removed by the end user.
Device Pairing – This is whether you want the end users in question to be able to connect the mobile device via ISB to a workstation to use things like iTunes. This is probably the only option here that’s worth giving any real amount of thought to disabling.
The ‘Hola’ welcome wizard that most iOS users see out of the box can be tailored in this section to streamline the start-up process. I’m not convinced these require much explanation as they are fairly self explanatory but most of these would be set to ‘skip’ to make the process fast for the end users. It is worth not skipping the Apple ID though as a valid ID will be required to download the MDM agent on enrolment from the Apple Store. Most of the other items can be managed via MDM profiles anyway.
Something very important not to miss in order to close this process off, is to actually assign the DEP profile to the devices. Going to the Device > Lifecycle > Enrollment Status page you can select one multiple or all devices. Then select to assign DEP profile as shown below.
This can be a bit of a pain if you have multiple DEP profiles to assign to different devices.
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.