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.

The iOS 7 Power User Challenge

That the growth in iOS has been phenomenal hardly needs to be stated any more. To people like me, though, who have been Apple users since the Mac Classic, it's been an amazing ride.

In 2008, after the launch of the iPhone 3G, I wrote:

If you haven't got it already, it's time to move your head to this place: iPhone OS is Apple's mainstream platform for 2012 and beyond.

That's the world we now live in.

I am and have always been obsessed with software. While the media obsess over new hardware, I've always been far more interested in the capabilities of software. Better hardware - generally - just saves me time. A faster iPad will be great, but what shall we do with it?

What iOS Hath Wrought

Three times in my career, Apple has shipped software that conventional wisdom said basically couldn't be done. The first was the Carbon layer of Mac OS X: most of the Mac toolbox running on a preemptively multitasking, protected memory Unix kernel. The second was Rosetta: PowerPC apps running unmodified and, for the most part, perfectly well on Intel processors.

iOS was the third. Conventional wisdom said that you couldn't possibly get a desktop OS running on a phone. Conventional wisdom said that you couldn't get rid of a user-visible filesystem. Conventional wisdom said you couldn't require all software on the platform to come through a first-party app store.

Right now, just before WWDC 2013, I think it's important to take time to appreciate exactly what iOS has achieved.

iOS broke the tyranny of the hierarchical filesystem as a user interface. A concept so complex that possibly the majority of computer users never achieved any level of real competence in its use. A far larger proportion certainly never achieved any kind of mastery.

iOS turned the purchase and installation of third-party software from a great opportunity to destroy your computer into something that people do for fun. People of very low technical ability are now perfectly safely and competently administering their own computers. This is a revelation and, in my opinion, a big part of the IT backlash against iOS.

iOS solved the virus problem. The conventional wisdom of the PC years was that Windows got viruses because it was vastly more popular than the Mac. In the post-PC years, we have hundreds of millions of people using iOS and, so far as I know, zero viruses.

There are other achievements I could list, but the point is that iOS broke through a lot of conventional wisdom about how computers should appear and operate.

The State of the iOS Union

If I were running Apple, I would milk the Macintosh for all it's worth — and get busy on the next great thing. The PC wars are over. Done. Microsoft won a long time ago. - Steve Jobs, February 1996

So where are we today with iOS? We have a powerful mobile operating system with excellent APIs that enable a broad range of powerful applications to be developed. Despite that, some of the fundamental design choices in iOS are limiting the growth of the platform.

The chart that I use to explain the appropriate deployment of smartphones, iPads and desktop computers uses two axes: task duration and task complexity.

iOS does a wonderful job in the lower-left corner of the chart. Right now, though, I think iOS needs to attack the upper-right corner of this chart. There is an opportunity to completely eliminate the desktop computer for some and drastically reduce its importance for many more.

What does such an attack look like? Well, there are various sources of complexity in the use of a computer for a task and some of them still either overwhelm iOS or simply become too awkward to tolerate.

Let's look at some of them.

Moving Data and Documents Between Apps

One source of complexity is having to use multiple tools to achieve the result you want. On the desktop, the common transport for doing this is the filesystem: save a file from one app, open it in another. iOS needs to support the user in that task without breaking the filesystem abstraction that has been so valuable in making iOS approachable for less technical users.

The current mechanism of "Open In...", which allows an app to copy a file to another app, is enabling some decent workflows but has the drawback of littering each app's sandbox with a copy of the file. It's also difficult to move large files this way.

If I want to take a PDF stored in Evernote, edit it with PDF Expert and save a modified version back into the same Evernote note, I simply can't do it today. The fact that so many iOS apps have built in direct support for Dropbox is testament to how weak the Dropbox app itself is. This is no criticism of Dropbox; they're doing all they can, given the design of iOS sandboxing.

