90 iPads in 90 Minutes

Today was phase one of our new deployment. We received the shipment of iPad Pros (9.7", 32GB, WiFi) that will make up two thirds of our deployment over the next three years.

I wanted to write in detail about the exact process of going from a pallet of cardboard boxes to 90 iPads ready to hand to students in around 90 minutes.

There are a few moving parts to this but they boil down to:

  • Unboxing
  • iOS Update
  • MDM Enrolment
  • User Assignment

Unboxing

I had the dedicated help of two colleagues to get through the unboxing, which is definitely the most tedious and time-consuming part of any sizeable iPad deployment.

Our devices came wrapped on a pallet but once I cut the wrapping, I discovered that almost every iPad was in an individual brown carton, inside which was an individual shrinkwrapped retail box.

So we settled into opening all these boxes. One person stripped the shrinkwrap, another pulled out and handed the iPad to me and then unwrapped and assembled each individual piece of the power adapter. The UK power adapter ships in two parts - presumably for space efficiency - and each has an individual plastic wrap on it. We just dropped the chargers into a big box and the cables into another to be picked later on deployment day.

The final point about unboxing is to note that I don't really care who gets which device. At this point, they're fungible as they're all going to be set up in the same way.

iOS Update

To my surprise, these iPads all came with a very recent version of iOS: 9.3.2. If it wasn't for the fact that Apple just released 9.3.3, today could have gone even quicker.

I decided to update all the devices to iOS 9.3.3 using Apple Configurator 2. I was going to plug them in anyway, so it seemed easy enough to just update them the same way.

Alternatively, since these devices are in DEP, I could have sent them an MDM command to update iOS. However, I didn't see the point of generating all that WiFi traffic for nothing and, also, I wasn't certain that that command would have an effect before the devices were fully set up.

So I plugged them into my Apple Configurator Mac, 20 at a time, and hit one button in Configurator. 10 minutes of playing Crossy Road later and it was time to move on.

MDM Enrolment

Our Device Enrolment Program was already set up and, while the devices were in transit, I had already allocated them to the correct PreStage Enrolment settings in our JAMF Casper Suite MDM server.

The slow way to proceed here is to:

  • Pick up an iPad
  • Connect it to WiFi
  • Step through the setup assistant until enrolment is complete.

The smart way to proceed is:

  • Create a blueprint in Apple Configurator 2 that automates the Actions > Prepare step
  • Connect 20 devices to Apple Configurator 2
  • Apply that blueprint
  • Play another game of Crossy Road

As I said before in Towards Zero-Touch iOS Deployment, the game is: never touch the glass.

So once I worked my way through 90 iPads, 20 at a time, here's what I had:

  • All devices supervised
  • All devices on the latest iOS version
  • All devices enrolled in our Casper Suite
  • All devices are named "iPad" in Casper and not allocated to any users yet

So the next phase is: allocate devices to users.

User Allocation

So at this point, I have 90 undifferentiated devices sitting in crates on a table. My next goal is to get those devices to:

  • Be assigned to a user in Casper
  • Be named with the full name of the user
  • Have some way of showing on the device itself which user got which iPad

Here's how I did it.

Firstly I exported from Casper a list of the serial numbers of all the enrolled iPads. I could have gotten this list from the DEP area in Apple School Manager, but I had four spare iPads which had not yet been enrolled and I didn't fancy scanning through a list to find which four serial numbers to exclude.

Next, I combined this information with a CSV export from our student database for all the pupils in classes that will get the iPad Pro. At this point, I have a CSV that looks like:

username, full-name, graduation-year, role, device-serial-number

Graduation Year and Role are two extension attributes I use to group students in the JSS for scoping apps and profiles.

Next, I wrote a Python script for the JSS API that basically did the following:

  • Parse the CSV file and for each row:
  • Create a user in JSS with the given name, email address, graduation year and role
  • Assign the device with the given serial number to that user
  • Set the name of the device to the full name of the user

Having done that, I have a Configuration Profile ready that uses the new-in-iOS-9.3 payload called "Lock Screen Message". This is scoped to every user that has the Role of "student". Once the user is assigned to the device, the profile automatically appears on the device.

The magic sauce is that the message contained in the profile is customised for each individual user. Casper Suite allows you to use place holders in a Configuration Profile which are substituted with actual values before the profile is pushed to each device.

In this case, the lock screen message is as simple as "This iPad is allocated to $FULLNAME". Here, $FULLNAME is the placeholder for the full name of the user.

The result is that each device gets a custom message on the lock screen - even before the iOS setup assistant has completed. At this point, I can just pick up each device, look at the soft asset tag on the display and put the iPad into the right class box.

Excuse the fuzziness - we kept the plastic wraps on the devices while handling them.

Excuse the fuzziness - we kept the plastic wraps on the devices while handling them.

The final result: 90 iPads updated, supervised, enrolled in MDM and allocated to users. Average time-per-iPad: one minute.

Towards Zero-Touch iOS Deployment

One of my goals for the next deployment is to, well, do it faster. The holy grail of iOS deployment is to "never touch the glass". That is, to engineer a system whereby the most you ever do to a device is put it in a case and plug it into a cable.

Is this realistic? Not entirely but, with Device Enrolment, I think we are very close.

Whether you can actually get there depends on what kind of state you want to deliver the devices to users in. There are three levels of 'preparation' that you can apply to a device:

  • Unconfigured: this is the 'shrinkwrap option'. The device hasn't been touched since it was delivered. There's nothing on the device.
  • Partially Configured: the device is enrolled in MDM and configuration profiles have been installed but no apps are installed.
  • Fully Configured: the device is enrolled, configured and apps are installed.

The "Unconfigured" option is great for businesses, universities and maybe even high schools. Basically, any situation where the users are adult enough to work through the setup assistant, log in with an Apple ID and let the setup complete.

The Partially Configured option is a good idea for middle school or any other situation where you want to guarantee that the user won't be able to use the device without certain security settings already in place.

The Fully Configured option is best for younger users or situations where the available bandwidth to install apps is not up to the task of many users installing lots of apps at the same time.

How can we deliver each of these scenarios with 'zero-touch'? Let's take a look.

Bootstrapping the Device Enrolment Program

The Device Enrolment Program lets you connect your Apple Devices directly into your MDM server at setup. As soon as your device contacts Apple's activation servers, it's redirected to your MDM server to be enrolled.

The question is: you need WiFi to talk to the activation server, so how do you get your devices up on the WiFi network and enrolling without touching them?

Turns out Apple Configurator is your friend here. As part of the Prepare step, you can tell devices to begin "Automatic Enrolment". Essentially, this initiates a mass jump-start of your devices into DEP. They're brought up on the WiFi and Configurator starts off the Device Enrolment process.

What happens after that is up to your DEP server. You can set options there to skip various of the iOS setup assistant screens, for example. At the end of the DEP process, you will have an iPad that is enrolled in your MDM server and has all the Configuration Profiles installed.

What you don't have is apps installed. For that to happen, you have to complete the setup assistant on the device. In various scenarios, this might require some involvement with the end-user or it might not. Let's look at some of those scenarios.

Zero-touch Unconfigured Deployment

This one is quite easy: basically don't do anything! In an Unconfigured deployment you can, in principle, hand out an iPad in a shrink-wrapped box and let the user do the rest.

There are a couple of caveats to this. Firstly, you can't guarantee that the device will be on any specific version of iOS. iPads often come out the box with quite surprisingly old versions of iOS. This isn't usually a problem except when you depend on certain features being available. In school situations, right now, you're going to want to ensure devices are on at least iOS 9.3 to take advantage of education-specific features.

If devices are in DEP, you can now force an iOS update from your MDM server, which might mitigate this problem if you don't absolutely depend on a certain iOS version from minute 1.

Zero-touch Partially Configured Deployment

In some deployment situations, you need the actual end user to do some setup on the device. This is usually because you need the user to authenticate to some directory service. The two most common scenarios in iOS deployment are:

  • Logging into an Active Directory account as part of MDM enrolment
  • Logging into an Apple ID as part of iOS setup

The latter case is probably the most universal example. That said, in this current world where you can assign apps to devices rather than users, it's not necessarily the case that every iOS device needs to have an Apple ID.

If you do need an Apple ID on the device, Partially Configured Deployment may be your best bet.

In a Partially Configured situation, you can deliver the device to the end users such that:

  • The device is enrolled in MDM
  • The device has Configuration Profiles installed
  • The iOS Setup Assistant has not been completed
  • No apps have been installed

In this scenario, you are using the MDM server's pre-stage features to design a setup experience for the user that might be much simpler than the standard out-of-the-box iOS setup experience.

In pre-stage, you can configure the Setup Assistant to skip several panes of settings, such as Siri, Apple Pay, Zoom and Terms and Conditions.

You can also skip the Apple ID login pane and the Restore from Backup pane, although you probably don't want to to this. In this scenario, you need the user to enter Apple ID credentials.

If you are using Managed Apple ID, users are assigned a temporary password. This is where the user enters that password and creates their own permanent password.

The benefit of a partially-configured model is that you can guarantee that your security restrictions are in place before the user sees the home screen. The major drawback is that, once the users have completed the setup assistant, they have to wait for apps to be installed.

My current model is to push a very small number of apps to every device automatically once they complete enrolment. The risk here is that the network takes a massive hit on the first day of school when everyone completes the enrolment at the same time and those apps all begin to push.

Two techniques can mitigate this problem: firstly, use Caching Server in Mac OS X Server. This will save your external bandwidth but may still kill your internal WiFi for a while.

The second technique is to stagger the roll-out of apps. I'm deliberately keeping my auto-install list very minimal: iTunes U, Pages, Keynote, Google Drive. Just enough to get up and running on day one. The remainder of the apps will all be made available for optional install through Casper Suite's Self Service app. This way, the pupils can install the apps they need when they need them.

A slight downside to this technique is that, when a pupil (or class) finds they need a huge app like iMovie or GarageBand, the wait might be quite long. What I might do is add those two apps into the Auto-install list at some point after opening day.

Zero-touch Fully Configured Deployment

In any scenario where the end user doesn't have a lot of ability to configure the device, a Fully Configured deployment is appropriate. When might this be true? In schools, when you're dealing with younger users or users with additional learning needs. In other scenarios, when the user won't really "own" the device but just use specific apps - think public iOS kiosks, loaner devices at museums or other borrowed-use scenarios.

A fully-configured deployment is one where the devices are brought to the ready-to-use state by the sysadmin without the end user's involvement at all.

This scenario is relatively easy to implement. In most of these situations, the user does not need to have an Apple ID on the device and apps can be pushed directly to the device by MDM.

The sysadmin can use Apple Configurator to start the Device Enrolment Program running and then all that is required on each device is to complete whatever steps in the Setup Assistant are required for the scenario.

The one pane I still recommend everyone leave enabled is Location Services. The reason for this is that iOS uses location services to set its current time zone. If you block Location Services, the default time zone is US/Pacific and you can end up with incorrect clocks on your devices.

As with other scenarios, you can't actually get to literally zero-touch as you have to complete the setup assistant. However, you can get the rest done - apps and configuration profiles - over-the-air.

Conclusion

Are we at zero-touch deployment yet for iOS devices? Sort of.

We can do a zero-touch deployment if:

  • End users are able to complete a simplified setup assistant by themselves
  • Our network can handle the automatic app installations that happen when the devices complete setup
  • We don't need to ensure a specific version of iOS on the devices

Here's what I'm going to do for my deployment:

  • For the youngest users, who don't need an Apple ID, I will deliver a fully-configured device.
  • For all other users, I'll be delivering a partially-configured device

One of the main reasons for doing partial-configuration instead of zero-configuration is that, right now, we want to be sure that everyone is on at least iOS 9.3. I don't know what OS our devices will come with, but we rather depend on some of those features right now. In future years, this might not be such a concern.

The second reason I want to do partially-configured deployment is that I want to assign specific devices to specific users before handing them out. That way, I can set up asset tagging and so on before the users get their devices. In an Unconfigured deployment, you have to have some way of connecting a user with the device they have enrolled. Usually, you would do this by making the user log into their Active Directory account before they enrol in MDM. We don't have AD, so we have to do this step by hand.

We're not totally at literal zero-touch deployment yet for all scenarios but we are very, very close.

Decommissioning Day

So the school holidays are finally here and every sysadmin knows that that means you can start ripping things apart with total abandon. It's the happiest day of the year!

This year, I have a number of jobs to do since its refresh year. The first task is to decommission all of the old devices.

As part of the hand-in this year, I deliberately made sure all the pupils had turned off Find my iPad in order to disable the Activation Lock. This mostly worked and only a few still had it enabled.

Next, I decided to unsupervise them from Apple Configurator. I had a number of quite large USB hubs so I connected them all at once and plugged in about 30 iPads. Configurator (we are still on 1.8 at this point) promptly fell over.

So I unsupervised them in smaller batches until all were done. One of the big problems at this point is that you're working with old Lightning cables, some of which might not work perfectly. Lots of occasional random failures.

Anyway, I got that done and it proved that the entire set was no longer activation locked and were erased. I found a few devices that claimed to be supervised but Configurator could not see them. I think this dates back to the bugs we encountered in the iOS 7 transition where some devices lost their supervision identities, but I didn't keep a detailed record of that time so can't be sure.

As a result, I ended up forcibly restoring about six devices. No big deal.

El Capitan

Next step was to upgrade the Configurator machine from Yosemite and Configurator 1.8 to El Capitan and Configurator 2. At this point, several iPads were behind in their version of iOS. I left them that way because I figured that Configurator 2 might do a better job of upgrading multiple devices at once.

Unfortunately, at this point, the Mac decided to throw its disk. Cue a 2+ hour rebuilding process which was tedious but uneventful.

Fortunately, Configurator 2 was much better at handling multiple devices at once. I was then able to update 25 or so iPads at once without issue. Bradley and I have given Apple Configurator a hard time on the podcast over the years but AC2 is definitely much, much better than version 1.

New MDM

Next thing I did was set up a new MDM. We have used Casper Suite for years now and I consider it the single non-negotiable thing about my iPad deployment practice. I genuinely couldn't live without it.

Our previous Casper instance predates the release of VPP Managed Distribution in the UK so it had a lot of cruft in it about coupon codes and such. Between that and the rise of Apple School Manager, I decided that it was worth the effort to set up a new MDM.

We host our MDM on Amazon EC2, so it was easy to throw up a new virtual machine and install Casper.

In the old MDM, I revoked all the apps from all the users. The quickest way to do this is to delete your VPP token from Settings > Global Management > VPP Accounts. This automatically revokes every VPP license you have assigned.

I re-uploaded the new VPP token to the new MDM server and once it all synced up, I had all my app licenses in the new server.

App Deployment

In the early days of VPP, you had to assign each app to an individual Apple ID. Since iOS 9, you can assign to a device instead of a user. This seems to be a better approach for school 1:1 situations. In my research at school, I discovered that almost no pupils ever installed a school-provided app on a personal iOS device.

Device Assignment allows you to push an app directly to a device and pull it back at will. Apple ID assignment sometimes worked and sometimes didn't depending on various factors.

As a result, we are moving to device assignment for all student devices in the next deployment.

We are also switching to the Casper mobile app for access to self service. Previously, Casper's Self Service was a web clip. The native app, as well as being faster and more responsive also allows administrators to send push notifications to all or some iPads with the app installed.

Another thing we are doing this deployment is making more use of optional installs of apps. There are a certain set of apps we want to be everywhere all the time - iTunes U, Google Drive, Pages, Notability - and other apps that we have enough licenses for to make available to everyone but which everyone might not need. These second kinds of apps are going into Self Service and pupils can pull them onto their devices as required.

As we start to move towards Managed Apple IDs, we will be leaning more on optional installs through Self Service. This is because Managed Apple IDs cannot buy apps directly, so everything has to come through the MDM.

This actually provides an additional benefit in that you can deploy apps with any age rating. Previously, we had allowed students free access to the App Store, subject to a 12+ age rating. This posed a problem when certain apps we wanted to deploy were rated 17+, such as Amazon Workspaces. By the same token, there were some apps that we definitely didn't want that were rated below 12+ (Hi, Snapchat!) Now, with Device Assignment and Managed Apple IDs, we can deploy only the apps we want regardless of age rating.

Another question, though, is whether you even really need Managed Apple IDs. As far as I can see, you only really get two benefits from having a Managed Apple ID over just, well, not having an Apple ID at all.

Firstly, you can subscribe to iTunes U courses. This is obviously very important for secondary schools but much less important for primary schools.

Secondly, you get iCloud storage for backup and other uses. Right now, Managed Apple IDs are still limited to the same rather stingy 5GB that consumer Apple IDs are limited to. In a world where Google are throwing unlimited free storage at schools, this is starting to feel like a real pinch. In a Shared iPad world where you're expecting to be able to offload a student's entire data load to iCloud, I can't see how 5GB is sustainable.

Still, if you are not using Shared iPad and you have enough experience to know that catastrophic hardware failures are very rare, maybe you don't need iCloud storage.

Still, these are early days in our redeployment. There's definitely more work to do!

Thoughts on Swift Playgrounds

At WWDC 2016 Apple announced Swift Playgrounds for iOS. Swift Playgrounds is an app that is connected to a larger initiative from Apple called "Everyone Can Code".

Everyone Can Code comprises the Swift Playgrounds app itself, a series of teacher and student guide books on the iBookstore and a suite of curriculum content delivered inside the Swift Playgrounds app.

I've spend the past few days at WWDC getting up to speed on Playgrounds and here is my first-cut at understanding how it all fits together.

The App

Playgrounds is genuinely a full Swift interpreter built into an iPad app. Although the demo in the Keynote focused on some simple concepts, it's not a toy or limited version of the language.

The app is comprised of two parts: the source view on the left and the live view on the right. The source view is where you type your program and the live view is where you see any output. At the same time, in the right margin of the editor, you can see intermediate results as they are calculated. This has been part of Swift Playgrounds on macOS for some time.

The app supports two kinds of files. The first is the Playground file that you can create using Xcode on a Mac. These files can be transferred to the iPad and run as-is inside Playgrounds on iOS.

The second kind of file is called a Playground Book. This is what you saw in the keynote. It's much richer and supports a nested chapter and page structure that supports navigation as well as basic assessments of success inside each page. The package format is documented online.

There are also a range of things that authors can do with each page in a Playground Book to make it easier for beginning programmers to meet success. These include hiding setup code that doesn't need to be seen by the learner, defining "editable regions" to constrain the learner to only type in certain areas and providing hint text in those editable areas.

Another feature of the app is that it freely allows import and export of Playgrounds and Books to other users via AirDrop. In my teaching experience with beginner programming environments, being able to inspect and adapt someone else's code is a very good way to build learners' curiosity and confidence - as well as a bit of competitiveness!

The app also features certain other simplifying tools for entering code. There are colour pickers, image literals and other gestures that make it easier for learners to avoid syntax errors. One simple example is that you can drag out the lower brace of a conditional statement or loop to enclose other statements and everything springs into place when you let go.

The QuickType bar above the keyboard (the area where you get text suggestions) has also been adapted to give code completion suggestions that are sensitive to the context and only let you complete legal code in the language. Authors of Playground Books can also give hints to the suggestions mechanism to constrain it to only show certain symbols or only symbols from certain packages.

It's important - and not at all obvious on first sight - to understand that Playgrounds is not in itself an authoring environment for Playground Books. When a learner works with a Playground Book, their edits to the code in the book are stored as a diff against the original content in the book. The original content is never modified, but the diffs do get transferred with the book when it's sent to other users. The reason it's done this way is that it facilitates resetting a page in the book to its original state if the user needs to. You can also reset the entire book.

The other thing that is not entirely obvious is that Playgrounds has full access to the entire iOS API. This means that there is effectively no limit on the complexity of Playground that you can build. You can use APIs like Core Location, WebKit, MapKit, Core Motion, Networking and Core Bluetooth. One of the demos given in the session on Playgrounds was of Playground Swift code controlling a Sphero robot over Bluetooth. I already did the standard daft Browser-in-five-lines-of-code trick that we used to do on the Mac.

The Swift Language

A broader question than "is the app any good?" is whether or not the Swift language itself is any good for Computer Science education. I have in my career taught children to program in Visual Basic, Ruby and Most recently Python.

As a Computer Science teacher, I need to know that Swift is a good language for learning to program with. One simplistic approach to promoting Swift in CS is simply to make the argument that kids love smartphones and apps are written in Swift therefore CS education should happen in Swift. I get the thinking behind that but it feels as zeitgeisty as the other moves that teachers make to co-opt anything that kids like and turn it into "education". Remember Second Life? And .... dare I say it .... Minecraft In the fullness of time?

I prefer to ask which specific language features in Swift make the language a good choice for learners. I challenged Apple staff this week to make that case and I came away with some good points. One of the things I particularly liked was that Swift leans toward explicitness rather than implicit or inferred behaviours.

Swift also has API design guidelines focused on expressiveness and understandability rather than terseness. It's also a relatively new language. This certainly has its drawbacks in that the language has changed substantially over the last two major revisions but there is a consistency and clarity to its approach that is sometimes missing from languages like Python.

What's Not to Like?

Swift Playgrounds is a very new app on iOS. Although it's fairly complete, there are a few things I feel that it still needs.

Firstly, I mentioned that there are ways to get the Playgrounds app to render your code by omitting and hinting certain areas. There's currently no way to get that rendered view out of the app. This is important for teaching in two ways: firstly, it would allow students to submit work to a teacher through iTunes U. The second reason is that a teacher authoring a solution would be able to give a printout of a completed (rendered) version to a pupil who needed it for whatever reason - perhaps a pupil with learning difficulties for whom copying in a provided solution would represent a good achievement. Giving these pupils the full unrendered source would be overwhelming.

The bigger issue right now is that the authoring environment for Playground Books is Xcode on macOS. I'll invite you to use the fingers of maybe both hands to count the number of teachers in your area who (a) even have a Mac and (b) are au fait with Xcode.

I have seen many times that any time the phrase "you use a Mac for that" is a total and complete show-stopper in education. This was true for iTunes U before Course Manager came to iOS and it's still true for iBooks Author.

I think there might, in time, be ways to create Playgrounds and Playground Books on iOS but it will be neither easy nor convenient for some time to come. This isn't an unexpected problem but it is still a problem.

Overall, though, it's hard to find anything seriously bad to say about Swift Playgrounds except that it's an early, immature product right now. Despite that, it already has serious power under the hood and some impressive curriculum content. Can't wait to see where this goes.