The Case of Being Mostly Cloudy

For a while it seemed that everyone was always giving away copious amounts of storage on whatever cloud service they were offering.  I signed up for a few, but never really used them much.  It was storage I had available, but I didn’t do much with it.

My primary issue was that with some of these services I was signed up twice, once tied to my work email and the other to a personal account.  This rather defeated the purpose of cloud storage, not having one account easily accessible from different places.  the other was that at work I long ago switched my primary computer to be a persistent virtual machine.  the data drive on that VM is only about 6GB, which had to provide room for all of my settings and local data.  That left no room to sync Dropbox, Box, or OneDrive.

A few years ago I actually began to formalize what cloud storage services I used and how I used them.  The impetus was two fold.  First, moving to Chrome as my web browser allowed easy access to my Google Drive account.  Second, Dropbox and later OneDrive implemented automatic photo uploading from your smart phone.  This gave me yet another place to securely backup and store all of the photos on my phone.

As time progressed however, things have shifted which is causing me to reevaluate how I use my cloud storage.  Google Drive has become my standard location to save individual important files to the cloud for backup.  Any document that I want to make sure will survive a catastrophic hard drive crash ends up there.

Dropbox, meanwhile, is essentially dead to me at this point.  My automatic photo uploads quickly overwhelmed the less than 6GB of space I have.  It’s been full for quite a while, and with that size limit I’m not sure what I will us it for when I finally clean it out.  A backup for Google Drive?  That seems a bit excessive…

OneDrive is now moving to the same fate as Dropbox.  The 25GB of storage I have currently has been perfect for automatic photo uploading, and allowed me to store all of my photos there for easy review and retrieval.  Now however, in July OneDrive will reduce my space down to 5GB unless I subscribe to Office 365.  Doing so will get me 1TB (!) of space, but that means paying for another cloud storage service, because…

There is also iCloud.  For the past couple of years I paid for the lowest tier of storage, because that was what I needed to backup my iPhones, iPads, and MacBooks (I should point out that everything other than the iPhones are work-owned devices).  I have resisted converting my legacy iCloud account into a proper iCloud Drive account, but now my 20GB storage limit is forcing my hand.

On a trip this past weekend I took a ton of photos, including longs runs of burst shots with my iPhone.  My iCloud storage was already nearing the limit, and this flurry of activity has run me out of space.  So my decision now is whether or not to upgrade and convert to iCloud Drive, which means that I have to change how I think about iCloud and what I use it for.

Up until this point, iCloud for me had one purpose:  To backup my i-devices.  That was it.  It was not for file storage, syncing, or other activities such as those.  iCloud was my first line of backup to guard against an iPhone or iPad data loss.  Google Drive backed up individual files of my choosing.  OneDrive was a second backup for my pictures.  It was a three-phase approach, and now two of those phases are shifting.

As it stands right now OneDrive will likely become superfluous storage along with Dropbox.  I’m not sure what either will be used for.  Google Drive will remain as it is.  iCloud may become my primary backup method after and upgrade and conversion to iCloud Drive.  I haven’t quite worked all of this out yet.

 

The Case of Managed or Unmanaged Apps

As we have begun to deploy apps for iPads on a wider scale across the environment, I’m struggling how what format to do so in.  Do we use the original format of using App Store codes, or do we fully and completely switch to Managed Apps?  I’m not sure which is the correct answer.

When using app codes, the rub there is that when a code is assigned to a person, the license for that app becomes the permanently assigned to the AppleID that redeemed the code.  In contrast, when using the Managed Distribution method the license for an app is temporarily assigned to the user’s AppleID, and can be taken back using your Enterprise Mobility Management system.  So, on the surface, for an enterprise environment the latter method seems like a no-brainer.  But, there’s one small hitch.

iOS apps are sandboxed.  Meaning that each app essentially exists on an island unto itself, with limited to no interaction with other apps or the device’s underlying system.  The problem is that by doing so not only is the app isolated, but all of the data associated with that app is marooned with it.  So, for example, if I markup a PDF file with iAnnotate, that PDF remains part of and associated with the iAnnotate app.  If iAnnotate is a Managed App and I revoke the license, not only is the app itself pulled, but any data saved with that app gets pulled as well.

The ramifications of this is that at some point a student, staff, or faculty member is going to lose some of their saved files.  When the license is pulled and recovered by the EMM system it will take the user’s data with it, and I’m not sure there is any way to get it back.  The easy “not-my-fault!” answer is to tell everyone to make sure everything is saved to a cloud storage service such as Box, but expecting 100% compliance with that is foolish.  The administration might let it slide when random Suzy Student graduates and loses her annotated PDFs, but when Dr. Administrator loses a vital planning document because she’s transferring to another college it will become a much bigger deal.

So, I’m torn.  On the one hand I would like users–students especially–to be able to take their work with them when they leave, but ensuring that means giving them a permanent license to every app we buy.  I don’t want to take any of their work away from them when a license is pulled from their iPad.

On the other hand I want to save money, and offer a wider variety of apps to users.  Doing that however, requires fully using the Managed Distribution method to make every dollar stretch as far as we can, and not constantly purchasing more and more copies of apps we regularly use.  I cannot have any confidence that students will handle their data properly, however, and take the extra step–and it is an extra step with iOS–to move everything to and from the cloud when working with their files.

I’m unsure which way to lean, but I know what way the budget is going to push me.

The Case of the App That Wouldn’t Go Away

I ran into an odd problem I had not encountered before: an app that wouldn’t delete from an iPad.

All of our iPads are managed by AirWatch.  As part of management I only force any enrolled iPad to have one single app, the AirWatch Agent.  To help further ensure this app gets installed I have a Compliance Policy enabled that seeks to repeatedly annoy the user into submission should they refuse the push on enrollment (or something else happens that prevents the Agent from installing.

On a coworker’s Device Enrollment Program-controlled iPad her Agent app would not install or delete.  The icon remained dimmed with a “Waiting…” status.  To solve this problem I removed her iPad from management, and re-enrolled it.  This seemed to have no immediate effect.

The next morning I put her user account into a special group to add her and her devices to an exception policy from the app push and the compliance policy.  I then sent a Query command to her iPad.

I’m not sure if these steps I took this morning fixed the problem, or if I simply wasn’t patient enough after re-enrollment the previous day.  Regardless, the Agent did finally install and her iPad has returned to compliance.