This also applies to chunks of data that are not files: URLs, strings, photos. A great recent example: I like to use Flipboard and Flipboard recently introduced a new feature where you can create "magazines" from web pages. I normally use Instapaper for caching stuff to read that passes by on Twitter, which I read with Tweetbot. Tweetbot supports a few read later services, including Instapaper, Pocket and Pinboard. It doesn't support Flipboard, and there's nothing I can do to make it support posting links to Flipboard apart from begging the Tweetbot developers to add it. The burden of inter-app integration should lie with the destination app, not the originating app.

If iOS had a generalised "send this piece of data to apps that claim to handle it" service - yes, like Android does - all the work to allow posting a link to Flipboard from Tweetbot would be in the hands of Flipboard and not Tweetbot. Similarly, the common workflow of saving an image to the Camera Roll and later extracting it in another app leaves behind data detritus that could be avoided if direct communication were easier.

Moving Data and Documents Between Devices

The TL;DR of this section is: iOS should support AirDrop, and it should be available as an "Open In..." target. Moving data between two iOS devices without using a Dropbox-like service, email or, worse, a Mac has always been annoying. Apps like iFiles leverage Open In... to work around the problem but, again, you end up with a copy of your data in iFiles' sandbox as well as the originating app.

There is another compelling argument for supporting WiFi Direct: Apple TV. The challenge of mass deployment of Apple TV on networks are well documented. What if a future Apple TV could receive AirPlay streams without the need to even be on the network? That would be a Very Big Deal.

Of course, this requires additional support in the WiFi chipsets built into iOS devices but there's no inherent reason it can't quickly become a standard capability.

Dealing with Big Personal Data

One of the bigger limitations of iOS has always been that, every so often, you'll try and do something that's "too big" for an iOS device to do. As the hardware itself becomes more powerful, these situations grow fewer but they still remain. In particular, they tend to persist in areas that involve handling a large chunk of data.

Examples include: trying to import a video from the Camera Roll into an app, opening a large Keynote file, applying a complex set of adjustments in iPhoto. Using Open In... can sometimes fall over if the file is large.

To some extent, these things are hardware-dependent. As CPU, memory and storage levels increase, these issues should diminish but there are clearly some aspects of these that are OS-dependent.

More Granular iCloud Restore

iCloud backup is really great. You set it and you forget it but, increasingly, I see a need for more granular access to the backup. Restoring your entire device just to get one missing file back is quite a drastic step, particularly when you have made other changes to data on the device since the file was lost.

Right now, iCloud backup is a brilliant disaster recovery mechanism. You lose or destroy your iOS device and you can be back up and running in a very short time. What it is not, currently, is a great user-error-recovery mechanism. If you screw up, you're staring a whole-device restore in the face.

Password Management

The current situation with internet passwords on iOS is, put simply, crazy-making. I use 1Password and, short of making it my main browser, it is maddening to have to keep switching between Safari and 1Password to get logged into a site.

The fact that I have a bookmarklet on my Safari toolbar whose sole purpose is to open the current URL in 1Password tells its own story.

I don't know exactly what the solution to this is. Giving mobile Safari the ability to run extensions isn't quite enough unless those extensions can communicate with an app also installed on the system. Regardless, this is becoming highly frustrating. The entire mechanism of usernames and passwords is out of date. It'd be great if Apple could lead the way on building in platform level support for 2-factor authentication. I'm not enough of an expert on this to comment much further but this needs to get easier.

Typing Enhancements

The iOS keyboard is good, but it could be better. I haven't spent a lot of time with the alternative keyboards on other platforms but they are said to be ahead of iOS. I think more work could be done to make autocorrect more predictable.

My main complaint though is about the text selection interface. We now know from some experience with gestural interfaces that interactions requiring tap-and-hold just plain feel slow, whether they actually are or not. The iOS text selection gestures depend heavily on tap-and-hold to precisely place the insertion point loupe.

Wrist Protection APIs

I do not think that iOS needs to embed deep stylus support. Nonetheless, the are increasingly good digital ink apps for various applications: art, drawing, PDF annotation and so on.

