The Refresh - Day One

Our new set of iPads rolled in today. We have gone with 4th Generation 9.7" iPad, WiFi and, this time, 32GB. What follows is a story about opening boxes.

In the UK, iPads ship in what is basically the same boxes they ship to the Apple Store in: a shipping carton, containing a smaller carton held in a spacer inside which are five iPads in shrink-wrapped retail boxes. Once you get rid of the brown cardboard, you're holding the exact same thing you'd get in a plastic bag from the Apple Store.

Today, we spent the entire day unpacking, breaking down the shipping boxes and getting the devices into their cases.

Sidebar: The Case

There are basically only three kinds of iPad case:

  • The Folio style, which folds into a typing stand similar to the original Apple case.
  • The Kickstand-style, which props the iPad against ridges on the inside front of the case.
  • The Milspec-style, which turns the iPad into a colossal Triganic Ningi of plastic and rubber with all the ergonomics of Batman's toilet seat.

We ended up going with the Belkin Cinema Stripe Folio (, This case is unusual in that it can be used in either a kickstand mode or as a folio-style typing stand. It also protects the corners and has a very reasonable price.

Taking Inventory

The outer shipping cartons have a sticker and barcode that shows the serial numbers of the five iPads contained within. The first step, therefore, was to capture the serial numbers of all the devices.

My terror at this point in the operation is somehow getting confused between all the devices and ending up not knowing what is where, so I decided to try and keep it manageable.

First, I labelled each of the 22 boxes with a letter A through V. Next I built a simple spreadsheet that had A through V in column A, each spaced out by four intervening cells. Then I used the barcode scanner I bought for the job ( to fill column B with the serials.

So far so good. Now we have groups of five serials in a spreadsheet. For a bigger deployment, your reseller might do this for you but I knew it wouldn't take too long with a scanner in hand.


The next job was to separate everything out without mixing everything up. Each of us took a box and 5 cases and followed this procedure:

  • Unpack the 5 retail boxes and keep the outer shipping container marked with the letter.
  • Unwrap the iPad and put it in its case.
  • Assemble the charger and drop it in a communal box.
  • Drop the cable - still wrapped - in a communal box.
  • Throw out the in-box documentation.
  • Stack the iPad in its case, with the base of the retail box (and, hence, the serial number of the device) back in the shipping container.
  • Stack the retail box-top in the corner for later reassembly.

Now, we have the same 5 iPads, in cases, back in the boxes they came from.


I wanted to put a barcode somewhere on the case of each device for later ease of troubleshooting and lookup if we ever need to. I used my list of codes and an app called Code128Encoder to generate PNG barcode files, then printed one sheet for each box.

Each person then took a box, trimmed the barcodes and passed the device, the serial number barcode and the lower-box to me. I double-checked that the barcode matched the lower-box and then stuck the barcode into the inside of the case.

At this point, every device is in its case and its serial number is stuck into the back of the case with a barcode. We can now discard the shipping boxes entirely.

Turn-on Test

We'll do more testing tomorrow but the last job for today was to simply ensure that each device booted up to the setup assistant. We finished that job and found no DOA devices.

Time Taken

There were five of us working today. Here are some rough timings for the day:

  • 11am: Start opening boxes
  • 1300: All iPads in cases, stacked in their shipping boxes, without barcodes
  • 1300-1345: Lunch
  • 1530: All iPads in cases, with barcodes, sorted into class groups.

So nearly 19 person-hours of work for 110 iPads, working out at about 10 minutes of physical prep per iPad.

iOS 7 Education Wish List

I wrote recently about my iOS 7 "power user" wish list. Those were not education-specific but borne out of experience trying to push how much I use iOS personally.

Here are some additions that I think would be incredibly helpful for education specifically. For almost all iOS users in 1:1 schools, I would say the 'power user' enhancements would be highly beneficial too.

Master Passcodes

We can enforce a passcode on the device but for basic classroom management - particularly in the earlier years - the teacher needs to know the passcode. This leads to (a) lists of passcodes being kept and passed around by teachers and (b) policies against regular changing of passcodes.

An alternative approach would be to allow a master passcode on the device. I mean by this that each device would have two pass codes that would unlock it: one set by the user and regularly changed and another set by the administrator (possibly only by Configuration Profile) and known to staff.

Screen Brightness Limits

One of the main causes of battery problems in schools is children cranking their iPad up to maximum screen brightness and leaving it there. In almost all cases, this is not necessary and it would be helpful if administrators could limit the brightness to, say, 60% of maximum to preserve battery.

Expanded MDM Inventory

In a personalised 1:1 model, it would be helpful to know a bit more about the state of the device through MDM.

For example:

  • Is Find My iPad on?
  • Date of last iCloud Backup
  • Currently running app

It might also be useful to be able to enforce some of these things in the same manner as passcode requirements can be enforced by configuration.

App Blacklisting

In personalised 1:1s, students have the right to install their own apps on the device. Typically, we control what they can install by enforcing an age-appropriate rating by configuration. However, sometimes there are apps that are within the age rating that you don't want people to install.

For example, say you don't want people installing Netflix or Snapchat on school devices. These apps are rated 12+, which is within the rating we would allow for personal users, but we can't block those apps specifically.

If it were possible to deliver an "app blacklist" Configuration to a device, we could do this quite easily. Right now, we depend on the alerting capabilities of our MDM system to let us know who has installed certain apps.

Arbitrary Grace Period for Passcode Lock

Right now, the choices for passcode locking are 1, 5, 15 minutes, 1 hour or 4 hours. I think 15 minutes is too short and 1 hour is too long. Let us set custom durations.

MDM-based recall of apps and books

This is the big one: scaling Apple Configurator's deploy-and-recall capabilities for apps to large deployments. Being able to get licenses back is important in many schools but bringing the devices back to Apple Configurator is costly in terms of staff effort.

MDM servers can currently distribute VPP codes quite effectively but there is no recall capability. The codes, once redeemed, are gone. Changing this would go a long way to making deployments even more scalable.

MDM App Install on Institutional Devices

Currently, when you push apps to a supervised device, the user has to enter an Apple ID and password on the device. This is fine for personally-managed devices but, for institutionally managed devices, you don't normally give the end-user the Apple ID and password. As a result we have to split our app management between Apple Configurator for institutional model devices and MDM-push installs for personal model devices.

It would be ideal if we could unify this into our MDM server without having to give the users the Apple ID password.

Control over OS Updates

iOS 5's over-the-air OS updating has been a great thing. However, it would be valuable to allow administrators to control when the updates happen. I imagine this taking the form of two new MDM capabilities:

  • Be able to turn on Software Update on the device
  • Push a command that updates the OS

With the former, it would allow administrators to 'hold back' an OS update until some testing had been done or, at least, research on how to support the users through the transition. The latter would allow admins to remotely start software update for devices.

Force the user's name or device name to appear on the lock screen

When you have 20 or 30 iPads, all in the same case, it's handy to have a way to distinguish them. Labels on the cases only last so long (i.e. not very long at all) so another way to distinguish them would be desirable.

Apple Configurator allows you to specify a photo for the lock screen and either the user's name or the device name. This works but the implementation is flawed. What Apple Configurator is doing is rendering the name on a PNG and setting it as the lock screen image.

This means that, if the user changes their lock screen, the user/device name information is lost. Unfortunately, the first thing most kids do is customise their lock screen! If the OS could display the device name on the lock screen over the top of an arbitrary lock screen image, this would really help identification.

Additionally, if there were an "admin mode" that would also display QR codes of the various device identifiers (Serial, UDID, WiFi MAC) on the lock screen, that would be great for inventory.

Lower Case Keyboard

This one's for the younger users. iPad's software keyboard shows capitals on the keys but younger users typically don't learn capital letters right away. If a version of the keyboard with lower-case characters were available that would help a lot.

These are just some ideas that come up from a few years' experience in using iPads in an educational setting.

The Butcher's Bill

So we are coming up on three years with the iPad 1. I thought it would be interesting to look back at our damage rate and see how things went.

I've kept a log of when devices were replaced and why. These numbers are based on a deployment of 115 iPads and all the repairs were handled through the Genius Bar at our local Apple Store.

1 Sep 2010: Dead Digitiser

A pupil reported that her iPad was not responding to touches in one area of the screen. I checked and there did appear to be a ‘dead band’ the width of the screen about one fifth of the way up where drags across the affected area would not be recognised. The iPad acted as if the user had lifted their finger from the screen.

8 Sep 2010: LCD Failure

Our Primary 4 teacher reported that one boy's iPad had developed rainbow stripes across the screen. No evidence of any physical damage to the device.

1 Nov 2010: LCD Failure

Another pupil's iPad is displaying similar video issues to the above.

16 Nov 2010: Home Button

An iPad is exhibiting a sticky home button. Clicks are not always registering.

22 Nov 2010: Broken Headphone Jack

A Primary 1 pupil accidentally broke off a headphone jack in the socket. As a result, the iPad thought there were headphones plugged in and would not play any sound. Neither I nor the Genius Bar could extract it, so the device had to be replaced.

23 Aug 2011: 4x4 Farrago

An iPad was destroyed by accidentally being run over by a 4x4.

23 Aug 2011: USB Failure

An unassigned device that had been stored over the summer was unable to be recovered from DFU mode, consistently showing error -1604 in iTunes.

29 Aug 2011: Cracked Screen

An iPad developed a crack in the lower corner of the screen due to being stacked horizontally under too many other iPads.

10 Nov 2011: USB Failure

An iPad stopped responding to cables being plugged in. Reboot or DFU failed to fix.

11 Jan 2012: Drop Damage

A pupil dropped her iPad right on the power switch. The aluminium case was dented and is mechanically interfering with the operation of the sleep/wake button.

27 Apr 2012: LCD Failure

A pupil's iPad developed black and flashing lines on the screen.

1 Sep 2012: Cracked Screen

An iPad had a cracked screen.

2 May 2013: Sleep Button

A pupil's iPad had a depressed sleep/wake button, making it difficult to turn the device on and off.

2 May 2013: Sleep Button

Another iPad developed a bad sleep/wake button.


  • 3 LCD failures
  • 2 sleep/wake button failures
  • 2 connector failures
  • 2 cracked screens
  • 1 digitiser failure
  • 1 case damage
  • 1 home button failure
  • 1 headphone jack
  • 1 bad interaction with a motor vehicle

So, over the course of three years, a total of 14 devices have been replaced. That works out at as an overall replacement rate of 4% per year.

Of these devices, half were for what we might call failures - damage not resulting from user action - and the other half were damage. Interestingly, our battery failure rate remains at a steady 0%.

I'm no mechanical engineer, so I can only guess at reasons why we may be seeing such a low damage rate. For one thing, I'd say that the iPad 1 is very robustly built. It doesn't have such a sharp edge as the iPad 2-style case, which can be vulnerable when the device is dropped.

The second thing I think contributed to our low damage rate was the fact that we have carpet in almost every classroom of the school except the science lab.

Another factor is that there just isn't that much to go wrong. A laptop has a complex hinge, more than 100 switches on the keyboard, a moving hard drive, a fragile power socket. The iPad has four switches, a charging socket and solid state storage. The 30-pin connector has proven reasonably robust but I expect the Lightning connector will be even more reliable.

Finally, I also believe that being 1:1, and building a culture of responsibility around that, makes a massive difference to the way pupils treat computers. When your name is on it, when your data is on that device and when its damage or loss will directly impact you, you tend to take good care of it.

iPad Disaster Recovery in Institutional Model Deployments

I've been working intensely on the deployment models for our iPad refresh in August. Our current deployment model dates back to 2010 and a time before Apple Configurator, Volume Purchase and MDM. Back then, we had to make do with iTunes and iPhone Configuration Utility and we liked it!

One of the things I've been trying to understand is how to handle disaster-recovery procedures in cases where a device has to be replaced. I cannot overstate how important this is in a 1:1 scenario. When constant iPad use becomes embedded in the culture of your school, as it has in ours, the problem of not having access to your device takes on a much greater significance.

Apple defines three models of iOS deployment: Personal, Institutional and Layered. For more on these models, see Apple's "iOS Deployment Model" videos. I want talk here about disaster recovery procedures for Institutional Model iPads.

Apple Configurator in Institutional Model Deployments

In an Institutional deployment, you use Apple Configurator as a complete replacement - in principle, at least - for both iTunes and iPhone Configuration Utility. Configurator is used to activate the device, install Configuration Profiles and install apps. Configurator can also back up a device. Typically, in Institutional deployments, devices will be put into Supervised mode such that they cannot sync with another computer.

The Problem of Backup with Apple Configurator

Apple Configurator's backup function is different to doing device backups in iTunes. iTunes maintains one backup per device, incrementally updating and overwriting the previous backup at each sync.

Apple Configurator's approach to backup is not "incrementally update this backup set" but rather "make a complete clone of this device". Both approaches have their uses.

The problem with making routine backups in Apple Configurator is two-fold:

  • It clutters up the backup list in Apple Configurator since every backup is distinct from every other backup. You have to version them by hand; perhaps by prepending the date to the device name.
  • It eats disk space on your Configurator machine every time you back up.

This is fine if the device you're dealing with is broken but operational. It's not so good for quickly taking routine backups as part of ongoing device maintenance. As best as I can tell, Configurator will at least duplicate the last backup and incrementally update that backup set, so it's not quite as slow as you might imagine but still not that great.

The key insight here is that, although a supervised iOS device cannot sync with iTunes on another computer, it can sync with iTunes on the supervising computer.

Here is my approach to ongoing backup maintenance of Institutional iOS devices.

Routine Backups

In an Instututional Model using Apple Configurator, devices are typically periodically returned to base for app updates, new apps and Configuration Profile adjustments.

As part of routine maintenance, a backup should be taken in iTunes and periodically incrementally updated. This ensures that you have a recent device backup in case of disaster involving device loss or damage that renders the device inoperable.

To do this, make sure Apple Configurator is not running, then connect the device, right-click on it in the iTunes source list and choose "Back Up...".

This will create a backup of the device that you can fall back on if the worst happens: a device is lost, stolen or damaged beyond usability.

Disaster Recovery Procedure for Institutional Devices

Assuming regular backups have been taken in iTunes, the following steps can be followed to restore a user's data to another institutionally-managed device.

  • If the damaged device is bootable, connect it to iTunes and update your last backup, then quit iTunes
  • If the damaged device is not bootable, fall back on your last backup of the device.
  • Connect new device to Apple Configurator
  • Supervise and name the device
  • Select "Don't Restore Backup" from the "Restore" popup
  • Install apps and configuration profiles
  • Quit Apple Configurator
  • Launch iTunes
  • In iTunes, restore the device from the last backup of the broken device

That last step is the only thing you should do with iTunes to restore. Don't turn on app sync or any other sync configuration from iTunes - leave all of that to Apple Configurator.

Once the new device has been restored and verified, you should:

  • Reconnect the broken device to Configurator
  • Unsupervise the device to recover your VPP licenses and erase all data from the device

Note that, in following this procedure, you'll need an extra VPP license for each app. If you only have N licenses, where N is the number of devices you've deployed, you'll need to unsupervise the broken device before supervising the replacement. I would be cautious about that since you'll also be destroying the data on the damaged device before you've restored and verified that your last backup was good.

Another reason why it's good to own a few extra licenses for your apps is that, in situations where Apple Configurator cannot un-install the apps from the device, you will not be able to recover your license. You will also have to forcibly remove the device record from Apple Configurator by holding down Option while choosing Devices > Unsupervise... (which becomes "Remove" when Option is held down).

Remember that the procedures detailed here are for Institutional Model deployments. The procedure for Personal Model deployments is different.