Reflections on Deployment Day 2016

So it's now been a week since we rolled out our latest iteration of 1:1 iPad at Cedars. What does it look like and how did it go?

Deployment Design

My intention is always to do one three-year deployment, not three one-year deployments. My aim, which we achieved in the 2013 deployment, was that the iPads would go out and not come back to me until the end of the lease.

Our school is straight-through K-12, with a slight bias towards pupils in the Primary department. We decided on a split deployment this time - using iPad minis and 9.7" iPad Pros.

One interesting thing in the discussions about the device was that the name "iPad Pro" might have actually hindered the iPad a little. The idea of buying a "Pro" device for a five-year-old just seemed to absurd to fly when, in both previous deployments, we had purchased the lower-storage fastest iPad. First time round we had no choice, of course, but last time round we bought everyone a 32GB 9.7" iPad with Retina Display. This time, the younger kids got something smaller.

The devices are: 64GB iPad Mini 4 (31 units) and 32GB iPad Pro 9.7" (94 units). This leaves us 1 spare mini and 4 spare iPad Pros. That's 3-4% spare capacity, which is about right. We could probably get away with a bit less given our Mean Time To Repair (it's very quick with an Apple Store 25 minutes away), but it's good to have a couple of identical spares to test things like iOS 10, Shared iPad and so on.

We are deploying the minis to Primary 1-4 (US: K-3) and iPad Pro for everyone else. I have in the past expressed scepticism about the suitability of the iPad mini for younger users and their poorer fine motor skills. I had to abandon that opinion in the face of the weight of evidence that literally every child who had their own iPad had a mini and they were all getting on just fine with it.

We are again using Casper Suite for our MDM, hosted on Amazon EC2. We have been very happy with this product for a couple of years now and there was absolutely no compelling reason to change.

Deployment Changes from 2013-16

There are a number of new technologies coming together in the 2016 deployment that we have not used before.

Firstly, these are the first devices we have purchased since the Device Enrolment Program came to the UK. We are also switching to iOS 9's VPP device assignment from the older iOS 7-era user-assignment model for apps. The huge change of course is the migration to Managed Apple IDs - about which more later.

Migrating to a new MDM Instance

As part of the deployment, I decided to migrate everything to a new instance of Casper Suite. Doing this was remarkably easy and basically involved these steps:

  • Shut down our old EC2 instance
  • Set up a new EC2 instance and install Casper Suite
  • Reconnect the new MDM to DEP and VPP by uploading keys and tokens to the appropriate places.
  • Assigning our DEP devices to the new server and setting it as the default server for new devices.

The main downside to doing this is that we were 2 years into a 3 year reserved instance on EC2 and we couldn't make a new instance of the type that we reserved (m1.small). We are running our new JSS on a t2.small EC2 instance right now and monitoring that before we buy a new reserved instance. In general, I would like to get our EC2 reserved instances lined up with our deployment cadence.

Preparation before the Day

The preparatory stage went remarkably smoothly on the whole. Devices were delivered and it was the coolest thing to be able to see and work with them in DEP while they were still sitting in a TNT loading dock.

Once the devices arrived and were unboxed, the next steps were to:

  • Connect them 20 at a time to Apple Configurator
  • Restore the devices to the latest version of iOS (they all came with 9.3.2 and 9.3.3 was then-current).
  • Use Configurator to kick-start the DEP process.

The restore step is important. Configurator lets you update or restore. Recall that all iOS devices greater than 16GB come with a pre-installed set of apps from the App Store: iWork, iLife and iTunes U. These apps will of course be unmanaged when you get the devices into MDM. You can take them under management remotely but to do so you'd have to scope all those apps onto all those devices and then un-scope any you wanted gone. Easier, to my mind, to just press the other button in Configurator.

All of this preparation went fine, except we didn't have our iPad Pro cases yet. The 9.7" Pro is very similar to the iPad Air 2 but it's not the same and it's definitely not case-compatible. For one thing, there are four speakers on the Pro. Secondly, and more importantly, the iPad Pro is the first iPad with a flash. iPad Air cases partially occlude the flash, which would be a constant problem for indoor exposure metering in photography.

We had decided on the recommendation of many many schools to go with the STM Dux cases. The nomenclature for these cases is confusing when it comes to iPad Pro. The STM Dux case for non-Pro devices is a case with a rubber frame, plastic back and an integrated wraparound cover. The "Dux" for iPad Pro is basically that case without the cover - obviously to allow access to the Smart Connector. We wanted a wraparound case for all our devices. This, for iPads Pro, is called the "Dux Plus".