Many of these apps have built their own wrist protection systems. Some are better than others and none of them behave exactly alike. In addition, none of them play particularly well with the iOS four-finger multitasking gestures.

Some system level mechanism for doing wrist protection alongside the multitasking gestures would go a long way to easing this problem.

Remove 50MB Limits on Cellular

Power users are often also highly mobile users. One of the main reasons I use a third-party app over the Apple Podcasts app is that, with Instacast, I can download a podcast of any size but Apple's app continues to enforce the 50MB download limit on cellular networks.

This limitation made sense in the early days of iOS, where everyone was on unlimited data connections. Today, most people are on metered connections. We pay for every byte, so we should be allowed to choose exactly how we spend those bytes.

Of course, a warning would still be useful. Some people are on metered contracts which, after a cap is reached, impose astronomical charges. Along with this change, I think a system-wide governor on mobile data usage would be useful. You can imagine, though, how Apple might be reluctant to build in such a feature and then undoubtedly face a rash of "Waah! Apple cost me thousands in data charges!" headlines every time someone doesn't understand how the feature works.

Choose Default Apps

The question of changing default apps has been a contentious one at times in the life of iOS. Until recently, I had not seen many examples of compelling replacements for Safari and Mail. Today, though, that's vastly different.

There are really good alternative browsers now, in the form of Chrome, Dolphin and others. The official Gmail app is lacking in some ways but its a perfectly good alternative for Gmail users. On the iPhone, I have been using Mailbox since the day I got to the head of the queue and would love to set it as my default mail app.

I don't think a generalised UI for changing every protocol handler in the system is necessary at this point. However taking two baby steps by allowing the user to choose their browser and mail client (and perhaps a third in choosing their maps app) would be a good start.

I would like to see some policy around preventing apps from setting themselves as default handlers. The user needs to remain in control of this.

Deeper Keyboard Support

I'm not a regular Bluetooth keyboard user but I do use one occasionally. The apparently increasing popularity of Bluetooth keyboard cases suggests that people do like to regularly use a keyboard with their iPad.

To better support this, I would like to see a few enhancements to the Bluetooth keyboard support in iOS. In particular, a method of keyboard-navigating the multitasking bar would be very welcome. I imagine this as a Command-Tab keystroke opening the bar and subsequent strokes highlighting successive apps which can be chosen by hitting return.

The Way Ahead

That's all I have for now. There are certainly more things that could be added. I have focused here specifically on the issues that are limiting deeper adoption and utilisation of the iOS platform for the 'power user'. There are certainly other concerns that a casual user or a beginner would have.

My broader point, though, is that iOS does NOT need a ground-up rethink, nor does it need to become more like our existing desktop OSes, in order to satisfy more of the needs of the power user. This conceptually small set of changes would go a long way to pushing iOS deeper into that high complexity/long duration section of my chart above.

IT Does Not Love iPads, and that's a good sign

I'm not normally in the business of going full-Macalope on stupid articles about iPad. After all, there aren't enough hours in the day. Having said that, one particular article has surfaced recently that I hear is being used by at least one local authority IT team in Scotland to justify an LA-wide ban on iPads.

The article by Michelle Fredette in Campus Technology entitled "IT Does Not Love iPads" is so completely off-balance that it's almost funny - until you realise that this kind of weak thinking is actually being taken seriously.

In case you don't make it to the end, here's an executive summary of the complaints:

• iPads come in boxes
• App licensing works differently from Microsoft's
• Apple TV is finicky to deploy at scale
• You need a whole new network for iPads

The only one of these that actually makes sense is the complaint about a device (AppleTV) that is, in fact, not an iPad.

Anyway, let's get into it.

Is there a higher ed institution in the United States that has not fallen into a swoon over iPads? Some colleges hand them out by the thousands to their entire student body. Others stockpile hundreds for use by faculty, staff, and administrators, or to be checked out of the library by students. On many campuses, iPads have taken over the hearts and minds of everyone.

