What's new in Apple Classroom 2.0

With iOS 10.3, Apple have released Apple Classroom 2.0. Apple Classroom first shipped alongside iOS 9.3 and provided tools to help teachers in an iPad-based classroom.

Apple Classroom provides a range of features including observing student screens, launching apps and URLs and locking student devices.

In the initial release of Apple Classroom, the way that the system worked was that your school Mobile Device Management server had to create and send an "education payload" to teacher and student devices. This payload included information about which users are teachers and students, and which teachers teach which classes and so on. This also prevented students from downloading and using Classroom to control other students' devices.

This made it very easy for teachers in such schools to just pick up and use Classroom. Unfortunately, it made the job rather difficult for school administrators and MDM vendors. So difficult, in fact, that most MDM vendors simply have not shipped support for Apple Classroom. As a result, very few schools are using Apple Classroom to its full extent.

Apple Classroom 2.0 goes a long way to fixing most of these issues.

Infrastructure Changes

Previously, the infrastructure requirements for Apple Classroom were reasonably high. You needed an MDM server that supported the Apple Education payload and student devices had to be supervised. Essentially, that describes a managed school deployment.

Apple Classroom 2.0 can now work without any of these requirements being met, albeit subject to a range of privacy limitations.

At its most basic, now, anyone can download the Apple Classroom app from the App Store and set up an ad-hoc class. However, the degree of control is limited because of privacy concerns. In Apple's terminology, these ad-hoc classes are called "unmanaged classes" and the MDM-provided classes are called "managed classes".

When a 'teacher' creates an unmanaged class, the class availability is broadcast via bluetooth. A new Classroom section appears in Settings where students can see available classes and join them. There is then a code-based confirmation step, as in many such enrolment systems, and then the 'students' are now in class.

The nice thing about this is that only the teacher device needs to have Apple Classroom installed. The client-side software is built into iOS 10.3 so, as long as all devices are up to date, there is no need to coordinate everyone getting the app installed before you can get to work.

Unmanaged classes, once created, are persistent and by default students will automatically re-join classes when the teacher opens the class in their Classroom app. This can be changed in Settings so that students have to be prompted to join the class before a teacher can control the device. Students can also un-enroll from classes at any time.

As unmanaged classes can be created on any device, the 'student' devices have a lot more control over their visibility and privacy than do students in managed classes provided by a school. In the first place, students can simply not enrol in the class. Secondly, the student has control over two privacy settings: "Lock Apps and Device" and "AirPlay and View Screen". These are two settings, each of which control two features.

Each of these settings has three possible values: Ask, Always and Never. The default for both is Ask. When a teacher tries to lock a device or view a screen, the student sees a permission dialog where they can "Allow" once or "Always Allow".

In a situation where a school has devices supervised in MDM but their MDM does not support creating Managed Classes, there is a restriction that removes students' control over these two settings so that they cannot refuse locking or screen viewing. This is only applicable to supervised devices, so that generally implies institutional control.

It's also worth mentioning that managed classes and unmanaged classes are mutually exclusive. You can't mix and match. If a teacher device has an Apple Education payload installed by MDM, it will not be able to create any unmanaged classes. Similarly, if a student device has an Education payload, it will not be able to join unmanaged classes. Under iOS 10.3, a student in a managed class can look in the Classroom settings, see which classes they are in and see which teachers have access to that class. The privacy controls for locking and screen viewing are hidden in this scenario.

Teachers in BYOD schools where the iOS deployment is not managed in any meaningful way might wonder whether the more general availability of Apple Classroom presents any kind of security or privacy problem for teachers if students were to come into school with Classroom installed on their devices.

Honestly, I don’t think so. In order to exercise control over another iOS device, the ‘teacher’ device has to create a class. The owner of the ‘student’ device then has to:

  • Unlock the device
  • Go to Settings > Classroom
  • Tap on the class name
  • Enter a code that’s only displayed on the ‘teacher’ device
  • Be accepted into the class by the ‘teacher’ device

That’s a pretty difficult process to go through accidentally.

The other question is about students creating their own unmanaged classes to control other students’ devices. Again, this would require the setup steps mentioned above and students can always delete any unmanaged class that is causing them difficulty. If your school has Apple Classroom support in MDM, turning it on prevents any problems.

Teacher Features

The major focus of Apple Classroom 2.0 is the loosening of these infrastructure requirements. The update also brings a few new features for teachers.

Firstly, the class list has been redesigned. This now allows you to reorder the classes and is a much more compact representation than the simple screen-wide table view of Classroom that was in Classroom 1.x.

