Apple Configurator 2 can rename iOS devices. To use Apple Configurator to rename a device, first plug it into a Mac running Apple Configurator 2. From Apple Configurator, right-click on the device and choose Device Name… from the Modify menu. At the “Rename device” screen, enter a new name for the device and click on Rename. Alternatively, you can use the (+) menu to choose variables to use during the renaming process. Here, you can choose to base a name on a Serial number, the Number, the device Type, or the Capacity of the device. Once you enter new information, click the Rename button to change the name of the device.
Our friends at VMware continue to outdo themselves. The latest release of Fusion works so well with Windows Server 2013 that even I can’t screw it up. To create a virtual machine, simply open VMware Fusion and click New from the File menu. Click “Choose a disc or disc image.” Select your iso for Server 2012 and click on Open (if you have actual optical media it should have skipped this step and automatically sensed your installation media). Click Continue back at the New Virtual Machine Assistant screen. Click Continue when the Assistant properly shows the operating system and version. Enter a username, password and serial number for Windows Server if you want Fusion to create these things automatically and just complete an installation. If not, uncheck Easy Install (but seriously, who doesn’t like easy). Also, choose the version of Windows Server (note that there’s no GUI with the Core options). Click Continue. At the Finish screen, you can click Customize Settings if you would like to give the new virtual machine more memory or disk. Otherwise, just click Finish. When prompted, choose where the new virtual machine will live and click Save. The VM then boots into the Setup is starting screen. You will be prompted for a Core vs. a GUI install (I know, you picked that earlier). I choose a GUI, then click Next. When the setup is complete, login, run Software Update and you’re done!
The most impactful aspect of the changes in OS X Mountain Lion Server at first appears to be the fact that DNS looks totally different in the Server app than it did in Server Admin. For starters, most of the options are gone from the graphical interface and it looks a lot less complicated, meaning that there are indeed fewer options. However, all of the options previously available are still there. And, the service behaves exactly as it did before, down to the automatically created host name when a server is configured and doesn’t have correctly configured forward and reverse DNS records that match the host name of the computer. The DNS servicein OS X Mountain Lion Server, as with previous versions, is based on bind 9 (9.8.1 to be exact). This is very much compatible with practically every DNS server in the world, including those hosted on Windows, OS X, Linux and even Zoe-R. Installing DNS For many, at installation OS X Mountain Lion Server will already be running the DNS service. This is because DNS wasn’t ready for the server when the Server app was first run. In order to protect itself from misconfiguration, the server then configures DNS to what it thinks is appropriate based on the initial setup assistant. While initially the service appears to only be running with the one record, several are actually created. The initial zone, a reverse zone, the NS record for the zone, the NS record for the reverse zone, the reverse record for the initially created zone, etc. To see all of this, open Server app and then click on the DNS service in the list of SERVICES. Then, click on the cog wheel icon below the list of records and click on Show All Records. Use the Edit button for Forward Servers to configure servers that DNS requests that aren’t resolvable by the local service for. For example, if you want your DNS service to look to 22.214.171.124 and 126.96.36.199 if it can’t find a record and then cache what it finds there, click Edit. At the Forwarding Servers screen, use the plus sign to assign the two IPs you would like to use. All records are then cached based on TTL of the zone. By default the “Perform lookups for” option is set to “only some clients”. Click the Edit button here to define what computers can perform DNS lookups through this server. At the Perform Lookups screen, provide any additional subnets that should be used. If the server should be accessible by anyone anywhere, just set the “Perform lookups for” field at the DNS service screen to “all clients”. Managing Records All you have to do to start the DNS is click on the ON button (if it’s not already started, that is). There’s a chance that you won’t want all of the records that are by default entered into the service. But leave it for now, until we’ve covered what everything is. To list the various types of records:
- Primary Zone: The DNS “Domain”. For example, www.krypted.com would likely have a primary zone of krypted.com.
- Machine Record: An A record for a computer, or a record that tells DNS to resolve whatever name is indicated in the “machine” record to an IP address, whether the IP address is reachable or not.
- Name Server: NS record, indicates the authoritative DNS server for each zone. If you only have one DNS server then this should be the server itself.
- Reverse Zone: Zone that maps each name that IP addresses within the zone answer with. Reverse Zones are comprised of Reverse Mappings and each octal change in an IP scheme that has records mapped represents a new Reverse Zone.
- Reverse Mapping: PTR record, or a record that indicates the name that should respond for a given IP address. These are automatically created for the first IP address listed in a Machine Record.
- Alias Record: A CNAME, or a name that points to another name.
- Service Record: Records that can hold special types of data that describe where to look for services for a given zone. For example, iCal can leverage service records so that users can just type the username and password during the setup process.
- MX Record: Mail Exchanger, points to the IP address of the mail server for a given domain (aka Primary or Secondary Zone).
- Secondary Zone: A read only copy of a zone that is copied from the server where it’s a Primary Zone when created and routinely through what is known as a Zone Transfer.
Note: To make sure your zone name and TLD don’t conflict with data that already exists on the Internet, check here to make sure you’re not using a sponsored TLD.Double-click on a Machine record next (or click plus to add one). Here, provide a hostname along with an IP address and indicate the Zone that the record lives in. The IP Addresses field seems to allow for multiple IPs, which is common in round robin DNS, or when one name points to multiple servers and lookups rotate amongst the servers. However, it’s worth mentioning that when I configure multiple IP addresses, the last one in the list is the only one that gets fed to clients. Therefore, for now at least, you might want to stick with one IP address per name. Note that the above screen has a match for the host name to the zone name, including the zone name. This is not to be done for manually created records. Enter the name of a record, such as www for the zone called, for example, krypted.com and not www.krypted.com in the Host Name record, or you will end up creating a host called www.krypted.com.krypted.com, which is likely not very desirable. Given that this wasn’t the default behavior back in Server Admin, I personally consider this something that will likely get fixed in the future. Click Done to commit the changes or create the new record. Next, let’s create a MX record for the domain. We’re going to stick with the c.pretendco.com subdomain as it provides us with a nice walled garden for our DNS. To create the MX for the domain, click on the plus sign at the list of records. Select the appropriate zone in the Zone field (if you have multiple zones). Then type the name of the A record that you will be pointing mail to. Most likely, this would be a machine record called simply mail, in this case for pretendco.com, so mail.pretendco.com. If you have multiple MX records, increment the priority number for the lower priority servers. As a full example, let’s create a zone and some records from scratch. Let’s setup this zone for an Xsan metadata network, called krypted.xsan. Then, let’s create our metadata controller record as starbuck.krypted.xsan to point to 10.0.0.2 and our backup metadata controller record as apollo.krypted.xsan which points to 10.0.0.3. First, click on the plus sign and select Add Primary Zone. At the zone screen, enter the name krypted.xsan, check the box for Allow zone transfers (there will be a second server) and click on the Done button. Click on the plus sign and then click on Add Machine record. At the New Machine Record screen, select krypted.xsan as the Zone and then enter starbuck as the Host Name and click on the plus sign for IP Addresses and type in 10.0.0.2. Click on Done to commit the changes. Repeat the process for Apollo, entering apollo as the Host Name and 10.0.03 as the IP address. Click Done to create the record. Setting Up Secondary Servers Now let’s setup a secondary server by leveraging a secondary zone running on a second computer. On the second Mountain Lion Server running on the second server, click on the plus sign for the DNS service and select Add Secondary Zone. At the Secondary Zone screen, enter krypted.xsan as the name of the zone and then the IP address of the DNS server hosting that domain in the Primary Servers field. Click Done and the initial zone transfer should begin once the DNS service is turned on (if it hasn’t already been enabled). Managing DNS From The Command Line Now, all of this is pretty straight forward. Create a zone, create some records inside the zone and you’re good to go. But there are a lot of times when DNS just needs a little more than what the Server app can do for you. For example, round robin DNS records, bind views, etc. Therefore, getting used to the command line is going to be pretty helpful for anyone with more than a handful of records. The first thing to know about the DNS command line in OS X Mountain Lion Server is to do everything possible using the serveradmin command. To start the service, use the start option:
sudo serveradmin start dnsTo stop the service, use the stop option:
sudo serveradmin stop dnsTo get the status of the service, including how many zones are being hosted, the last time it was started, the status at the moment, the version of bind (9.8.1 right now) and the location of the log files, use the fullstatus option:
sudo serveradmin fullstatus dnsA number of other tasks can be performed using the settings option. For example, to enable Bonjour Client Browsing, an option previously available in Server Admin, use the following command:
sudo serveradmin settings dns:isBonjourClientBrowsingEnabled = yesSubnets can be created programmatically through serveradmin as well. Let’s look at what our krypted.xsan subnet looks like, by default (replace your zone name w/ krypted.xsan to see your output):
sudo serveradmin settings dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsanWhich outputs the following:
dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:allowZoneTransfer = yes dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:aliases = _empty_array dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:expire = 1209600 dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:serial = 2012080505 dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:allow-update = no dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:adminEmail = "firstname.lastname@example.org" dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:machines:_array_index:0:name = "starbuck.krypted.xsan." dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:machines:_array_index:0:ipAddresses:_array_index:0:ipAddress = "10.0.0.2" dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:machines:_array_index:1:name = "apollo.krypted.xsan." dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:machines:_array_index:1:ipAddresses:_array_index:0:ipAddress = "10.0.0.3" dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:nameservers:_array_index:0:name = "krypted.xsan" dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:nameservers:_array_index:0:value = "starbuck.krypted.xsan." dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:refresh = 3600 dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:mailExchangers = _empty_array dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:reverseMappings = _empty_array dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:retry = 900 dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:timeToLive = 86400 dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:serviceRecords = _empty_array dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:bonjourRegistration = yes dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:name = "krypted.xsan"Now, let’s say we’d like to disable bonjour registration of just this zone, but leave it on for the others on the server:
sudo serveradmin settings dns:views:_array_id:com.apple.ServerAdmin.DNS.public:primaryZones:_array_id:krypted.xsan:bonjourRegistration = noThe entire block can be fed in for new zones, if you have a lot of them. Just remember to always make sure that the serial option for each zone is unique. Otherwise the zones will not work properly. While serveradmin is the preferred way to edit zone data, it isn’t the only way. In /private/var/named are a collection of each zone the server is configured for. Secondary zones are flat and don’t have a lot of data in them, but primary zones contain all the information in the Server app and the serveradmin outputs. To see the contents of our test zone we created, let’s view the /var/named/db.krypted.xsan file (each file name is db. followed by the name of the zone):
cat /var/named/db.krypted.xsanThe output of which is similar to the following (YMMV based on record composition):
krypted.xsan. 10800 IN SOA krypted.xsan. admin.krypted.xsan. ( 2012080507 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 minutes) 1209600 ; expire (2 weeks) 86400 ; minimum (1 day) )10800 IN NS starbuck.krypted.xsan. apollo.krypted.xsan. 10800 IN A 10.0.0.3 starbuck.krypted.xsan. 10800 IN A 10.0.0.2Add another record into the bottom and stop/start DNS to immediately see the ramification of doing so. Overall, DNS is one of those services that seems terribly complicated at first. But once you get used to it, I actually find manually editing zone files far faster and easier than messing around with the Server app or previously Server Admin. However, I also find that occasionally, because the Server app can make changes in there that all my settings will vanish. Troubleshooting is another place where the command line can be helpful. While logs can be found in the Server app, I prefer to watch log entries live as I perform lookups using the /Library/Logs/named.log file. To do so, run tail -f followed by the name of the file:
tail -f /Library/Logs/named.logFinally, see http://krypted.com/mac-os-x-server/os-x-server-forcing-dns-propagation for information on forcing DNS propagation if you are having issues with zone transfers. Conclusion Because DNS is one of the most critical aspects of getting your server or servers configured properly, set up the name of your server before you do anything else. Then the very first thing you should do when you open the Server app on your first server is configure DNS. The next thing you should do is test DNS. The first thing you should do on each subsequent server is check DNS. Overall, the DNS service is very straight forward, once you get used to setting up records. There is a ton of flexibility around using the command line to manage the service as well; however, be aware when you do so that you could end up loosing data if you aren’t careful not to make any changes in the Server app! As for getting used to the changes with every new version of OS X, Daniel Graystone once said “She’ll adjust. She’s probably very confused by everything. It’s only natural.”
Profile Manager allows you to leave certain fields that are user-centric blank and it will prompt at the time that the profile is installed for the blank information. These are usually user-centric fields, such as short name and password. You can also create a profile in Profile Manager for each user you want to setup mail, Exchange, iCal, Address Book and other services that are tied to a specific user. You can enter the username for each and leave the password blank and the user will be prompted for the password but have the username filled in. And then there are payload variables. Note: Before we get started on Payload Variables, it’s worth noting that many did not work well prior to 10.7.3, most notably %email%. Profile Manager provides a number of ways to configure accounts and settings on iOS based devices. When a user logs in, the user’s name, email address, title, phone number and both the short name and GUID of the user’s account are able to be substituted using variables. These variables have a % in front of and behind the name of the variable, making them easy to identify when looking at accounts. These can easily be put into a profile’s payload. When a user logs in the contents of the payload variable are replaced with the information for the account that logged in using the /MyDevices page in the web enrollment interface. When the enrollment profile is downloaded to the device, the variable is substituted with the user’s information from directory services (for user payloads) or from the device itself (for device payloads). Using payload variables is a really straight forward process. First, create a profile by logging into the Profile Manager web interface (the name of the server followed by /ProfileManager. When prompted, provide the username and password for an administrative account. Click on a group or user who you would like to configure a profile for. From the profile screen, select the payload that you’d like to configure. Enter the variable into the field(s) you’d like the substitution to occur in. For example, here I’m using a variable everywhere currently possible. Note: You can wrap the variable with other text. For example, if you enter krypton.com/%short_name% then for a user of cedge the variable would expand as krypton.com/cedge, useful in doing Exchange configurations. Variables available for use include user and device variables. These user variables are as follows:
- %email% – The email address (the EMailAddress attribute)
- %first_name% – The first name (the FirstName attribute)
- %full_name% – The full name (the RealName attribute)
- %guid% The guid (the GeneratedID attribute)
- %last_name% – The last name (the LastName attribute)
- %job_title% The job title (the JobTitle attribute)
- %mobile_phone% The mobile number (the MobileNumber attribute)
- %short_name% The short name (the RecordName attribute, typically the name of the account )
- %BuildVersion% – Full OS version on the device
- %ICCID% – ICCID (from the SIM card)
- %IMEI% – IMEI (International Mobile Equipment Identity)
- %OSVersion% – Common version number of the device’s OS
- %ProductName% – Product name
- %SerialNumber% – Serial number
- %WIFIMAC% – MAC address of the WiFi interface
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). Content 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). Cradling Devices 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:
- OTA policies and custom app deployment: MDM
- OTA content distribution: Apps
- Cradled policies and custom app deployment: iPhone Configuration Utility (free)
- Cradled content and app distribution: iTunes (free)
- OTA App distribution: AppleID/iCloud
- Backup and restore: iCloud or iTunes
- Update iOS devices to the latest version of iOS.
- Rename devices using a numbered scheme (e.g. iPad 1, iPad 2, etc).
- Erase (wipe) iOS devices.
- Backup and Restore iOS devices.
- Deploy profiles/policies (e.g. no Siri for you, disable cameras, setup wireless, etc) to iOS devices.
- Export profiles.
- Activate devices (after all a restore of a freshly activated device is an activation).
- Push any kind of app to devices.
- Track Volume Purchase Program (VPP) codes used on devices.
- Revoke VPP codes used on “Supervised” devices (more on supervision later).
- Assign users from directory services to devices.
- Load non-DRM’d content to apps on devices.
- Can work with up to 30 devices simultaneously (think big USB hubs or carts on wheels here).
- Paid apps need to use VPP codes to DRM apps. These VPP codes are purchased through a centralized program for an entire organization. To enter the VPP, you need to be a business with a DUNS number or an educational institution. You also basically need to be in the United States.
- Free apps can be deployed but the AppleID is in the IPA, meaning that to do an OTA update through App Store requires entering the password for the Apple ID the app was purchased with.
- In order to push apps through Apple Configurator, the system running Configurator needs access to Apple’s servers and Apple Configurator needs an AppleID associated with it that is not the VPP facilitator if you are leveraging any paid apps.
- You can use Apple Configurator “off-line” or without an AppleID to Prepare devices with Profiles, just not to
- If you push Trust and Enrollment profiles to automatically join Profile Manager (or another MDM vendor) the device isn’t associated with a user unless the MDM has been prepped to designate each UDID or Serial Number to a given user.
- Apple Configurator doesn’t work with Video or Music due to different DRM limitations.
- If you accidentally plug in your iPhone to a machine you’re using Apple Configurator on it and you’ve chosen to Erase in the application, then it will wipe your phone along with the 30 iPads you’re wiping. It’s awesome and scary like that (yes, I’ve accidentally wiped my phone).
- Company and education labs: manage devices end-to-end (no MDM, iTunes iPhone Configuration Utility or other tools needed), managed by the lab manager.
- One-to-One environments (schools): Manage the distribution of infrastructure settings (mail, wireless networks, etc) for devices as well as Trust Profiles to make it faster to enroll in MDM environments and Web Clips to manage the links for enrollment.
- Device distribution: Pre-load applications (that can’t be updated unless they’re cradled again), renaming, profiles, activation, iOS software updates, etc.
- Backup and Restore only stations where you don’t interfere with later iTunes use.
Once the codes are imported, you’re ready to configure a device.
When you import an application, you are creating a file with a GUID in /Users/admin/Library/Application Support/com.apple.configurator/Resources. These files represent applications that have been prepared for distribution. When importing, it will take as long as it takes to copy from the source to that directory. The entry in that directory is roughly the same size as the app. Therefore, you likely don’t want to copy every app you have in there, just the ones you plan to distribute.
Now for the dangerous part. Make sure you don’t have any devices plugged into the computer. I love to start with a device at the activation screen. That thing requires so many taps I jump at any 0 touch deploy type of options I can get my hands on to skip it (not that you’re going to get 0 touch if you have profiles). The reason we want to make sure there aren’t any devices plugged in is that they’ll be wiped if they are… Provided there aren’t any, click on the Prepare button and any devices plugged in wills tart configuring immediately. The application count will go down for VPP apps as each device is configured. It can do 30 in parallel.
You’ll see a green checkmark when each device is done. When you’re ready to stop configuring devices, click on Stop. The only other way to do any in parallel is through Xcode Organizer’s restore feature, but that was never very stable for this type of purpose and this is a much more object oriented approach to device imaging. The caveat for these apps is that the password for the AppleID is needed to update them, so this is not a means to deploy paid apps to BYOD or self-managed types of devices (IMHO). Also, the iOS version for devices is downloaded at this point from Apple. If you notice that the first time each type of device is imaged that it takes awhile, this is why. The second time this step is skipped (another reason we need Internet access on our Apple Configurator computer). These are located in /Users/admin/Library/Application Support/com.apple.configurator/IPSWs and if you need to run a beta version of iOS you can do so by dropping their ipsw versions in here manually, but I haven’t gotten device supervision to work when doing so.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. Conclusion 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!