Let's start by using words like "swoon", "stockpile" and "hearts and minds" to get it clear from the start that all this enthusiasm for iPad is just a mass delusion. Got it?

Everyone, that is, except the IT department.

Given our decades of experience with computers that the IT department love and staff and students hate, I think this can only be considered a good sign.

These sexy tablets might be the apple of faculty and students' eyes, but for IT directors and their staffs, working with iPads in an enterprise network environment is not the stuff of a love affair.

"Sexy". As we know, Real Serious Business can only be done on thick, black computers that people don't like.

To state the problem simply: iPads are designed for consumer use, and as such, they're not set up for large-scale implementations.

I hope someone told LAUSD, who just voted to roll out a $50m, 47-school iPad program. Or McAllen School District, who already have 25,000 units in the field.

They're not even set up for two users to share the same device, much less for sharing over a network.

It's 2013 and the fact that iOS is not a multi-user operating system is still coming as a shock to some people? Also, it turns out the iPad is not a mainframe computer.

For schools making a major investment in iPads on campus, the solution is a combination of new policies and investment in third-party tools for managing the devices.

So there is a solution!

For many other institutions, though, the devices are acquired as needed, or in small batches for specific purposes. In such cases, schools don't necessarily anticipate the additional tools and administration the iOS devices can require--until IT starts bumping up against the limitations of a device that's not easily managed under the school's existing network and resource management infrastructure.

So organisations that don't bother to try and understand what they're doing tend to have a hard time?

The differences between iPad device administration and that of desktop machines or laptops are apparent at all stages of their use, beginning the moment the machines arrive on campus.

You don't even get a minute's reprieve from the awful otherness!

Take, for example, the case of Seton Hill University, a school that has distinguished itself as a forerunner in campus iPad implementations, including being named a second time as an Apple Distinguished Program. In the spring of 2010, the Greensburg, PA, school ordered 1,850 iPads in anticipation of providing them to students for the following fall term. What IT faced was a giant pallet of the devices, individually wrapped or in boxes of 10.

iPads come in boxes! Unlike the Windows PCs that come on tear-off rolls and the Android tablets that come in sheets you can cut to size!

Phil Komarny, Seton Hill's vice president for information technology and CIO, says that his staff had to take each iPad out of the box, update the operating system to the most recent version, image tag it, and put it back in the box to be ready for deployment. "There was nothing else we could do, because this device that they built is completely consumer," Komarny shrugs.

To be serious for a moment, there is something else you could do: get your reseller to do this for you. I'm only leasing 120 iPads and I've had resellers falling over themselves to help us do these chores.

If I was buying 1,850, I'd think this would be the very least a reseller could do for me.

Thomas Hoover, associate vice chancellor and CIO at the University of Tennessee at Chattanooga (UTC), had a similar experience with iPads in a previous role at Pepperdine University (CA), where the IT group handed out several hundred of the devices to students, who turned them back in at the end of the year. "We'd have to manually go through and redo all the iPads," Hoover explains. "It's not like a computer device that you can configure automatically."

So once a year you had to touch every iPad once? Poor dears.

Two years after the first Seton Hill deployment, Apple brought out Apple Configurator, a free download from the Mac App Store that can be used to configure 30 devices at once. But for many campus CIOs, that's too little too late. Those with big iPad implementations tend to rely on mobile-device management (MDM) applications like MobileIron that enable enterprise-level configuration, security, and app management.

And people with big Windows implementations certainly don't have to buy any additional software or services to manage those machines, am I right?

With the iPad, app management is a whole new ballgame for IT departments familiar with licensing and managing applications in bulk for desktop or laptop machines. Rather than selecting from software options hosted on the school's network, faculty and administrators download apps from the App Store, choosing from hundreds of thousands of options. Many schools simply haven't set up a good strategy for purchasing and tracking this new approach to apps. And in lieu of a policy, faculty often download an app using their personal Apple account, and then get the university to reimburse them. (Students are generally not reimbursed for their app downloads, which are considered a "books" expense.)

If you fail to plan, etc.

