28 Dec iPad Mgmt – Past, Present & Future with Case Study
Case Study
iMazing is a product from DigiDNA, which is a Swiss company. iMazing has a feature called Configurator that allows blueprints to be built.
We had a great experience with their technical support, Gregorio Zanon, discussing our management needs and requests and with them implementing many of our requests.
Here is a link to the University of Utah’s Marriott Library and other case studies using iMazing Configurator and their other solutions.
The Past
Originally, our iPad student checkout project started with 10 iPad with the use case of quick check
–out and return with students attending classes onsite at the Marriott Library or in near proximity. To meet this need and limited budget, we developed AEiOS (Automated Enterprise iOS) which is a python library designed to aid the automation of Apple iOS device management, configuration, and imaging. We wanted to provide our students and patrons the ability to use our iPads without restrictions as if they were personal devices. Users can configure the devices however they like, install their own applications, and even use iCloud, while we (MacAdmins) maintain user data privacy between each checkout.
It was designed for our student checkout iPads in our student environment with very busy support staff. It integrates the best of Apple Configurator, Device Enrollment Program (DEP), Volume Purchase Program (VPP), and Mobile Device Management (MDM). It wasn’t dependent on Jamf Pro could be used with any MDM solution, but we implemented it with our Mobile Device Management (MDM) solution, Jamf Pro.
By integrating the best features of Apple’s Apple Configurator, Device Enrollment Program (DEP), Mobile Device Management (MDM), and Volume Purchase Program (VPP). We have created a completely automated, and truly zero-touch solution for iOS device checkout using free and native Apple macOS solutions that require no interaction by our very busy support staff other than plugging in with check-in.
.
We wanted to set up a fully automated process that could easily take a new or recently checked-out iPad, erase it, apply a configuration to it, install apps, and quickly return it to students that would like to check it out. It had to be easy and simple as university students and non-IT employees would be interacting with it.
Here is an overview of the workflow process:
Technical Debt
With our student iPad checkout program success and increasing demand for more and more iPads. We started seeing increasing issues with technical debt the internally developed solution that we shared with the community on our public GitHub repository, but with no feedback or contributions. This is often the case with open source projects, where there is a need for the solution but due to many factors very little feedback and contributions outside the core developers.
A good open-source project solves a problem or the top problems that MacAdmins are actively searching for a solution. Maybe, our project solved a problem for a very few, but wasn’t the top priority that MacAdmins needed or time to focus on it? The truth is a lot of open-source code is not the best quality. Nobody wants to depend on code that is difficult to understand, unstable, and full of bugs. Our code had its fair share of bugs and stability issues and especially for those external to our organization the code was probably very difficult to understand, let alone to give us feedback and contributions.
And at the Marriott Libary, we are getting more & more busy with additional projects, services with ever-increasing demands on our time. The final nail in the coffin for this project was the core developer left our organization and we decided to investigate other solutions where we could greatly decrease our direct development and support, but provide similar functionality and with fewer bugs & stability issues.
The Present
AEiOS was retired and iMazing was chosen to control and image the Student Checkout iPads. iMazing is a product from 
DigiDNA, which is a Swiss company. iMazing has a feature called Configurator that allows blueprints to be built. The blueprints automate the process of onboarding iPads, whether it is a brand new iPad or one that was recently checked in. The blueprints supervise the device and enroll them with DEP through our Jamf Pro server. iMazing installs a WiFi profile to allow the iPad to connect to the Jamf Pro server. Jamf Pro’s Prestage Enrollment deploys our configuration, completes all the setup assistant screens, and returns control to iMazing. iMazing deploys the most up-to-date versions of the Apps we selected to be installed and can update iOS too. The iPad is now ready to be checked out to the next patron for use with all the Apps and configuration. iMazing is a true Zero-Touch deployment since Jamf Pro and iMazing perform all the actions without having the need for user intervention.
Our Setup
Hardware
After implementing a test setup of iMazing we purchased additional iPads, 100+ and higher-end USB 3 hubs to improve performance and reliability. We choose a Cambrionix – ThunderSync3-16, which is a 16 port Thunderbolt USB 3 hub. With the ability to connect 5 other hubs together it is great for scalability. The hub can provide the device with power while it is syncing with the computer using the CDP (Charging Downstream Port) functionality.
Configurator
Configurator in iMazing has many of the same features that the base iMazing has but in a more streamlined way for MacAdmins. The main feature that we used to configure the iPads is the Blueprint functionality. The Blueprints allow us to select different actions that will occur to the iPads to implement automation. To configure the iPads we do use most of the features that the Configurator has to offer. Their website for the Configurator has an overview of the different functions that it does. It is a great resource when you want to see more options and different management scenarios.
Access Configurator in iMazing
Open iMazing on the menu bar select Configurator.
There is plenty of different options to choose from in this list. The most common one is the Blueprints since that is where we customize the actions to be run on our managed iPads.
Blueprints
A Blueprint is a series of settings that iMazing applies to an iPad when it is connected. Blueprints allow us to bring an iPad that was used by a student, back to a default image state. To create or customize an existing blueprint.
Select Blueprints
The Blueprints screen looks like the graphic above. We currently have one Blueprint created. There could be a number of Blueprints for different iPad configurations. We are only using one for our Student Checkout iPads. When the Blueprint has been selected it will provide an overview of the different actions that are configured to run.
To make changes to the Blueprint, Select Edit.
General
In this window, we have all the options that we can perform on the iPad. The General page is the main page for iPad management. Even though it is the first page, it should be the last page to apply settings. The options are:
Name: Name the Blueprint “Student iPads”. This is important to the automation that it be named this.
Device Type: The device type doesn’t matter and won’t stop iPhones from being erased and configured if a person in our service area unwittingly attaches their iPhone to get an extra charge. We posted signs warning about this potential issue and as far as we know this never has happened.
WiFi Profile: This is a critical setting as it allows the iPad to connect to the internet to get the configuration from the Jamf Server. Select the WiFi Profile that was configured in the Profile Setting of the Blueprint.
Seconds to wait to let devices acquire WiFi connection: This needs to be set to the highest so that it allows the iPads enough time to connect to the Jamf Pro server.
MDM and DEP Enrollment: Jamf Pro holds are the base configuration that we need for the iPads. Select “Apply configuration from DEP (will erase devices)” and enter your Credentials to connect to the Jamf Pro server. Any of the other options won’t work since it needed to communicate to the Jamf Pro server for activation.
Organization & Supervision
Next, we use this option to customize our Supervision Identity from our Jamf Pro server.
This is what a default setting looks like before setting the Supervision Identity. To add a new Supervision Identity:
Click on the Organization & Supervision tab.
Under Organization, in the dialog box select Choose.
A new Organization window will show to allow the creation of a new Identity or pick an existing one.
Create a new Identity by selecting the Plus “+” button.
This is where you would fill out the information if you wanted iMazing to supervise the devices. Fill out the information but don’t create a new Supervision Identity. It will not connect to the Jamf Pro properly and will cause other errors with the setup.
Next, we retrieve the Supervision Identify from the Jamf Pro server and is password protected. With the Supervision Identity p12 and the password, we can add it to iMazing.
Near the bottom of the New Organization window, there is a dialog box for Supervision Identity.
Select Choose existing PKCS 12 and select the Supervision Identify file.
Select Choose
With the Supervision Identity selected, the options become available.
We needed to Supervise the device to allow the iPad to be managed and updated by iMazing. Storing the passcode allows the iPad to be unlocked when a Patron sets a password on the iPad and returns it without clearing it. In the past, we would have to use Apple Configurator to restore the iPad. The process took a little bit of time and we weren’t able to reset any iPads turning that time. By saving the passcode to unlock the token to the keychain, we can pass the token to the iPad when it is returned.
Setup & Accessibility
This page is a replication of the Jamf Pro PreStage Enrollment page. Most of the settings will not be used as they are configured by Jamf. The settings that can be set are Device Name, Language & Region, and the Wallpapers. The rest are controlled by Jamf Pro.
The device name that is set is a variable that is pulled down by Jamf. By entering the variable “{device_name}” it will populate the correct name from the Jamf Pro server. If the iPad comes back from being imaged with “iPad” as a name, check the iPad’s record in Jamf.
Set the Language and Region. Set English and the United States for the options.
In Wallpapers is the place to set the images that we want at the Lock Screen and the Home Screen. They can be 2 separate images or the same one. The iPad images currently have the 50 years of Marriott Library with the All U Need graphic. This can be updated at any time. Below is what our production iPads are currently using.
The rest of the options we aren’t going to cover since we configure them with Prestage Enrollment on our Jamf Pro server.
The device name that is set is a variable that is pulled down by Jamf. By entering the variable “{device_name}” it will populate the correct name from the Jamf Pro server. If the iPad comes back from being imaged with “iPad” as a name, check the iPad’s record in Jamf.
Set the Language and Region. Set English and the United States for the options.
In Wallpapers is the place to set the images that we want at the Lock Screen and the Home Screen. They can be 2 separate images or the same one. The iPad images currently have the 50 years of Marriott Library with the All U Need graphic. This can be updated at any time. Below is what the production iPads currently use.
The rest of the options on this page I’m not going to cover since we configure them with Prestage Enrollment in Jamf.
Actions
The actions page allows you to perform actions that we can only do to an iPad that is connected. Some of the actions are only for iPads that are Supervised. This allows us to restore control of the iPad after the patron returned it. We can easily remove any passcodes and erase the iPad so that it can be returned fresh imaged state. The actions are split out into 3 different sections: Pre-Configuration, Configuration, and Post-Configuration.
The Pre-Configuration actions are the first steps to making the iPads ready for the next patron. Since the iPads are Supervised we can clear both passcodes on the device without having to manually restore the iPad like we have had to do in the past. With the iPad passcode removed we can erase and reset up the iPads. During major iOS version upgrades, we can turn on a feature that updates the iPad to the latest version before erasing it.
Here is a list of the Pre-Configuration actions that we have set up. “Erase all data and settings” is an MDM configured setting. It will be grayed out if you have “Apply MDM Configuration” in General. We want to prevent proximity setup since there is a lot of already configured iPads in the same space and could cause potential issues.
The Configuration actions are the meat of the iMazing configuration. This is where MDM Enrollment, supervision identity, WiFi Profile, and our set of Apps are applied. This can be found in the other pages below Actions.
The Post-Configuration actions help with finishing the setup of the iPads.
For our iPads, we use the “Skip Setup Assistant” and “Shut Down device”. With our USB hub only having 16 ports, we can’t have all of our iPads plugged in at once. To conserve the battery on the iPad we shut down the iPad when it has finished imaging.
Adding Apps
The Apps page is used to configure what Apps the iPads get. Currently, we are deploying 20 different Applications to the iPads. But allow students to add applications if needed using their Apple ID when iPad is checked out.
To configure Apps for the iPads, our Apple School Manager account has to be configured with iMazing. Configuration of the Apple School Manager account is done outside of the Blueprint building. To configure the Apple School Manager account it can be found in the iMazing Apple School Manager account setup section.
The Apps page in the Blueprint starts blank. Sign-in with the Apple ID used when the Apple School Manager account.
Apps
Similar to Blueprints, Apps is the main page for our App collection. It controls what Apps are available on the Apps page in Blueprints, how many of the licenses are in use, and the version numbers.
Select Apps
If it is the first time accessing the Apps page it will greet you with the managed Apple ID sign-in.
To download the apps locally click on the cloud download button. 
To remove an app, click on the trash can button. 
Blueprints are not the only way to install apps on iPads. You can use the Install Apps button to custom install the App on any connected iPads. When a Blueprint is applied to the iPad again, the app won’t be there.
Automation
Since we wanted to keep our iMazing station in a “kiosk mode” we had to add a few scripts to automate processes to keep the system operational limited care & feeding by our team. For the time being, AppleScript remains one component of macOS automation technologies, along with Automator, Shortcuts, Services, and shell scripting. Starting in macOS Monterey, Automator is being replaced by Shortcuts So, the long term viability and need for AppleScript is and doubt, but can is still useful to implement when there are no other alternatives. iMazing has some AppleScript supports but does not support every task we wanted to automate. You can often work around such limitations by writing a user interface AppleScript, commonly called a UI or GUI script. A user interface AppleScript simulates user interaction, such as mouse clicks and keystrokes, allowing the script to select menu items, push buttons, enter text into text fields, and more.
UI Browser
A good utility to aid in the discovery and creation of AppleScript UI scripts is the UI Browser. You can use UI Scripting even if the target application does not support AppleScript. UI Browser understands the arrangement of an application’s UI elements and knows their AppleScript names and index numbers. It enables you to navigate the Accessibility hierarchy and generate useful UI Scripting statements with a single click.
Enabling User Interface Scripting
User interface scripting relies upon the macOS accessibility frameworks that provide alternative methods of querying and controlling the interfaces of apps and the system. By default, accessibility control of applications is disabled. For security and privacy reasons, the user or MacAdmin must manually enable or on managed systems pre-approve them on an app-by-app including AppleScript applications. UI Browser 3 is a Universal application and runs on macOS Sierra 10.12 or later and verified through macOS Monterey 12.
Enable Accessibility Control for an AppleScript Application
- Launch System Preferences and click Security & Privacy.
- Click the Privacy tab.
- Click Accessibility.
- Click the Add button (+).
- Choose the AppleScript applications (i.e. “Close iMazing” & “Reset iMazing”) and click Open.
- Select the checkbox to the left of each AppleScript application.
Pre-Approve AppleScript Applications
MacAdmins can pre-approve the AppleScript applications with a Privacy Preferences Policy Control (PPPC) configuration profile. PPPC configuration profiles can only be managed when pushed from a Mobile Device Management (MDM) solution like Jamf Pro.
You can build such a configuration profile manually, but it is much easier & less error-prone to use one of the tools listed below to build them:
Custom AppleScripts
Below are examples of two AppleScript we create applications to aid in customization and automation of our iMazing Configurator system.
Verify UI Scripting Enabled
This AppleScript requires UI scripting to be enabled, you can verify if your system is or is not enabled with this AppleScript:
tell application "System Events"
return UI elements enabled
end tell
If it returns “false” UI scripting isn’t enabled, and you need to enable it on the system you want to use below AppleScript.
Close iMazing
This AppleScript clicks a blocking window to properly close the iMazing application:
tell application "System Events"
tell process "iMazing"
try
click button "Done" of window "iMazing"
end try
end tell
end tell
Reset IMazing
The following AppleScript uses the actions of the “AXFullScreenButton” to set iMazing into full-screen mode:
- “AXZoomWindow” action to maximize.
- “AXPress” action to full screen.
It also does additional house cleaning with iMazing to aid in resetting to our default desired state.
-- Use this script as a wrapper for GUI Scripting statements to aid and resetting iMazing
activate application "iMazing"
try
tell application "System Events"
perform action "AXZoomWindow" of (first button whose subrole is "AXFullScreenButton") of (first window whose subrole is "AXStandardWindow") of (first process whose frontmost is true)
end tell
end try
tell application "System Events"
tell process "iMazing"
try
click button "Done" of window "iMazing"
end try
delay 60
click menu item "Blueprints" of menu 1 of menu item "Library" of menu 1 of menu bar item "Configurator" of menu bar 1
delay 5
click button "Apply Blueprint" of window "iMazing"
delay 5
--click pop up button 1 of window "iMazing"
tell pop up button 1 of window "iMazing"
click
delay 1
click menu item "Automatically on all devices connected via USB" of menu 1
end tell
delay 1
click button "Continue" of sheet 1 of window "iMazing"
delay 1
click button "Apply Blueprint" of sheet 1 of window "iMazing"
end tell
end tell
Workflow Process Overview
The Future
In the future, we will be evaluating implementing different methodologies in managing our student iPads.
Jamf Setup & Reset
Two possible options from Jamf our Jamf Setup and Jamf Reset:
Jamf Setup gives a new option between generic configurations and an Apple’s Shared iPad. A single device supports multiple customized use-cases. This creates a more flexible shared device. It provides an intuitive way for end-users to receive relevant apps and settings – no direct IT involvement is required. Lastly, it provides an over-the-air workflow with no need for additional hardware. Users do not need a username or password, software, or another directory service. This enables one-time guest use.
Jamf Reset does not need additional integrations or warehouse re-provisioning. This workflow is repeatable and reliable. It provides a user-initiated wipe that allows users themselves to digitally sanitize devices, with Home screen access to wipe the device. It creates an over-the-air workflow with no additional hardware required. Troubleshooting can be done with one tap by resetting the device. This creates a scalable re-provisioning process.
Jamf Setup and Jamf Reset support a new Single Login workflow that simplifies and secures frontline shared-device deployments. With Single Login, a user’s Azure cloud identity credentials can be used to instantly provision/de-provision an iOS or iPadOS device for their individual needs, wirelessly and without IT interaction. The interaction with Single Login using a user’s Azure cloud identity credentials is attractive, but currently, our campus doesn’t have this setup that could be used in production. When configuring the Jamf Reset application, IT Admins can choose to have the “Reset” option below either erase all contents and settings or simply a soft reset. The soft reset clears all the local data and if configured to use SSO or the Single Login workflow, logs out the previous users from any of the applications that were automatically logged in. This allows for a quick “shift” change, while also keeping user data specific to that user without requiring an erase all contents and settings option.
These tools are probably not ideal for our environment and short-term student checkout use case, where the setup & reset functionality would be distributed to either our busy & often untrained student service counter staff or to the student using the iPad on checkout or return of the device. We might implement Jamf Setup & Reset for our staff/faculty iPad distribution where these use case better meets the benefits of these tools.
These solutions tend to be more beneficial in environments with frontline shared-device deployments like healthcare, etc. with defined work scheduled and roles with employees.
Shared iPad
Another possible option is Apple’s Shared iPad feature which allows multiple users can use the iPad, and the user experiences can be personal even though the devices are shared. Shared iPad requires a mobile device management (MDM) solution and Managed Apple IDs that are issued and owned by the organization. Users with a Managed Apple ID can then sign in to Shared iPad, which is owned by the organization. For roles and privileges, you’ll need someone to create the account, and then depending on if they are a student, teacher, manager, etc. they will have different means of handling and assisting with the shared iPads. Devices must have at least 32 GB of storage and be supervised.
Our devices have 64 GB of storage and are supervised, and there are concerns that the ideal user space with Share iPads would not meet the needs of our student environment. Also, our campus currently can’t support Managed Apple IDs or federation into Azure AD.
Shared iPad Temporary Session
Another option with Shared iPads is the feature of a “Temporary Session” where any user has the ability to initiate a temporary session without the need for a user name or password by tapping Guest at the login screen. All their data—including browsing history—is deleted when the user signs out. In a temporary session, any user can unlock and access the iPad without a password. Users working in a temporary session should take this into account if they’re signed in to any websites or apps. Because a Managed Apple ID isn’t required, apps that use or require iCloud or cloud-based storage may not be supported.
Our student environment implements many cloud-based storage solutions from DropBox, OneDrive, GoogleDrive, etc. And we like providing the ability to allow students to log in with their Apple ID to download edge case needed applications and not restricting all software to Self Service and upkeep by or MacAdmin team. We try to provide updated core applications that are used by students, but due to limitations on disk space, we try to limit them based on usage and available free space on devices.
Alma Integration
Since we are the main library at the University of Utah, we are using Alma to check out all our student laptops, iPad, and other devices. Ex Libris Alma is a library software system (ILS)for managing the acquisition, sharing, cataloging, and use of all kinds of resources, including physical and electronic books, physical and electronic periodicals, and digital resources (such as audio, image, and video files). We are investigating the possibility of using its API or webhooks functionality to provide desired functionality for our student iPad management or maybe student MacBook management. Alma supports webhooks to enable the efficient processing of events like when a device is checked back in by a student, which in turn could initiate erasing user content & data with our direct interaction of the device outside checking the device back into our library software system (ILS) which they currently are doing with iMazing & Jamf Pro managed systems.
Internally, there might be a few challenges to gaining access & project focus time to the API & webhooks to development integrations, because in the library world view our student checkout devices might be considered a lower priority in reference to other library resources.
No Comments