Some iOS and/or OS X deployments require us to create a boatload of Apple IDs. This could be to redeem VPP codes, to do iOS backups, to configure Messages, now giving the ability for OS X Server users to password reset for themselves, etc. I have sat and manually created Apple IDs for a number of clients. I’ve created dozens at a single sitting and there are some serious annoyances and challenges with doing so manually. For example, you’re gonna’ fat finger something. If you type 10 things in for 50 accounts then it’s hard to imagine you’re not gonna’ mess something up in one of those 500 fields. It’s also time consuming and well, just annoying.
Then, along came a script. That script allowed us to create loads of IDs on the fly. Now, we have a very nice GUI tool called the Apple ID Automation Builder that can be used to batch create a number of Apple IDs on the fly. Brought to us by Greg Moore and hosted by enterpriseios.com, this is one of those rare finds that is a serious time saver and very valuable when you need it in your bat belt. Great little tool, well worth the money and I look forward to providing Greg with plenty of accolades should we ever meet!
krypted May 12th, 2013
The Volume Purchasing Program is a program from Apple that allows you to buy gift codes en masse for distribution to users, either by mail merging them and sending them out or using a special tool for distribution, such as Apple Configurator or an MDM solution. If you’re in the United States and work with iOS, you’ve likely been using the Volume Purchasing Program for awhile. But for users in Australia, Canada, France, Germany, Italy, Japan, New Zealand, Spain and the United Kingdom, the Volume Purchasing Program is new and probably being well received.
The Volume Purchasing Program allows users to receive the codes and install/purchase software without being gifted money to do so, although in most cases the users will need Apple IDs. This is because the Volume Purchasing Program still requires codes to be redeemed, although if you’re using Apple Configurator you can deploy apps without tying them to unique AppleIDs.
Overall, the Volume Purchasing Program is a great way to be able to control and manage app expenditures, and for users in the newly added countries, will help with deployments large and small. To access the Volume Purchasing Program site, see http://www.apple.com/business/vpp. To quote Apple:
Deliver essential business apps to your employees with the Volume Purchase Program, now available in Australia, Canada, France, Italy, Germany, Japan, New Zealand, Spain, the UK, and the US. VPP makes it easy to purchase iOS apps in any quantity and distribute them to your users. You can also have custom apps built for your company’s unique needs. Search thousands of useful apps, specify any quantity, and use a corporate credit card to complete your purchase. Download the updated VPP Guide for details.
krypted September 5th, 2012
Posted In: iPhone
Tags: Apple Configurator, AppleID, australia, canada, England, france, germany, ios, iPad, iPhone, ipod touch, Italy, japan, mdm, new zealand, spain, UK, united Kingdom, volume purchasing program, vpp
Push Notifications can be used in most every service OS X Mountain Lion Server can run. Any service that requires Push Notifications will provide the ability to setup APNS during the configuration of the service. But at this point, I usually just set up Push Notifications when I setup a new server.
To enable Push Notifications for services, you’ll first need to have a valid AppleID. Once you have an AppleID, open the Server app and then click on the name of the server. At the Overview screen, click on Settings.
At the Settings screen for your server, click on the check-box for “Enable Apple push notifications.”
At the Apple Push Notification Services certificate screen, enter an AppleID if you have not yet configured APNS and click on OK. The Apple Push Notification Service certificate will then be configured.
The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. To renew, open the same screen and click on the Renew button.
Enter the credentials for the AppleID again and then click on Renew Certificate button. The certificate will then be valid for another year.
krypted August 19th, 2012
Profile Manager first appeared in OS X Lion Server as the Apple-provided tool for managing Apple devices, including Mobile Device Management (MDM) for iOS based devices as well as Profile management for OS X based computers, including MacBooks, MacBook Airs, Mac Minis, Mac Pros and iMacs running Mac OS X 10.7 and up. In OS X Mountain Lion, Apple has added a number of new features to Profile Manager, most notably the ability to push certain types of apps to mobile devices.
In this article, we’re going to look at setting up Profile Manager from scratch. If you’re upgrading to OS X Mountain Lion Server (10.8 Server) from OS X Lion Server (10.7 Server) then review this link for upgrade instructions.
Preparing For Profile Manager
Before we get started, let’s prep the system for the service. This starts with configuring a static IP address and properly configuring a host name for the server. In this example, the IP address will be 192.168.210.135 and the hostname will be mlserver3.pretendco.com. We’ll also be using a self-signed certificate, although it’s easy enough to generate a CSR and install it ahead of time. For the purposes of this example, we have installed Server from the App Store (and done nothing else with Server except open it the first time so it downloads all of its components from the web) and configured the static IP address using the Network System Preferences. Next, we’ll set the hostname using scutil.
sudo scutil --set HostName mlserver3.pretendco.com
Then the ComputerName:
sudo scutil --set ComputerName mlserver3.pretendco.com
And finally, the LocalHostName:
sudo scutil --set LocalHostName mdm
Now check changeip:
sudo changeip -checkhostname
The changeip command should output something similar to the following:
Primary address = 192.168.210.135
Current HostName = mlserver3.pretendco.com
DNS HostName = mlserver3.pretendco.com
The names match. There is nothing to change.
dirserv:success = "success"
f you don’t see the success and that the names match, you might have some DNS work to do next, according to whether you will be hosting DNS on this server as well. If you will be hosting your own DNS on the Profile Manager server, then the server’s DNS setting should be set to the IP address of the Server. To manage DNS, start the DNS service and configure as shown in the DNS article I did previously:
Provided your DNS is configured properly then changeip should work. If you’re hosting DNS on an Active Directory integrated DNS server or some other box then just make sure you have a forward and reverse record for the hostname/IP in question.
Now let’s open the Server app from the Applications directory. Here, use the Next Steps drawer at the bottom and verify that the Configure Network section reads that “Your network is configured properly” as can be seen here:
Profile Manager is built atop the web service, APNS and Open Directory. Therefore, let’s close the Next Steps drawer, click on the Web service and just hit start. While not required for Profile Manager to function, it can be helpful. We’re not going to configure anything else with this service in this article so as not to accidentally break Profile Manager. Do not click on anything while waiting for the service to start. While the indicator light can go away early, note that the Web service isn’t fully started until the path to the default websites is shown (the correct entry, as seen here, should be /Library/Server/Web/Data/Sites/Default) and a View Server Website link is shown at the bottom of the screen. If you touch anything too early then you’re gonna’ mess something up, so while I know it’s difficult to do so, be patient (honestly, it takes less than a minute, wait for it, wait for it, there!).
Once the Web service is started and good, click on the View Server Web Site link at the bottom and verify that the Welcome to Lion Server page loads.
Setting Up Profile Manager
At the first screen of the Configure Device Management assistant, click on Next.
Assuming the computer is not yet an Open Directory master or Replica, and assuming you wish to setup a new Open Directory Master, click on Create a new Open Directory domain at the Configure Network Users and Groups screen. Then click on Next.
At the Directory Administrator screen, provide the username and password you’d like the Open Directory administrative account to have (note, this is going to be an Open Directory Master, so this example diradmin account will be used to authenticate to Workgroup Manager if we want to make changes to the Open Directory users, groups, computers or computer groups from there). Once you’re done entering the correct information, click Next.
At the Organization Information screen, enter your information (e.g. name of Organization and administrator’s email address). Keep in mind that this information will be in your certificate (and your CSR if you submit that for a non-self-signed certificate) that is used to protect both Profile Manager and Open Directory communications. Click Next.
At the Confirm Settings screen, make sure the information that will be used to configure Open Directory is setup correctly. Then click Set Up (as I’ve put a nifty red circle next to – although it probably doesn’t help you find it if it’s the only button, right?).
The Open Directory master is then created. Even if you’re tying this thing into something like Active Directory, this is going to be a necessary step. Once Open Directory is setup you will be prompted to provide an SSL Certificate.
This can be the certificate provided when Open Directory is initially configured, which is self-signed, or you can select a certificate that you have installed using a CSR from a 3rd party provider. At this point, if you’re using a 3rd party Code Signing certificate you will want to have installed it as well. Choose a certificate from the Certificate: drop-down list and then click on Next.
If using a self-signed certificate you will be prompted that the certificate isn’t signed by a 3rd party. Click Next if this is satisfactory.
You will then be prompted to enter the credentials for an Apple Push Notification Service (APNS) certificate. This can be any valid AppleID. It is best to use an institutional AppleID (e.g. firstname.lastname@example.org) rather than a private one (e.g. email@example.com). Once you have entered a valid AppleID username and password, click Next.
Provided everything is working, you’ll then be prompted that the system meets the Profile Manager requirements. Click on the Finish button to complete the assistant.
When the assistant closes, you will be back at the Profile Manager screen in the Server application. Here, check the box for Sign Configuration Profiles.
The Code Signing Certificate screen then appears. Here, choose the certificate from the Certificate field.
Unless you’re using a 3rd party certificate there should only be one certificate in the list. Choose it and then click on OK. If you are using a 3rd party certificate then you can import it here, using the Import… selection.
If you host all of your services on the one server (Mail, Calendars, VPN, etc) then leave the box checked for Include configuration for services; otherwise uncheck it.
Now that everything you need is in place, click on the ON button to start the service and wait for it to finish starting.
Once started, click on the Open Profile Manager link and the login page will open. Adminsitrators can login to Profile Manager to setup profiles and manage devices.
The URL for this (for mlserver3.pretendco.com) is https://mlserver3.pretendco.com/profilemanager. Use the Everyone profile to automatically configure profiles for services installed on the server if you want them deployed to all users. Use custom created profiles for everything else.
Enrolling Into Profile Manager
To enroll devices for management, use the URL https://mdm.pretendco.com/MyDevices (replacing the hostname with your own). Click on the Profiles tab to bring up a list of profiles that can be installed manually.
From Profiles, you’ll need to install a Trust profile in order for the client to enroll. Tap or click on the Install button for the Trust Profile and complete the installation process.
Click back on the Devices tab. From here, click or tap on the Enroll button and complete the enrollment process on the client (following the defaults will suffice).
On the devices, you’ll then be prompted to install the profile. On iOS tap Install then Install then Done. On OS X, click Continue, then Install.
Once enrolled, you can wipe or lock the device from the My Devices portal. Management profiles from the MDM server are then used. Devices can opt out from management at any time. If you’re looking for more information on moving Managed Preferences (MCX) from Open Directory to a profile-based policy management environment, review this article.
If there are any problems when you’re first getting started, an option is always to run the wipeDB.sh script that resets the Profile Manager (aka, devicemgr) database. This can be done by running the following command:
Automating Enrollment & Random Management Tips
The two profiles needed to setup a client on the server are accessible from the web interface of the Server app. Saving these two profiles to a Mac OS X computer then allows you to automatically enroll devices into Profile Manager using Apple Configurator, as shown in this previous article.
When setting up profiles, note that the username and other objects that are dynamically populated can be replaced through a form of variable expansion using payload variables in Profile Manager. For more on doing so, see this article.
Note: As the database hasn’t really changed, see this article for more information on backing up and reindexing the Profile Manager database.
Once you’ve got devices enrolled, those devices can easily be managed from a central location. The first thing we’re going to do is force a passcode on a device. In this case, it’s an iPad. We’re going to click on the device in Profile Manager’s admin portal, located at https://<SERVERNAME>/profilemanager (in this case https://mdm.pretendco.com/profilemanager).
From the device (or user, group, user group or device group objects), click on the Profile tab and then click on the Edit button.
Here, you can configure a number of settings on devices. There are sections for iOS specific devices, OS X specific settings and those applicable to both platforms. Let’s configure a passcode requirement for an iPad. Click on Passcode, then click on Configure.
At the Passcode settings, let’s check the box for Allow simple value and then set the Minimum Passcode Length to 4. I find that with iOS, 4 characters is usually enough as it’ll wipe far before someone can brute force that. Click OK to commit the changes. Once configured, click Save.
At the “Save Changes?” screen, click Save. The device then prompts you to set a passcode a few moments later.
The next thing we’re going to do is push an app. To do so, first find an app in your library that you want to push out. Right-click (or control-click) on the app and click on Show in Finder. You can copy the app from your library or browse to it at the location it is in later.
Then, from the https://<SERVERNAME>/profilemanager portal, click on an object to manage (in this case it’s a group called Demo) and click on the Apps tab.
From the Apps tab, click on the cog wheel icon and then click on Edit Apps.
At the Add Apps screen, click on upload and then browse to the app we found earlier.
The app is then uploaded and displayed in the list. Click Add to add to the selected group. Then, click on Done. Then click on Save… and an App Installation dialog will appear on the iOS device you’re pushing the app to.
At the App Installation screen on the iPad, click on the Install button and the app will instantly be copied to the last screen of apps on the device. Tap on the app to open it and verify it works. Assuming it does open then it’s safe to assume that you’ve run the App Store app logged in as a user who happens to own the app. You can sign out of the App Store and the app will still open. However, you won’t be able to update the app as can be seen here.
This brings up an interesting limitation of how Profile Manager interacts with the App Store. It kinda’ doesn’t. If I were pushing apps to elementary school iPads in a 1:1 I could either use Apple Configurator (if I wanted to burn up a VPP code per student per year) or I could use iTunes (if I wanted a labor intensive process of restoring an iPad per computer rather than a parallel process). But either way, I’m gonna’ stay away from Profile Manager for apps.
So if you push an app to a device and the user taps on the app and the screen goes black then make sure the app is owned by the AppleID signed into the device. If it is, have the user open App Store and update any other app and see if the app then opens.
Finally, let’s wipe a device. From the Profile Manager web interface, click on a device and then from the cog wheel icon at the bottom of the screen, select wipe.
At the Wipe screen, click on the device and then click on the Wipe button again. The iPad then says Resetting iPad and just like that, the technical walkthrough is over.
Note: For fun, you can use the MyDevices portal to wipe your iPad from the iPad itself.
So where are all these new features that justify a new version number? To quote Apple’s Profile Manager 2 page:
Profile Manager simplifies deploying, configuring, and managing them all. It’s one place where you control everything: You can create profiles to set up user accounts for mail, calendar, contacts, and messages; configure system settings; enforce restrictions; set PIN and password policies; and more. Because it’s integrated with the Apple Push Notification service, Profile Manager can send out updated configurations over the air, automatically. And it includes web-based administration, so you can manage your server from any modern web browser. Profile Manager even gives users access to a self-service web portal where they can download and install new configuration profiles, as well as clear passcodes and remotely lock or wipe their Mac, iPhone, or iPad if it’s lost or stolen.
Wait, it did that before… Which isn’t to say that for the money, Profile Manager isn’t an awesome tool. Apps such as Casper MDM, AirWatch, Zenprise, etc all have far more options, but aren’t as easy to install and nor do they come at such a low price point. Profile Manager is a great option if all of the tasks you need to perform are available within the tool. If not, then it’s worth a look, if only as a means to learn more about the third party tools you’ll ultimately end up using. One thing I can say for it is that Profile Manager is a little faster and seems much more stable (in fact, Apple has now published scalability numbers, which they have rarely done in the past). You can also implement newer features with it, including Gatekeeper and Messages.
krypted August 12th, 2012
Tags: 1:1, add apps, Airwatch, app installation, App Store, Apple Configurator, AppleID, automate enrollment, Casper MDM, certificate, check task status, configure Mobile Device Management, Enrollment, ios, iPads, iPhone, Mac OS X Server, mdm, mountain lion, mountain lion server, MyDevices, one to one, os x 10.8 server, passcode, passcode requirement, profile manager 2, push apps, set pin code, trust certificate, what changed in Mountain Lion Server, wipedb.sh, Zenprise
My traditional interpretation of Apple’s vision on how iOS devices are used is that everyone has an AppleID. That AppleID enables them to access their apps from any iOS device they own or Mac that they own. That AppleID enables them to access mail, contacts, calendars and even files through iCloud. That AppleID also allows users to remotely wipe their device through Find iPhone and track their friends iOS devices (as in social networking via breadcrumb tracking) through Find Friends. All of this “Just Works” in a consumer sense. And it even allows for a little sharing of content across devices you own. However, larger organizations need more. They need centralized management, content distribution and most other things you find that you rely on traditional desktop computers for.
Over the years, Apple has added tools for centralized control of devices. This started with ActiveSync compatibility and early forms of Mobile Device Management and has grown into a pretty robust, albeit disconnected, set of tools. Of these, Apple Configurator is the latest. Apple Configurator was released about a week ago and since, I’ve been trying to figure where it fits into the solutions architecture that surrounds iOS integrations. There are a number of other tools already available that can aid in the deployment and management of iOS devices, and Configurator is a great addition.
To me, there are 3 classes of management tools for iOS. These were roughly broken up into Over the Air (OTA), cradled (USB) and content management. Apple Configurator ends up fitting into all of these scenarios in some way. Let’s start by looking at the traditional uses of these three and then look at how they are impacted by Apple Configurator.
Mobile Device Management
Over the Air tools, such as Profile Manager, allow for Mobile Device Management (MDM) without cradling, or syncing a devices. These tools allow you to configure policies via profiles. There is also a bit of App pushing built into most MDM solutions. Apple’s Profile Manager can push applications written in-house, but no content from the App Store. 3rd party solutions, such as JAMF’s Casper Suite, Absolute Manage MDM, AirWatch and about 15 others are able to push apps from the App Store as well, leveraging the Volume Purchasing Program (VPP) to issue apps to devices. However, when an app is pushed through one of these tools, the app becomes associated with the AppleID for the user who owns the device.
Note: While we use the term push, the user has to accept all App installations on the device.
For large environments, MDM is a must as it allows for centralized command and control. Pushing apps is one aspect of such control. Policies enforceable through MDM include disabling cameras, configuring passcode policies on devices (not pushing passcodes), disabling YouTube, silencing Siri, unstreaming photos, disabling iCloud Backup, forcing encrypted backups, disabling location services, controlling certificates, blocking pop-ups, controlling cookies, disabling access to the iTunes and App Stores, and controlling what kind of media can be accessed on devices.
Additionally, MDM can be used to push SSIDs for wireless networks (and their passwords/802.1x configuration information), setup mail, setup Exchange ActiveSync, configure VPN connections, configure access shared calendars (iCal shared files, CalDAV and Exchange), configure access to shared contacts (LDAP, CardDAV, Exchange and Exchange Global Address Lists), deploy Web Clips and manage certificates (either with cert files or via SCEP). In short, whether you’re using the practically free Profile Manager from Apple, Mobile Iron, Casper, AirWatch, FileWave or one of the many other tools, there are a lot of things that MDM can configure on devices.
Reporting can also play a major role in how MDM tools are used. iOS Apps are owned by AppleIDs, not devices. MDM does not manage AppleIDs, but you can trigger fields in MDM databases to report back unauthorized AppleIDs being used. Reporting can also identify when devices join non-approved wireless networks (which cannot be blocked through MDM), identify devices that have been jailbroken (a major security concern for many organizations) and report on device use.
Because devices can fall outside of our control, MDM also plays an important role in being able to wipe and lock devices. While some of these types of features are available via Exchange, not all people use ActiveSync. Users and administrators alike can wipe, lock and de-enroll devices at will, potentially crippling what any device with an Enrollment Profile can do.
There are really 3 kinds of MDM tools: those that can push apps, those that can’t and Apple’s Profile Manager. The reason I put Profile Manager into its own class, is that it can push some kinds of apps, it’s cheap ($49.99 one time as opposed to per device per month or per device per year billing) and it’s great for some things. But Profile Manager should be used in very specific environments unless the price is the only decision making factor behind a tool. In larger environments, choosing a MDM solution is one of the most important aspects of managing mobile devices and the iOS platform is no different in that manner than other mobile platforms.
MDM has some limitations, though. A good MDM solution can manage the infrastructure side of device configuration. However, content requires a completely separate tool. Additonally, MDM is a completely opt-in experience. If a user wants, they can remove their device from the MDM solution at any time. Rather than a limitation, think about the opt-in experience this way: if a user removes themselves from MDM then all content that was given to them via MDM is then taken away, except that which they have moved to the local device. Therefore, if an administrator pushes an Exchange configuration then all content from that Exchange profile is forbidden fruit, removed alongside the de-enrollment.
MDM also works with Lion. Policies, centralized management, etc can be integrated with Lion. You can’t do app distribution per se, but you can push out a policy to change where the dock is on the screen, add a printer to a Mac and configure a login hook through a Profile Manager-based policy. Many of the MDM providers have begun adding functionality to their tools to allow for Mac management as well as iOS and I would expect that to become the standard in years to come. iOS is a single-user device and OS X is a multi-user device, which completes that paradigm, but Apple has made it no secret that policy-based management for Mac OS X is moving to the realm MDM (even if that is enforced through a traditional lens of directory services based policy-based management).
One of the unique aspects of the iOS platform is that it doesn’t have a file system that is exposed to users. There’s no /Volumes, no C: drive and no home folders. The devices don’t log into a server, because there’s no way to interpret a server connection. The file system that is exposed to iOS devices is through the lens of each application. Sandbox is a technology that limits each application’s access in terms of memory, hard drive, etc. Each application can only communicate with resources outside of itself if there is an API to do so, APIs mostly reserved for Apple (e.g. photos, contacts, etc). Therefore, when you discuss content management from the perspective of building a large iOS solution, you’re talking about apps.
The apps used for content management come in a few flavors. There are those that allow you to edit content and then there are those that allow you to read content. One way to look at this is through Safari. Sharepoint, WebDAV and various document management portals allow users to access data through the Safari browser on an iOS device. Safari will let you view various file types. But to edit the data, you would need to send it to an app, or copy it to the clipboard and access it in an app. Pages is an example of an app that can browse a file tree via WebDAV and edit content. However, planning how each type of file is accessed and what type of editing can be done on each file type or what type of resources need to be accessible can be difficult (e.g. there are a number of transitions in Keynote presentations that do not work in iOS).
Then there’s iTunes. iTunes allows you to backup and restore devices, update devices, etc. iTunes allows you to drop content into each application. If you look into the ~/Library/Mobile Documents, you can drop content, edit default documents and other tasks that can be done through a command line, then perform a cradled sync to an app. If networking is built into an app then you don’t have to plug a device into a computer. If an app can leverage iCloud, SMB or AFP then you can access data over the air. If you are trying to replace computers with iOS devices (a la post-PC) then you would need to plan each business task that needs to be performed and make sure not only that there is an app for that (or an app you build for that) but also make sure that you can round trip data from a shared repository and back to the network storage that the data resides on.
You can also access many of the benefits of MDM without having an OTA element. This can be done with iPhone Configuration Utility. iPhone Configuration Utility can configure the same policies available through Profile Manager but relies on either a cradled or email/web server/manual way of getting policies onto devices and updating. MDM automates this, but iPhone Configuration Utility is free and can be used as well. Additionally, profiles can be exported from Profile Manager and installed in the email/web server/manual way that iPhone Configuration Utility profiles are installed.
This is all probably starting to seem terribly complicated. Let’s simplify it:
Basically, there’s a few holes here. First, AppleIDs cannot be centrally managed. Second, you need to use gift cards or the Volume Purchasing Program (VPP) to distribute apps, and Third, even when you push an app to an AppleID, the app follows the AppleID to their next organization (which causes many organizations to treat apps like consumables). Fourth, synchronizing content is done primarily through iTunes, which only syncs a device at a time, making preparation of large numbers of systems terribly complicated.
Enter Apple Configurator, a free tool on the Mac App Store. This tool basically fixes all of the problems that we reference, but does so over USB. This means that Apple Configurator is not necessarily a replacement for MDM. In fact, you can deploy Trust and Entrollment profiles for MDM and automate the MDM enrollment for a device through Configurator. Instead, Apple Configurator is a tool that can either Prepare or Supervise an iOS deployment and do so in a manner that is easy enough that you don’t need a firm background in IT to manage devices on a day-to-day basis.
Here is what Apple Configurator can do:
Apple Configurator has some caveats:
I see a number of uses for Apple Configurator. Some of these use cases include:
These can enhance practically every environment I’ve worked with. But unless it’s a small environment (e.g. the labs), Apple Configurator isn’t a replacement for the tools already in use in most cases. Instead, it just makes things better. Overall, Apple Configurator is a welcome addition to the bat belt that we all have for iOS management and deployment. Now that we’ve looked at the when/where of using it, let’s look at the how.
There are two ways to use Apple Configurator. The first is to Prepare Devices. You would use this mode when you’re going to perform the initial setup and configuration of devices but not when the devices won’t be checking back into the computer running Apple Configurator routinely. Preparation settings do not persist. And while applications can be pushed through Preparation, updates for those applications will be tied to the AppleID that purchased the app.
The second is Supervise. Supervising devices is an option when preparing and allows you to have persistent changes to devices, to layer new settings the next time devices are plugged in, to add applications and the most intriguing aspect of iOS management here is reallocating VPP codes to new devices when a user or device is retired. Supervising devices also allows for assigning a given user to a device and thus pushing data into an application.
Setting Up Apple Configurator
Apple Configurator is installed through the Mac App Store. When installed, you are presented with three options. The first (going from left to right) is to Prepare Devices.
Before we get started, we’re going to add our AppleID. The computer running Apple Configurator needs to be able to connect to the App Store and it needs to have an AppleID associated with it if you’re going to use VPP codes. So let’s set that up before moving on. To do so, from Apple Configurator, click on the Apple Configurator menu and click on Preferences… From the Preferences menu, click on Set for the Apple ID and provide an AppleID (not the VPP Program Facilitator).
Then, when prompted, provide the credentials for your AppleID. If you have any problems with this, try Authorizing the computer in iTunes, if you can’t do one it stands to reason you can’t do the other and it’s either an invalid AppleID or that the computer cannot communicate with Apple’s servers (ports, DNS, Internet connectivity, etc might be the issue).
Also, let’s configure the Lock Screen settings, which is what’s displayed to users when you’re supervising devices. If you have user pictures in Open Directory, this will show each user’s photo at the lock screen (we will discuss device supervision later).
Using Apple Configurator to Prepare Devices
In this example, we’re going to prepare some devices for deployment. Before we do anything, we’re going to do a backup of the iOS device to use for testing. To do so, simply click Prepare Devices to bring up the main Apple Configurator screen and then click in the Restore field.
At the Restore menu, click Back Up…
Then choose the device to backup and click on Create Backup… to bring up the screen to select where to save your backup to (by default it should be your Documents but you can save them anywhere, like /iOSBackups). Click Save to make the first backup.
Notice how fast that went (assuming you didn’t load it up with 10 Gigs of crap)? The reason is that we’re not backing up iOS, just the data. This will become a little more obvious the first time we go to restore a device. In the meantime, if you look at your target directory, you’ll see a file with the name you provided followed by .iosdevicebackup. If you aren’t supervising you would need to delete these from the filesystem to remove them from the menu of available backups. If you are supervising then you’ll have a menu to manage the backups. You can also use the Other option in the selection menu to browse to another location and select another backup (e.g. you’re pulling them from other machines, etc.
Now that we have a backup, let’s do some stuff to the device. Let’s join the wireless network, change the wallpaper, create some contacts, make some notes and in general do some of those things that you might do on a base image of a computer, aside from of course configuring local admin (it’s not a multi-user device), installing anti-virus (to date, AV companies for iOS are snake oil salesmen) and other things you might not do. But as with imaging, if you can do something in Profile Manager or Apple Configurator, let’s reserve doing it there. In fact, I would probably try to set everything in Profile Manager or your MDM provider that you can (if you have one) and use Apple Configurator for as little as possible. That goes with imaging as well, do as much in directory services/managed preferences/profiles as you can and keep the image as simple as possible…
Anyway, once you have the device as you want it, make another backup. This is akin to baking an image with DeployStudio or System Image Utility. We can’t asr them out yet, but we’re in a much better place than we were.
Once you have a good backup, let’s leverage Apple Configurator to tell the device erase, update to the latest version of iOS, restore our image, join the SSID of our enrollment network (let’s consider this similar to a supplicant network in 802.1x). Then, let’s add a profile that will throw a Web Clip to our MDM solution and even add a Trust Profile to cut down on the number of taps to enroll (and the confusion of tap here, tap there, etc). From the Prepare screen in Apple Configurator, click on Settings and type the naming convention for your devices (in this case we’re going to call them krypted 1 and up) in the Name field. Then check the box for Number sequentially starting at 1 so it’s going to name them from 1 to 1,000,000 (which is how many iPads my krypted company is going to end up writing off at the testing rate I’m on now). Leave Supervision set to OFF (we’ll look at that later) and set the iOS field to Latest. Then, check the box for Erase all contents and settings and choose your image from the Restore menu.
Now for something that users of iPhone Configuration Utility, Profile Manager and Casper MDM will find familiar, click on the plus sign in the Profiles field and select Create New Profile. Here, we see what is the standard policy sheet (apologies to HIG if that’s not what those are officially called but I’ve not been able to find the right term) and give it a name in the Name field. This is how it will appear in the Profiles section of Apple Configurator. Because you can deploy multiple profiles, I’m just going to configure the SSID and Web Clip and call it MDM Enrollment. Optionally, give it some notes, organization name, etc.
Click on Wi-Fi and then click on the Configure button. Here, enter the SSID of the deployment network (MDMEnroll in this example). We’ll use the Hidden Network field to indicate the SSID is suppressed and we’ll use the network type of WEP and throw the password into the Password field as well. Now, before we move on, notice that there’s a plus and minus sign in the top right of the screen? You can deploy multiple of each, so if you have 10 wireless networks, 4 Email accounts, 9 VPN connections, 29 SSL Certs etc, you could deploy them all easily with multiple entries of each.
Scroll down in the sidebar a little and then click on Web Clips. Click on the Configure button. The Label is how the web clip’s name will appear on the device. We’re going to enter Enroll Here. In the URL field, provide the URL for your MDM server (e.g. When using a Profile Manager server called mdm.krypted.com the URL would be https://mdm.krypted.com/MyDevices). Not to get off topic, but did anyone else notice that Profile Manager in 10.7.3 now requires SSL certs? Anyway, you’ll also choose whether the web clip should be Removable (I think it should if it’s to enroll) and optionally choose an Icon. We’ll skip that (if we were using a 3rd party tool, I’d throw their logo in here; otherwise I usually like to use the company logo. I also like enrollment links to be Full Screen.
Go ahead and click Save and you’ll see MDM Enrollment listed in the Settings. If you notice, you can also click on the profile and then click on the export menu to export the profile or under the plus sign (“+”) you can Import Profile…, which is how we’ll bring in our Trust Profile from Profile Manager. From Profile Manager we already downloaded the Trust Profile. Now we’re going to click on Import Profile… and browse to it on the desktop, clicking on Trust profile.mobileconfig (or whatever name yours may have). Click Open.
We could go a step further and actually enroll the device by exporting the enrollment profile as well, but again, I want each user to provide their username and password so I as an administrator don’t have to go through and attach each device to a user in this scenario. I’ve been looking at importing devices and associating them with users via postgres, but that’s going to be another 3am article, on another night…
Next, check the box for each profile and click on Apps. This is where things start getting kinda’ cool. For this you’re going to need some app ipas. Each app in iTunes is stored as an .ipa file. We’re going to look at two different kinds of apps. The first is a free one and the second is a paid for app, both we’ll pull from iTunes. To do so, open iTunes and click on an app (iBooks in our example) and click on Show in Finder.
Note: Not all app .ipas are called the same thing as the filename. If you Show in Finder from the contextual menu of an app in iTunes it will automatically highlight the correct app in the Finder when it opens a Finder screen.
From the Finder you can either copy the app to the machine running Apple Configurator or if you’re using iTunes on that machine, you can go ahead and drag it to the Apple Configurator apps list. We’re also going to add an App that we used a purchase code from the VPP store to buy. You’ll get an error when you drag the paid app in (or browse to it if you so choose) that indicates the app is paid and in order to deploy it you’ll need to use VPP codes. Once added, you’ll notice it has an error indicator and the number 0 beside it.
Click on the numerical indicator beside the app name and you’ll be able to import redemption codes. These are emailed to you when you buy apps through the Volume Purchasing Program. BTW, no drag and drop in this screen, use the Important Redemption Codes button to browse to the XLS files.
Using Apple Configurator to Supervise Devices
Now, supervising devices may seem more complicated, but it isn’t. Back at the Prepare screen, we set Supervision to OFF. Change the iOS field to No Change. Now, let’s turn it ON. When you do so, the iOS field automatically switches to Latest. This means that supervision is going to require updates (which is fine in my book as updates have yet to break a single app for me). Get all the same settings the same as they were previously.
Once you enable Supervision, click on Prepare in Apple Configurator and connect a device again. The device will then be imaged as with the same settings that you’ve given it from before. However, once it’s done, you’ll be able to click on the Supervise tab and see devices (Note: You supervise devices rather than users).
The subsequent Starts and Stops will now allow you to enable and disable profiles and apps on the fly, as well as restore backups, update devices and as you can see in this screen, reclaim those valuable VPP codes!
Do a Get Info on a device and you’ll also see a bevy of information about that device.
You can also click on Assign, once you’ve enabled Supervision. Assigning devices requires directory services. When you click on Assign, click on the plus sign (“+”) to add the first user. Type the first few letters of the users name and they should appear in the list. Click on them and they’ll be added. You can then use the right panel to assign content to the apps that you assign to that user’s devices.
Once added, the user will by default have no device. To assign a device to a user, use the Check Out box at the bottom of the screen and then match the users with the devices you want them to have.
The final piece of this application is to assign content to users. As I mentioned earlier in this article, the file system of an iOS device is through the lens of the applications that the device has installed. Therefore, we’ll be associating files to applications. DRMd content is not distributed through Apple Configurator. So iBooks, etc, aren’t applicable. The various third party applications can open and therefore host file types that they support, as with iTunes. From the Assign pane of Apple Configurator, click on a user and then click on the plus sign (“+”) to add documents. At the Choose A Target Application screen, choose the application you’ll be loading content into.
When you click Choose, you’ll then be able to select files to use with that application.
Then just dock the iOS device, sync and viola you’ve got content distribution over USB all handled. You can also add groups of devices and groups of users and distribute content to groups of users rather than to one at a time.
Apple Configurator is really a great tool when used in the right scenarios. In learning how it works and interacts I actually learned a lot about both iOS and Mac OS X that I didn’t know before. I hope I did the tool justice with how easy it is to use. This is a fairly long article and it’s probably more complicated than it needs to be in parts, but that’s more my method of trying to figure out what it’s doing than the tool being complicated. It’s not hard to figure out at all. I am sure I could teach any non-technical iOS admin to use it in less than an hour.
My wish list includes logs and OTA. You can’t use iPhone Configuration Utility while you’re using Apple Configurator and therefore, you can’s see up-to-the second logs about things like key bags to figure out why this isn’t working or that. This makes it kinda’ difficult to figure out why a profile doesn’t get installed with an image if you’re not using an AppleID with the tool or other weird little things like that. I’d love to see a little more logging. Obviously, if you could run this thing Over the Air then it would be nerd nirvana. I guess the OTA isn’t as much as wish list for this tool, but features that could be imported into Profile Manager and other tools.
One of the more important aspects is the impact on AppleID use and app ownership. I started this off by saying “My traditional interpretation of Apple’s vision on how iOS devices are used is that everyone has an AppleID.” Well, when using this tool an AppleID is no longer necessary for app deployment.
Overall, we have a new, powerful tool in our arsenal that makes up the iOS administration ecosystem. I hope that I’ve managed to dispel a few rumors with this article and look at some great uses for where this tool should and should not be used. I also hope that no matter what, if you manage iOS devices, that you’ll take a look at it. I expect you’ll find it useful in some part of your management toolkit!
krypted March 15th, 2012
Tags: 802.1x, ActiveSync, AFP, API, Apple, Apple Configurator, AppleID, applications, apps, carddav, company, content management, cradle, deployment, devices, distribution, DRM, DUNS, education, encrypted backups, Exchange, iCloud, ios, iPad, iPhone, iphone configuration utility, ipod touch, itunes, LDAP, lock, management, mdm, mobile device management, mobility, ota, over the air, Prepare, reporting, restore, revoke apps, Safari, SCEP, schools, serial number, sharepoint, SMB, Supervise Devices, Trust Profile, UDID, volume purchasing program, vpn, vpp, Web Clip, webdav, wipe, Wireless
Users can log into the Mac App Store using their personal Apple ID. Users can also log into the Mac App Store with an AppleID that is linked to a company owned email address instead. The AppleID itself should be a company owned asset so that if/when users leave the organization, the organizations till owns the software that they purchase. Whether purchasing software through a volume purchasing program or directly, those dollars are wasted if the user is purchasing software through a personal AppleID. Therefore, you need a way to look at what AppleID that a user is using and to make sure that the organization has a way to link that account information back to the host the user is using and/or change the information if the user were to move to a different system.
In order to find the AppleID that a user is using, look into com.apple.storeagent. As the user, simply run defaults and read that domain along with the AppleID key:
defaults read com.apple.storeagent AppleID
When you run this, you see the Email address of that user. The DSPersonID is then listed here as well, as well as any other accounts (by DSPersonID) that have AppleIDs attached to the host. That DSPersonID is used throughout iCloud, actually. If you have installed iCloud through the system preference pane you will end up with Back to My Mac keys and other keychain assets that reference back to the keychains.
Now, to defaults write data into this domain isn’t as simple as you might think. The problem is that you would need to know the AppleID’s DSPersonID. You would also need to deploy the keychain items for the AppleID application password and the certificate for the AppleID, which has a com.apple.idms.appleid.prd.CN, or common name.
krypted November 11th, 2011