More than one CIO laments that the ad hoc nature of app downloads can lead to the school purchasing the same app repeatedly, especially if it's a popular one like Numbers. Hoover describes the problem like this: "You reimburse professor A for an app, and then they leave. IT wipes out the iPad because you don't want any sensitive information from the previous person, then yeah, you're going to have to buy that app again for professor B."

Layered model deployment. It exists for a reason.

Some schools have developed workarounds to avoid repeatedly purchasing the same apps. John Haverty, assistant director of user services at Washburn University (KS), says he started to recommend that departments create a generic account for their faculty members to use. "That way, if someone does leave, that software's not going to stay with them--it's going to move on to the next person," he points out.

Again, look at the layered model but you'd probably be cheaper just eating the cost of - what - $30-50 of apps when someone leaves. After all, how often do you turn over staff? The cost of processing their employment paperwork will probably outweigh the cost of the apps they need.

Haverty raises another app-related issue for tax-exempt universities, which is the time-consuming process for getting tax reimbursements on app purchases. "We had to go ahead and make the purchase, then contact someone at Apple to provide the tax ID to get the tax reimbursed." Haverty says that often departments don't bother.

Given that tax systems haven't really caught up with the internet yet, this is hardly a surprise.

Apple has a Volume Purchasing Program for education, released in 2011, which enables educational institutions to buy apps and books in volume at discounts and tax-free. And mobile-device management providers enable schools to manage their Apple volume licensing as part of the broader MDM. Indeed, MDM solutions solve just about all the major challenges presented by Apple devices, including network access, enterprise configuration, and device and app management, as well as security requirements like the ability to remote wipe a lost or stolen device.

OH WAIT - so all this complaining was actually for nothing because solutions to these problems already exist?

Apple, in fact, recommends that enterprises use them. But for schools like Washburn that have acquired devices like iPads and apps in a more informal manner, MDMs represent a time and resource sink that they haven't yet committed to.

If you fail to plan, etc.

But even if your school works with an MDM, there's still the problem of Apple TV working within the campus enterprise. Apple's media receiver is the ideal device for mirroring iPads onto a large screen because the two devices can connect wirelessly. Even better, Apple TV is configured to receive iPad input, so content looks like it should without tweaking.

Yup, Apple TV is great but calling it "the ideal device" and pretending it is essential for an iPad deployment is a great set-up for slamming it in the next paragraph.

Apple does provide a VGA adapter that can connect iPads to televisions and monitors, but, depending on the version of your iPad, you still often have to fiddle to get it to display apps.

The VGA adapter works great - especially with the Lightning port instead of the 30-pin - and I don't know what the "fiddle to get it to display apps" thing is about. I think that's just a lie.

So Apple TV seems like a natural choice for projecting iPad content. And faculty like Apple TV for features like the ability to stream Netflix. But as UTC's Hoover says, "making Apple TV work on the campus network is an abomination on a grand scale."

An abomination on a grand scale, eh?

Hoover may be a bit hyperbolic but he's captured the zeitgeist of IT's exasperation with Apple TV, which is the subject of a July 2012 petition posted on change.org by members of the Educause Wireless Local Area Networking Constituent Group. The petition notes that while Apple has created advertising that promotes the use of Apple TV in college conference rooms, auditoriums, and laboratories, "Apple TV, AirPlay, and Bonjour technologies make it very difficult to support these scenarios on our standards-based enterprise networks."

There's no doubt Apple TV and Bonjour can be finicky at large scale - this definitely needs some work - but I guess my question is what's so wrong with using the VGA adapter if AppleTV is simply impossible.

Issues with AppleTV are tangential to whether or not you should deploy iPad and are absolutely bogus as a justification for banning iPad from your school.

To set up Apple TV, says Jeff Kell, a member of UTC's network services, "you have to enable wireless multicast/broadcast traffic. Such traffic is sent out over every access point on campus, tying up airtime." This means that in an "enterprise setting, every access point will get a copy of every device's advertisements or discoveries in the entire enterprise." Not only is this a huge waste of airtime and bandwidth, Kell says, but it is "a disaster incident waiting to happen, such as some dorm kid streaming porn onto a classroom projector."

