Enrolling iPads and iPhones into JAMF’s Casper suite can be done through Apple Configurator 2, text messages, email invitations, Apple’s Device Enrollment Program (DEP), or using links deployed to iOS devices as web clips. When doing larger deployments the enrollment process can be automated so that devices are automatically enrolled into Casper when set up using an Enrollment Profile that is manually downloaded from Casper and deployed to device. Additionally, a certificate can be needed if the certificate is not included in the profile, an option available as a checkbox in the setup. While you hopefully won’t need to download the certificate, we’ll cover that as well:
Download the Enrollment Profile
To download an enrollment profile from Casper MDM:
Add the Profile To Apple Configurator:
To deploy the profile through Apple Configurator:
If you then wish to unenroll, simply remove the profiles by tapping on profiles and then tapping on the Remove button. Per the MDM API, a user can elect to remove their device from management at any point unless the device is supervised (and then it’s harder but still possible to remove the device from management), so expect this will happen occasionally, even if only by accident.
krypted December 10th, 2015
Apple Configurator has now been in my grubby hands long enough for me to start looking at it a little deeper than I did in the introductory article I did awhile back. Architecturally, Apple Configurator keeps its data in ~/Library/Application Support/com.apple.configurator. Here, you’ll find a directory called IPSWs, another called Resources, file called AppleConfigurator.storedata and another called Users.storedata.
The IPSWs directory is where operating system versions, per model of iOS are stored. These look something like iPad2,1_5.1_9B176_Restore.ipsw, which is iOS 5.1 for a standard iPad 2. iPad 1, the retina display iPad, as well as each iPod Touch and iPhone 4 each have their own entry as well. The IPSWs are automatically downloaded here when you initially perform a restore using Apple Configurator for each model of iOS device. You can copy each model’s ipsw into this directory proactively to keep Apple Configurator from downloading updates. You can also populate this directory manually with older copies of iOS if you are running them or if you are a developer, with developer releases of ipsw files.
The Resources directory is going to house applications and documents/content that you’ll be pushing to devices if you use the Assign options to assign content (and possibly other assets, although thus far I seem to only be getting apps and documents in here). They don’t look like applications or documents though. Each entry in this directory is assigned a generated identifier. The size of each and date/time stamp should match the size of the object and when it was added to Apple Configurator, respectively. When you delete an application or document from Apple Configurator then you should see the entries here disappear. Running strings against the entries that are applications, you should be able to identify which is which pretty quickly. Running such commands against documents (or other assigned content) can net much spottier results due to the fact that there aren’t always references to what you’re looking at inside of what you’re looking at… Either way, just looking at the raw data that comprises these application and content objects isn’t the only way to grab the name of the file. We’ll take a look at that a little later.
In addition to these two directories, Apple Configurator can throw data almost anywhere because it allows users to do so when creating backups of devices. These backups are in the form of files ending with .iosdevicebackup and by default getting placed into ~/Documents. When these are created, they can be saved to any location you choose. Deleting them from the file system automatically causes Apple Configurator to forget about them (although I have had to restart the application after removing the .iosdevicebackup file).
And then there’s the databases. As I mentioned, there are two, AppleConfigurator.storedata and Users.storedata. These are both sqlite databases and are both accessible through standard sqlite3 commands/queries. I haven’t been able to find any documentation of what each table is used for, but I’ve run devices through a number of regressions and think I’ve mostly pieced it together, which I’m in some cases able to back up with writing directly to the SQL table. Each database consists of the following tables (although not all are used and in some cases they are used for different purposes in each database), which I show followed by a description of what I think each is doing along with the more important columns of each table:
Now that we know roughly what’s where, let’s put that to use. Let’s start with just getting some information on what profiles are installed in Apple Configurator. Here, we can run a SQL select to look at all the rows in the ZPROFILE table, by calling the sqlite3 command (in /usr/bin), using the SQL table as our first position and then putting our select query in quotes, which in this case is to select all (*) information from the ZPROFILE table:
sqlite3 ~/Library/Application Support/com.apple.configurator/AppleConfigurator.storedata 'SELECT * FROM ZPROFILE'
To export a profile from Apple Configurator’s database using sqlite3 (which means you can do this from a centralized location), use the sqlite3 command, selecting the database and then run a select for the ZPROFILE table, selecting the ZNAME record called Pretendco Deployment and then send the output to a file called test.mobileconfig:
sqlite3 ~/Library/Application Support/com.apple.configurator/AppleConfigurator.storedata 'SELECT * FROM ZPROFILE WHERE ZNAME = "Pretendco Deployment"' > test.mobileconfig
Strip the first line of that file out and you’ve got yourself a mobileconfig file.
To see all of your applications:
sqlite3 ~/Library/Application Support/com.apple.configurator/AppleConfigurator.storedata 'SELECT * FROM ZMOBILEAPPLICATION'
Or if that’s too much output (it is), then just look at the names of the apps:
sqlite3 ~/Library/Application Support/com.apple.configurator/AppleConfigurator.storedata 'SELECT ZNAME FROM ZMOBILEAPPLICATION'
These are just a few light queries. You could easily expand on this to export all of the profiles as mobileconfigs, dump a list of each iOS device that has each app installed, a list of which users have which devices, which users have which apps, which devices are running low on disk space, etc. Overall, the sqlite queries are similar in nature (or can be) to what we were doing in the scripting iPhone Configuration Utility article I did awhile back; however, there are a lot more options here.
krypted March 28th, 2012
Tags: Apple Configurator, developer, documents, iOS 5, iosdevicebackup, iPad, iphone configuration utility, ipsw, Lion, location, Open Directory, path, payload, profile, scripting, select where, sqlite3, user, ZMOBILEAPPLICATION, ZUSER, ZVERSION
When I install a new system that I am personally going to be using, one of the few tweaks I make is to configure the Finder to show me paths in the title bar. This just keeps me from the occasional Command-click on the folder name and keeps me abreast of where I am. Mostly it’s helpful in list or icon view as. To enable full paths
use defaults to write an _FXShowPosixPathInTitle key into com.apple.finder.plist. The key should be boolean and we’re setting it to true. After about 30 seconds new windows should show with the path in the title bar:
defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES
I actually add this to my user template at imaging time for my personal system workflow, so that I don’t even have to think about it… So I almost forgot how to do it. Luckily, a quick peak at my user template reminded me when I was building a new imaging environment for Lion… If you decide it isn’t for you, feel free to set it back by setting the key to NO:
defaults write com.apple.finder _FXShowPosixPathInTitle -bool NO
krypted July 27th, 2011
Posted In: Mac OS X