The single new feature in the class view is the addition of a button that will immediately mute all the devices in the class. I'm sure this will be a welcome addition for many teachers! This is simply an action that sets the volume once but doesn't lock it.

The bigger feature in Classroom 2.0 is the enhancement to AirDrop. Classroom 1.x had a Share Sheet extension that allowed you to share URLs from Safari to your class. Classroom 2.0 takes this idea and supercharges it.

Classroom 2.0 has the idea of the "current class". That is, the class that you currently have open in Apple Classroom. This is why the "Close" button in Classroom has changed to "End Class".

While you have a class open, the system-wide Share Sheet gets a new trick. The current class, as well as any sub-groups that you have defined, appear as AirDrop targets at the top of the sheet.

What this means is that teachers can now share a URL, photo, video or any file, to the entire class in one tap. This far exceeds the capabilities of the old Classroom Share Sheet extension that only allowed sending URLs to students. Now, anything that can be AirDropped can be sent to the entire class in one go.

Between Classroom 2.0, recent enhancements to Swift Playgrounds and the new "education edition" 9.7" iPad, someone at Apple is clearly listening to the needs of education.

Using Amazon Workspaces for Legacy Software

One of the courses we teach in school is Administration and IT. This is a Business Studies course that covers many of the regular office (and Office) skills that students might need in the future.

The course doesn't explicitly require that you use Windows Office but in practice it does. The exams are set by people who use Windows and the exams are marked by people who expect to see the output of Microsoft Office....so.

So I had the problem of having to somehow provide a Windows environment to our iOS devices. There's no way I'm buying and maintaining a legacy Windows lab for this course, so what to do?

There's also no way I'm getting into enterprise software land with services like Citrix. It's one of my basic rules that if the price isn't on the website, it's unlikely to be a price I'm happy to pay.

Enter Amazon Workspaces.

Amazon Workspaces is basically a virtualised Windows environment that you can connect to from iOS, Mac, etc. Best of all, you just click a button and you get a service - no salesmen involved.

We also have an Office 365 service set up for pupils taking this class. We don't have a general Microsoft license, so we're paying about £1.15 per pupil per month for this.

One of the things with all of Amazon Web Services is that you need to understand both the technical aspect and the pricing model - and you really, really, have to understand your own usage model.

For us, we use the VMs during class and rarely outside of class. For the Higher class, that's 5 hours per week. For the lower-level classes, it's 2 hours per week. It's quite a minimal amount of usage, so you can understand my reluctance to commit a lot of capital to this.

Workspaces has two pricing models: monthly and hourly. For the basic "Value" bundle, which is all we need, the monthly price is $27/month. The hourly pricing model for WorkSpaces is a basic $8/user/month to have the VM set up and then it's $0.23 per hour that the workspace is active.

So you can see that for us, where our usage is quite sparse across a week, the hourly pricing is a huge win.

WorkSpaces also provides a bundle where you can get Office 2013 built into the bundle and set up. What I didn't understand going into this, though, is that there is additional pricing for having Office installed in the bundle. That extra is $15/bundle/month. Considering we were already paying for Office 365, this was a huge waste of money.

My first deployment model was to put out the pre built Amazon "Value Plus" bundle. That was very easy to do but adding on an additional $15/user/month was too expensive. I didn't realise this until the first bill came in but once I did, it was time to make a change!

As part of the rebuild, I decided to create a custom image to create the student images from. I simply followed the tutorial steps and built a bundle that included the Google Drive sync app, Google Chrome, Office 2016 and Acrobat DC. I had previously led pupils through building their own setups but, as the number of pupils has increased, this is increasingly impractical.

Once I created these images for each student, all the student had to do was sign into Google Drive and sign into their Office 365 account.

Additionally, I tagged each instance with a tag named "class", so that I could identify the images associated with each class group. Essentially, the script enumerates all the workspaces with a specific tag and then sends them a start or stop command, depending on the parameters sent to the script.

Imaging

None of the pre-built Amazon images are ideal for what we want. In particular, we wanted to have Google Drive, Chrome, Acrobat Reader and the latest version of Office installed.

So I followed a fairly simple tutorial to create a custom bundle for our students that included those packages. All the student had to do to make a bundle work for them was to sign into Google Drive and Office and they're ready to go.

This custom image should also make it easier to delete and recreate the workspaces. To save money, I will endeavor to find some months in the school year where we don't need to have those Workspaces in operation and delete and recreate them. I haven't done that yet, but it's more of an option now that setup is much faster.