I might be old fashioned but I think of "disaster incidents" as being a bit more serious than this. Regardless, anyone who has actually deployed an AppleTV will know that you can turn on an on-screen code that any user must enter on their device to gain access to the Apple TV. For exactly this reason.

Also: don't these massive enterprises have VLANs?

In a blog post, Matthew Libera, performing arts technology consultant at the University of North Carolina at Greensboro, described the steps he took to use Apple TV in his classroom, which included creating his own network and sacrificing access to the internet on his iPad. While it was doable, Libera wrote, "there is no way in heck that I'll be able to convince any of my faculty here that this is a worthwhile undertaking."

Correct. If you have to do this, just get a VGA adapter and get on with your job. This is still nothing to do with iPad per se.

Indeed, many schools just forbid the use of Apple TV on campus. Or they turn to companies like Aruba Networks, which offers a solution for managing Apple TV and other Bonjour protocol-reliant devices in a university enterprise network. But again, this takes an investment in a third-party toolset that's generally attractive only for institutions that are all-in when it comes to iOS devices.

Banning Apple TV isn't actually that unreasonable in its current form. Still nothing to do with iPad.

All-in schools like Seton Hill say that that its iPad program would have been impossible without a major investment in a state-of-the-art network, which included replacing wiring for full campus coverage and upgrading both the wired and wireless networks. The latter, which provides campuswide 802.11n technology, was essential to support the demands of an iPad-oriented university population.

Dunno. I'd say campus-wide WiFi is essential to support the demands of any population of people born after about 1955, regardless of the computer they're using.

With the help of Enterasys network solutions, Seton Hill also revised its approach to managing the network. Now, the school handles network traffic on three virtual LANs: one for iOS devices, one for Mac OS X traffic, and a third for Windows and guest traffic. This approach streamlines network management, but also enables IT to manage network traffic at a more granular level.

OH WAIT - so there actually is a solution to these problems? I'm starting to notice a pattern in this article.

Lynn University (FL) is another iPad-committed campus that will roll out an iPad mini program to all freshman and transfer students this fall. It was able to create a robust campus network as a windfall from hosting one of the presidential debates last October. While the school had to pick up the tab for the new network, it got good deals on some of the technology from participating companies.

Note the subtle - and untrue - inference that you have to buy a new network to support an iPad program.

According to Lynn's CIO, Chris Boniforti, the school had to provide a completely new network environment for up to 6,000 media personnel attending the debate, and it had to be totally isolated from the university's network. Lynn essentially created a whole new network, roughly the size of its existing network, with the understanding that the school would bring it in to replace its aging network once the debate was over. The school estimates that process would otherwise have taken several years and pushed back its iPad mini initiative.

So Lynn got a new network faster because they hosted a presidential debate. Not clear how this is related to iPads.

For schools like Lynn and Seton Hill that have invested heavily in what Boniforti calls the Apple ecosystem, there seem to be fewer hiccups in using enterprisewide iPads. But IT directors who want to incorporate iOS products into their campus ecosystem without making such full-scale investments say they would like a little more support from Apple.

Let's be clear: what the author means here by investing heavily in the "Apple ecosystem" is actually "taking the time to understand how these devices work".

As one Educause wireless LAN constituent mused on the group's listserv: "This is where I daydream about the likes of several Apple engineers reading this list, thinking 'Gee, maybe we should consider how to make our toys work in the actual enterprise.'"

Aaaaannd there's the "toys" canard. It's amazing to me that the FAA approved American Airlines pilots to fly with toys in the cockpit.

So this article boils down to four actual complaints:

• iPads come in boxes
• You don't buy apps like you bought them from Microsoft
• Apple TV is tricky to manage at scale
• You need to buy a whole new network for your iPad program