Still, we got the cases in time and it's all good. The cases seem very robust so far and have a very clever clear plastic panel over the back. Some class teachers have put labels under there to identify individual kids' iPads and they won't wear or peel off.

Rollout Day

We rolled out class by class. We ran into a couple of issues where we jammed the wifi by - maybe - associating too many devices in a short period.

Managed Apple ID Process

Let's just say that the idea of having to use a Managed Apple ID was ... not warmly welcomed by pupils used to free access to the App Store. It wasn't my decision to migrate everyone to a Managed ID, but I had to because of the limitations Apple has placed on iTunes U and Managed IDs.

As a result of this forced migration, a few issues arose. Firstly, I feel that the deployment lost a certain amount of enthusiasm amongst the older students who have had (mostly) free rein up to now. As a result, I'm deploying a range of 'lifestyle' apps for those kids to soften the blow.

Similarly, a few pupils had purchased apps in their school Apple IDs and now have no way back to using those apps on their school devices. Also, some pupils had depended on their iCloud Document syncing in Pages and Keynote instead of backing up to Google Drive. That can be recovered through iCloud.com on a desktop computer but...who has desktop computers any more? ;-)

The setup process as designed in our DEP pre-stage was:

  1. Enter personal wifi password (school-set)
  2. Enable Location Services
  3. Enter Apple ID & Temporary Password
  4. Chance Temporary password (requires entering temp password again, then school password twice)
  5. Accept TrueTone display page
  6. Get to home screen
  7. Enter password for iPad passcode
  8. Confirm password for iPad passcode
  9. Enter password for Google Apps account

I could have controlled the last two steps by not pushing the profiles until later but that would have required interacting with the JSS console in front of the class, which I really didn't want to have to do.

Younger and less-able children were very, very confused by the process of resetting their password. The terms "Current", "New" and "Verify" were too terse to fully explain what they were expected to do.

The "set passcode" prompt and the "Google apps" password prompt were in a race condition so some pupils saw one appearing first then another overtaking it. This led to confusion because I had started explaining a step and then some pupils were presented with dialogs for a separate step.

Basically, this was just too much passwording. Enter the school-provided password five times and the temporary Apple ID password twice (and twice in two screens at that!). This would have been much better if we could have set the final password in Apple School Manager and not required a reset of the password as part of the login.

App Installation

Once pupils had completed the setup, the devices needed a 'kick' in JSS to get them going. I'm not sure why. If I manually prompted the devices to update inventory, apps started getting installed. All devices had pending installations as they had been sitting in setup assistant for about 3 weeks. I didn't have to clear them manually, and probably the apps would have installed next time the devices uploaded inventory (within the next 24h). Unfortunately I needed action to happen in the class basically as soon as Setup Assistant was completed. It would be ideal if the device could signal the MDM "I'm ready now" - which I don't think it can.

App installations proceeded smoothly from there. Caching server worked wonderfully well and we barely touched the Internet the whole day.

I noticed that when a number of apps were being installed, no visual feedback was given on the home screen. The network activity spinner was active but no darkened icons were shown on screen. The apps just appeared once they had been downloaded and installed. Children, who are well used to the App Store, found this confusing and disconcerting.

Overall, though, I have been pretty pleased with the deployment. The network, MDM and caching server all performed very well for Day One.

Caching Server stats from launch day. 

Caching Server stats from launch day. 

The Problem with Managed Apple IDs and iTunes U

As I write this, we are five days away from teachers coming back to school and eight days from pupils coming back.

And I have found a showstopper problem with Managed Apple IDs and iTunes U.

Please bear with me as the explanation will be slightly complex but it is essential to understand its impact if you are rolling out Managed Apple ID and rely on iTunes U.

Background

Briefly, a Managed Apple ID is an Apple ID that is created by the school for pupils. They can also be created for teachers and administrators. A Managed Apple ID allows access to iCloud and iTunes U but not to commercial services like the App Store and iBookstore. A Managed Apple ID is literally disbarred from any commercial transaction with Apple.

Contrast that with a 'consumer' Apple ID - the kind that every iOS user creates either through iTunes or through on-device setup when they buy an iPhone. These Apple IDs have no restrictions.

In our deployment, as in many others, teachers use their own personal Apple IDs on the iPads they use in school. This is obviously true - there has only ever been one kind of Apple ID and every teacher using an iPad must be using a 'consumer' Apple ID.