Scheduling

This is where things start to get fun. When a user tries to connect to a stopped instance, the instance will automatically start but this can take up to 5 minutes. This ain't exactly what you want when trying to get a class started, so I decided to try and figure out a different way to do it.

First, I wrote a python script that would start or stop each class group of workspaces on demand. This script lived on a unix machine we have in school. That was helpful - as long as I remembered to run it before class.

Of course I rarely remembered to run it before class. Remembering to do things is a computer's job, so let's get the computer to do it.

AWS provides a service called Lambda. Lambda allows you to run a Python script in the cloud without having to worry about anything to do with the server or the underlying operating system. It's basically "scripts in the cloud" and very helpful for small self-contained scripts like this script that starts and stops groups of Workspaces.

So I wrote this script and set it up as an AWS Lambda script. The question then was how to schedule it to run. Turns out, AWS has another tool for that: CloudWatch.

Cloudwatch is the monitoring and logging component of AWS. In general, the primary use case for CloudWatch is to monitor your AWS workloads and take action. For example, if your response times are getting long, CloudWatch would notice and run a Lambda script to spin up more servers.

CloudWatch also contains an option to execute Lambda functions on a schedule. There are options for running them on set frequencies (once every X minutes) or on a Cron schedule. This latter option is perfect for my application.

I didn't want to write different scripts for each class group or for starting and stopping workspaces. Instead, these needed to be arguments passed to the script. CloudWatch scheduled rules allow you to send parameters to a Lambda function in the form of a JSON dictionary.

So I set up each rule to spin up the Workspaces 20 minutes before the class starts and stop them 10 minutes after it ends. This was a bit of a hassle, as it requires two rules to be scheduled for each period - one to start the servers and another to stop. Still, at least it was only a matter of changing the Cron expression and the parameters sent to the Lambda function.

The only major wrinkle here was that CloudWatch scheduled rules always run on UTC and there's no way to express a local time zone. This is a pain as I now have to both adjust all of my CloudWatch triggers when the UK reverts from BST to GMT and, worse, remember to do it.

So, in summary, the chain of events goes like this: CloudWatch executes on a Cron schedule to run a Lambda function which causes AWS Workspaces to start or stop.

A Lockout Protocol for iOS 9.3

One of the things I want to be able to do in our new deployment is detect devices that are "out of spec" and make sure that the users find their way back to me for ... ah ... re-education.

Most "out of spec" things can be dealt with by the MDM server itself. If a device checks in with a missing configuration profile or a missing app, the server will automatically take care of that.

Sometimes, though, we want to check for other conditions and make sure that these situations don't go on for too long. To achieve this, I have designed a "lockout protocol" for our deployment.

The Configuration Profile

We have a configuration profile that can be applied to any supervised iPad that essentially “locks out” the user from doing any work. It’s really quite simple.

The first payload is a Restrictions payload which I use to only allow one app: The JAMF Self Service app.

The second payload is a Home Screen Layout payload. This puts the Self Service app into the Dock, so that people can find it easily.

That’s all it is but, because the devices are supervised and in DEP, there’s nothing the user can do to get out of this situation except to come and see me for help.

The Criteria for Lockout

To detect these anomalous conditions, I have a smart device group in our MDM that captures devices based on the following conditions:

  1. The device inventory is more than 10 days old (i.e. it’s not communicating with the server properly) OR
  2. The JSS “Jailbreak Detected” field is “yes” OR
  3. The “Location Services for Self Service” is “Not Enabled/Unknown”.
  4. The iOS version is less than the current release version of iOS.

Now, I normally give a grace period for iOS updates of about a week before I update the criteria for the smart group so it’s not too draconian.

I haven’t yet had a device where the inventory alone was stale. I suspect this condition is probably redundant given that, if the device can’t supply inventory, it’s unlikely to be able to receive the new profile either.

Warning Period

When a new iOS update comes out, the first thing I do is push a notification to Self Service. To be fair, about half the students respond to this in a timely manner.

After a few days, my new thing is to push a new wallpaper to the devices that puts the message right in the students’ faces.

After a few more days, if the devices still aren’t updated, I update the criteria for the lockout protocol and the shutter comes down until everything comes into line.

Even when locked out, the device will still be able to be updated as Settings is the one app that can’t be hidden.

Once the anomalous situation is resolved, the user will likely need to come and see me. Devices update their inventory typically once a day to the JSS, but an administrator can force an inventory update manually. That would cause the device data to be updated and the restrictions lifted.

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.