The first complaint is just utterly bizarre. The second is true but, as the author actually points out, there are multiple existing solutions. The third complaint is the one that's actually true. Unfortunately, it's just nothing to do with iPad. The last is just false.

The entire article follows the pattern of building up small issues (and non-issues) to be insurmountable obstacles, then quietly admitting that a solution actually exists.

Using articles like this one to justify iPad bans is pathetic and embarrassing.

Teaching Programming with iOS and Amazon EC2

I just shut down the Amazon EC2 instance we've been using all school year, so I thought it was worth reflecting on. Last August, I wrote about my new approach to teaching Ruby programming on our iPads.

How did it work? In a word: perfectly.

The Server Side

Back in August, I set up an Amazon EC2 instance. I used the standard Amazon Linux AMI, and launched it in a Micro instance. For neatness, I allocated an Elastic IP Address to the instance and created a sensible DNS name for it.

The next step was to set up user accounts for each pupil. I did this manually because I could, but it's easily automatable if you needed to. Our iOS SSH client, Prompt, supports using SSH keypairs for authentication but distributing the private keys is a little fiddly so I reconfigured SSH on the server to allow password authentication.

Responsiveness of the remote server wasn't an issue at all. We used the EU West (Ireland) region for our Amazon EC2 instance so it wasn't far away from us and the interactive response was just fine. I'm not sure it would have been ideal to actually edit code in, but it was perfectly fine for running programs.

We ran into no problems with with the EC2 server at all. I set it up, it ran for over 5,000 hours of operation without a hitch and I turned it off today. All-in, it cost me £65 to run this server for the past academic year. I didn't do anything to limit the time the server ran - it was on 24x7 for the whole year. If I had automated shutting it down at, say, 10pm and relaunching it at 9am, I could have cut the cost to about £35 for the year but it's almost not worth my time to bother.

The Client Side

In my last piece, I was debating the exact combination of software to use. In the end, we settled on using Prompt for our SSH client and Textastic to edit the code.

Textastic has a really nice feature whereby, if a file was initially downloaded from a remote server, Textastic can send the file back where it came from with one tap. This really helped the overall workflow.

The idea of switching between two apps to edit and run code didn't seem to have much impact on pupils. With the multitasking gestures in use, the switch was easy enough. The biggest complaint was that, on our iPad 1s, resuming the switched-to app was slower than we would have liked. This problem will go away after our refresh.

Occasionally, Prompt wouldn't maintain the connection to the server while the pupils were editing code in Textastic. I haven't yet figured out if that's just a bug or if there's some server-side timeout happening. It wasn't a frequent enough occurrence to warrant a lot of debugging.

The Hardware

This class was the first time we had deployed Bluetooth keyboards for use with the iPad. When you're programming, you're always reaching for those weird symbols in the second and third keyboards on the iPad. Textastic does a good job of trying to help you by creating a row of five-way buttons across the top of the standard keyboard that allow quick access to a large number of symbols. The downside to this is that you lose even more screen space for seeing your code.

For these classes, I bought a number of these Bluetooth keyboards. They cost £9.16 on Amazon and they held up perfectly well for the year. They're not quite as delightful to type on as an Apple Bluetooth keyboard but they do the job just fine and none of them broke.

The Workflow

Once students complete an assignment, they have to turn in a report with some text, their source code and evidence of systematic testing of their code. We went through a few iterations of the exact workflow for this but, in the end, we settled on copying and pasting the code from Textastic and the testing runs from Prompt into Pages and presenting them in a monospaced font along with the rest of the report. The only downside to this workflow is that you lose the syntax colouring from Textastic.

This document was then emailed to me as a PDF where I could mark it digitally using PDF Expert on my iPad and return it to the students via email and archive my copy.

The Future

I'll definitely continue doing this. Given the success of this project, it's almost inconceivable that we could justify provisioning a whole computer lab for just one subject.

On a wider note, I think this milestone is emblematic of the increasing maturity of iOS. In 2010, computer programming was one of the cardinal subjects that iPad sceptics insisted it would "never" be possible to teach using an iPad. Well, guess what? Add another item to the pile of things that people said would "never" be possible in computing.