Since iTunes U 3.0 came out, teachers have been using these personal Apple IDs to create iTunes U courses for our pupils. The reason they were using personal Apple IDs is that the iTunes U app on iOS uses the Apple ID that is logged into the "iTunes and App Store" section of iOS Settings as the Apple ID for the teacher. There is no way to have a separate Apple ID just logged into iTunes U. Remember that fact; it will become important later on in this story.

Managed Apple ID

Once we were migrated to Apple School Manager, the first thing I tested was:

  • Create a Managed Apple ID for a fake student
  • Set up an iPad with that Managed Apple ID
  • Test enrolling in an iTunes U course that I created last year

Immediately I hit a problem. An error message stated:

"Your Apple ID can only enrol in courses from your institution."

I was confused by this because my courses are from my institution. Our school has an iTunes U site and all my courses are set to be from "Cedars School of Excellence". There is a menu in Course Settings where an instructor can choose which institution their course is associated with.

After some more messing around, I realised that what this error message actually means is this:

Students with Managed Apple IDs from a particular school's Apple School Manager domain can only enrol in courses that are owned by an Apple ID that is also from that same Apple School Manager domain.

I verified this by creating a new Managed Apple ID for myself, sharing a copy of my course to that Apple ID and then enrolling my fake student Apple ID in that course. This worked perfectly.

Consequences

So, as a result of this decision to only allow iTunes U interaction between Managed Apple IDs in the same ASM domain, this means that teachers effectively have to be using a school-issued Managed Apple ID to run their iTunes U courses.

This is fine - in a very restricted set of circumstances that don't apply to any existing school iOS deployment anywhere.

Firstly, every currently practicing iOS teacher will be using a consumer Apple ID. Very likely it will be their personal Apple ID. This is because this was exactly the deployment scenario that Apple has encouraged us to use since iOS 7: users bring a personal Apple ID and the school or business uses VPP Managed Distribution to assign apps to that Apple ID.

Secondly, because iTunes U does not have its own Apple ID login system but instead uses the iTunes and App Store setting on the device, there is no possibility of using a separate Managed Apple ID "just for iTunes U". Signing into a Managed Apple ID on an iPad to make iTunes U happy will mean that teachers have to switch Apple IDs to buy any app, buy an In-App Purchase or download any past content purchase in iTunes, iBooks or the App Store.

This is obviously a massive speed bump in the teacher's iPad experience. Worse, though, there are various vaguely-documented tripwires in the App Store that can lock a device into a specific Apple ID for 90 days:

"Computers and devices can be associated with a different Apple ID once every 90 days."

- View and remove associated devices in iTunes, Apple

It is not at all clear whether Managed Apple IDs are also subject to these restrictions. These tripwires are set server-side and it is far from certain that you could depend on their criteria not to change during the course of a deployment. I mean, what does it look like when the App Store sees the same iPad signing into and out of Apple IDs on a daily basis?

If teachers are expected to flip between two Apple IDs on their iPad - which they will probably be doing on a daily basis, if not hourly - what happens if (when?) the iPad gets stuck for 90 days on one or other Apple ID? Either the teacher is locked out of their courses for 90 days or they can't buy or download any apps for 90 days. I'm not an Apple Music subscriber, but some teachers somewhere surely are, and I'm told that Apple Music gets weird when you switch Apple IDs.

Workarounds

At the moment, I have no satisfactory workaround for this. I cannot conceivably expect teachers to switch to using a Managed Apple ID permanently, abandoning all their past purchases and content. Similarly, the idea of switching between two Apple IDs in the course of doing your job is maddening at best and potentially disastrous if you accidentally trigger an App Store tripwire.

The only workaround that I can live with right now is to just not use Managed Apple IDs for students. Fortunately, most of the pupils moving up to our secondary department already have a device-generic Apple ID that I can convert into their own Apple ID. It's just the new pupils that I have to worry about.

At the moment, Apple is checking whether the Apple IDs of both teacher and student are in the same Apple School Manager domain. To me, this is the wrong criteria. The check should be: is the student's Apple ID from the same institution as the course's Institution?

It should not matter whether the teacher's Apple ID is institutional or personal - if the teacher has the right to make courses for that institution, they should be able to enrol that institution's students in that course.

I speculate that the Apple School Manager database and the iTunes U course database are simply not integrated. Whichever part of the system that is performing this check doesn't know that the "Cedars School" in our iTunes U courses is the same "Cedars School" as in our Apple School Manager domain.

I don't know the exact technical and legal reasons why this decision was made. All I know is that this new system of Managed Apple IDs is currently undeployable for any existing iOS site. The problem is not actually a student problem; it's a problem for the teacher's user experience.

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.