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 Passive Install: Office 2013 and Acrobat Pro 2015 (DC)

Today I spent configuring and updating our installation points for Office 2013 and Acrobat Professional 2015 a.k.a. Acrobat DC.  Office 2013 went fairly smoothly, as it usually does, configuring both a custom passive install and automatically adding Service Pack 1.  The process for it is pretty simple:

  1. Run “setup.exe /admin” from a Command Line.
  2. Set the options and changes you wish from the customization tool.
  3. Save your MSP file to the Updates folder.
  4. Download the offline installer for the latest Service Pack.
  5. Run the SP installer with the “/extract” switch and unzip all of the files to the Updates folder.

Acrobat Pro however, was a little more annoying.

  1. Download Adobe’s Customization Wizard.
  2. Once you have that, open the AcroPro.msi from within the wizard.
  3. Make your changes, generate the Transform file, and save that to the Transforms folder in the Acrobat installation directory.
  4. Save the AcroPro.msi file.

The problem I kept running into, and didn’t solve but managed to work around, was that certain options from within the Customization Tool caused an error:

Unable to Submit Changes, MSI Set Value failed, Error Code = 259.

I googled high and low, the full width and breadth of the Internet, and could find no answer.  This was further complicated a bit by being an enterprise customer, so although our package said is was “Acrobat Professional DC” it was actually “Acrobat Professional 2015,” also known as the “Classic Track.”  The slight version difference made getting the proper update package more complicated than it should have been, and may be contributing to the errors with the Customization Wizard.

In the end on the PC side I was able to change or disable most everything I wanted to in the installer.  I ended up creating a simple batch file to run the Acrobat Setup program, which runs a passive install, then follow that immediately by the latest MSP update package.  Although the update runs silently, the open window of the batch file is enough to let me know the computer is still processing the update.  All of the seems to work well enough to do what I want.

On the Mac side, things were much easier for Acrobat, after a brief false start.  Adobe does offer a Customization Wizard on the Mac side, but when attempting to use it the tool wants a serial number.  As an enterprise customer, we don’t have one the way it wants it.  So that was a bit of a dead end.

However, after getting our enterprise installer and the proper update package for Acrobat Professional 2015, I simply loaded everything into AirWatch and let our EMM system handle it.  When loaded into Products on AirWatch and pushed down via a Files/Actions profile, the installer and update PKG file ran silently and flawless.  That was definitely the way to go.

 

 

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.