Never's a long time.

Canon WU10 WiFi Scanner Adapter Review

I've been using a Canon P-150 document scanner for a couple of years now to go paperless. I've written about the process before and it's working very well for me.

In January this year, Canon introduced the WU10 WiFi adapter for the P-series scanners, along with an iOS app called Canon Capture On Touch Mobile. I couldn't find any reviews on the web, so I decided to take the plunge and buy one. Here's my take.

What It Is

The WU10 is a wifi bridge to control the Canon P-series desktop scanners. I have the P-150, now discontinued, and the WU10 also works with the current P-215 and P-208 Mobile scanners.

The WU10 is a plastic box with a USB socket and a power plug. You connect it to power and plug the scanner into the box over USB. The WU10 also contains a rechargeable battery which is charged by the mains cord but which can also power the unit itself and the scanner for mobile operation.

WiFi Setup

The WU10 has two modes of wifi operation: it can connect to your existing wifi network, or it can become its own hotspot for ad-hoc operation. The wifi mode is selected by a switch on the side of the box and you have to restart the unit before it will change modes.

To set the device up, you start it in ad-hoc mode and connect to its SSID. From there, you can connect to a web-based configuration portal on the device via its IP address and enter the SSID and password for your existing WiFi network. Switch modes, restart the device and it's on your network and ready to scan. The configuration portal supports five different WiFi network setups so you can set it up for home and work. In the portal, you can also configure WiFi settings for the device's own hotspot, including 2.4GHz channels, 20/40MHz channels and change the SSID and key that it uses.

Mac Scanning

Once you've set up the device on your network, you can immediately scan from the iOS apps - more on that later. The Mac software "CaptureOnTouch" that came with the scanner is not included or updated with the WU10. Instead, you get an additional tool called "Scanner Wireless Connection Utility" which, as far as I can tell, tricks CaptureOnTouch into thinking the scanner has been connected over USB.

To scan though the WU10 from the Mac you have to first open the Wireless Connection Utility and 'connect' the scanner over the network. At this point, CaptureOnTouch wakes up just as it would if the scanner were connected directly. It's a small inconvenience but not really any more annoying than fishing around for the USB cable at the back of your desk.

iOS Scanning

One of the main reasons for getting the WU10 is that it enables scanning directly from iOS. Canon have an app named "CaptureOnTouch Mobile" that's universal for iPhones and iPads. Although the visual design of the app is not particularly to my taste, it works really well and does exactly what you'd hope it does: you can pick a few settings, scan a document and you open it in another app. What more do you want?

CaptureOnTouch Mobile doesn't have all the settings of the Mac version, but it has more than enough to be useful. You can:

• Choose the scanner, in case you have multiple WU10s on your network.
• Choose colour or grayscale scanning.
• Choose between Letter, A4 and auto-detect paper size.
• Choose 150dpi or 300dpi resolution
• Choose simplex, duplex or "skip blank page" scanning - the latter meaning "capture both sides and throw any blank sides away"

…and then there's a big "Scan" button, which makes it all happen.

As the document scans, you get a preview on the iPad screen and you can swipe through the pages. You also have the option of deleting individual pages from the preview if you get a mis-scan.

Once the scan is complete, you have the option of sending the document as JPEG to the Camera Roll or as PDF to another app via "Open In…". Both formats can also be emailed.

And that's really all there is to say about the Canon WU10. I'm really quite delighted with it. The app does everything it needs to do and, crucially, doesn't try to do anything more. It just scans and hands off a PDF to whatever app works for you. For me, naturally, it's usually Evernote but you can go to any app that handles PDF, such as iBooks, Explain Everything, Dropbox or a dedicated PDF app like PDF Expert.

More broadly, I find the WU10 interesting as it represents yet another step along the road of iOS doing the things that people said iOS would "never" do. You can't scan without a USB socket on board, right? Wrong.