After updating an iPhone, maybe it’s stuck. Doesn’t happen much, but it can happen. When it does, it’s great if you’ve got a backup of your phone. And those traditional means of restarting, resetting, and restoring don’t work any more. Or at least they do, but they’ve moved. If you need to DFU or restore your device, starts by plugging the phone into a computer running iTunes. Then press and hold the power button down for 3 seconds and press the volume down button while you’re holding that power button. Hold both down for about 10 seconds and let go of the power button, holding the volume down button for 5 more seconds. This process is pretty specific and I’ve often had to do it 3-4 times to get it just right. If you see the Apple logo at boot, the device is just rebooting (and that’s usually all I’ve needed). But if you really need it to go into restore or DFU-mode, you’ll want to see the screen that says Plug Into iTunes. Once you see that, you are in restore mode. If you want to be in DFU mode, you’ll want it right in the middle, where the screen is black.
I love answering a question with a question. Is asr still in OS X? Is NetInstall still in OS X Server? Can OS X still NetBoot? Does System Image Utility still work? The answer to all of these is yes. Therefore, the answer to “Is imaging dead” is clearly no. Is it on its way out, maybe. Debatable. Is it changing? Of course. When does Apple not evolve? What have we seen recently? Well, the rhetoric would point to the fact that imaging is dying. That seems clear. And this is slowly coming out of people at Apple. The word imaging is becoming a bad thing. But, as a customer recently asked me, “what do you do when a hard drive fails and you need to get a system back up”? My answer, which of course was another question was “what do you do when that happens with an iPad?” The answer is that you Restore. What is the difference between an Image and a Restore? Yes, I meant to capitalize both. Yes, I realize that’s not grammatically correct. No, I don’t care. It’s my prose, back off. But back to the point. What is the difference between the two? Am Image can have things inserted into /Applications, /Library, and even /System (since it’s not booted, it’s not yet protected by SIP). An Image can have binaries and scripts automatically fire, that Apple didn’t bake into the factory OS. On an iPad, when you Restore, you explode an .ipsw file onto disk that can’t be altered and acts as an operating system. The difference here is that one is altered, the other isn’t. Additionally, iOS ripsaw files only contain drivers for the specific hardware for a given device (e.g. one for iPad Mini and another for iPhone 6). But, you have pre-flight and post-flight tasks you need to perform. Everyone understands that. Think about automation via profiles. You can run a script with a profile. You can apply a profile at first boot. You can install a package (the future of packages is IMHO more debatable than the future of images) and a .app with a profile. These might take a little more work than it does with a NetInstall and System Image Utility. But then, it might not. You’d be surprised what’s easier and what’s actually harder (for now) with this new workflow. Complexities are more logistical than technical. So, Imaging is dead, long live Restoring? Arguably, any older workflows you have will be fine for some time. So any good article has a call to action somewhere. The call to action here is to try to subtly shift your deployment techniques. This involves implementing a DEP strategy where possible. This involves putting the final nails in the coffin of monolithic imaging. This involves moving to as thin an image as possible. This involves (I can’t believe I’m saying this) de-emphasizing scripting in your deployment process. This also involves completing the move that you’ve hopefully started already, from MCX to profile or mdm-based management. What else do you think this involves? Insert running commentary below!
Blueprints are a new option in Apple Configurator 2. Blueprints allow you setup a template of settings, options, apps, and restore data, and then apply those Blueprints on iOS devices. For example, if you have 1,000 iOS devices, you can create a Blueprint with a restore item, an enrollment profile, a default wallpaper, skip all of the activation steps, install 4 apps, and then enabling encrypted backups. The Blueprint will provide all of these features to any device that the Blueprint is applied to. But then why not call it a group? Why call it a Blueprint? Because the word template is boring. And you’re not dynamically making changes to devices over the air. Instead you’re making changes to devices when you apply that Blueprint, or template to the device. And you’re building a device out based on the items in the Blueprint, so not entirely a template. But whatever on semantics. To get started, open Apple Configurator 2. Click on the Blueprints button and click on Edit Blueprints. Notice that when you’re working on Blueprints, you’ll always have a blue bar towards the bottom of the screen. Blueprints are tiled on the screen, although as you get more and more of them, you can view them in a list. Right-click on the Blueprint. Here, you’ll have a number of options. As you can see below, you can then Add Apps. For more on adding Apps, see this page. You can also change the name of devices en masse, using variables, which I explore in this article. For supervised devices, you can also use your Blueprints to change the wallpaper of devices, which I explore here. Blueprints also support using Profiles that you save to your drive and then apply to the Blueprints. Blueprints also support restoring saved backups onto devices, as I explore here. For kiosk and single purpose systems, you can also enter into Single App Mode programmatically. You can also configure automated enrollment, as described here. Overall, Blueprints make a great new option in Apple Configurator 2. These allow you to more easily save a collection of settings that were previously manually configured in Apple Configurator 1. Manually configuring settings left room for error, so Blueprints should keep that from happening.
One of the things that is awesome and sometimes frustrating about Apple Configurator is that when you do certain tasks, you end up updating the OS on devices. The reason this is awesome is that it allows you to centralize operations. The reason this can be frustrating is that if you’re on a limited bandwidth connection, you may find that you can’t do very basic tasks before downloading a large OS update. And if you’ve got a bunch of Apple Configurator workstations, and you are running a training session, this can get infinitely more annoying. In these types of lab environments, you’re in luck. If you have an ipsw (the iOS OS update file), you can copy the file from ~/Library/Containers/com.apple.configurator/Data/Library/Caches/com.apple.configurator/Firmware/ onto another machine. To copy them onto a USB drive called bananarama for example, use the following command:
cp -R ~/Library/Containers/com.apple.configurator/Data/Library/Caches/com.apple.configurator/Firmware/ /Volumes/bananarama/ipsws/And once you’ve moved that drive, to then copy them back:
cp -R /Volumes/bananarama/ipsws/ ~/Library/Containers/com.apple.configurator/Data/Library/Caches/com.apple.configurator/Firmware/
You can easily create a backup of an iOS device using Apple Configurator. Once you’ve created a backup, it can be restored onto a number of devices. This contains iOS data and data outside of the secure enclave. These backups allow you to restore an iOS device, add apps (not using the backup), set backgrounds, set app locations on the home screen, etc. To do so, open Apple Configurator and then click on the Prepare icon. At the Prepare screen, click into the Restore field and then click on the Create Backup button. At the pop-up menu, select the device you’re backing up (usually there’s only one) and then click on the Create Backup button. Then choose the location you’d like to place the backup file. Click Save and the backup starts. Once the backup is complete, you will have an iosdevicebackup file in the location you saved the file to. This is stored on the iOS device and can then be restored to other devices.
You loved your Apple Watch. It was awesome. But then something happened. Maybe it got glitchy. Maybe it got weird. Maybe you want to sell it and so just want to get it back to factory defaults first. Well, either way it’s easy. To reset your watch, open the Settings app. Open the General app. Tap Reset at the bottom of the list. When prompted, tap Erase All Content and Settings on the Apple Watch. Once done, unless you’re getting rid of the watch, you’ll want to pair it again. To do so, follow the instructions in this article: http://krypted.com/apple-watch/set-up-your-new-apple-watch. Or, you can restore your device by selecting a device to restore the backup from.
The most important command for managing pretty much anything in Linux is vi. So if you only learn one command, learn that one. But if you want to learn another, the second most important command for managing Xen is then xm (well, once you’ve apt-gotten or yummied up the installation that is). The xm command has a number of easy verbs, each used for managing the Xen environment.
- xm info – Shows information about the Xen host
- xm list – Shows information about doms (states include r for running, b for blocked, c for crashed, p for paused and the worse, d for dying).
- xm network-list – Shows virtual interfaces for doms
- xm log – Shows information from the Xen logs
- xm reboot – Reboots a VM
- xm vcpu-list – Shows dom virtual processors
- xm top – Shows hosts and domains similar to how top works in *nix
- xm uptime – Shows uptime
- xm dmesg – Shows the send message buffer
- xm create krypted.com – Create a node called krypted.com
- xm console krypted.com – Switch to that new krypted.com node
- xm destroy krypted.com – Deletes that newly created krypted.com node
- xm shell – Invoke an interactive shell environment of your xend
- xm shutdown – Turn off a VM
- xm pause – Rather than shut the VM down, just pause it (starts back up much faster), but if the host is rebooted then state is lost (otherwise use suspend)
- xm suspend – Suspends a VM, which writes the data to disk, so changes wouldn’t be lost on restart.
- xm rename – Rename installed VMs
- xm resume – If a VM is paused, fire it up
- xm save – Similar to suspend except with user definable state file
- xm restore – Similar to resume except restoreable with exports that used the save verb
- xm dump-core – Dumps core per domain
- xm sysrq – Sends system requests per domain
- xm block-list – Lists block devices per domain
- xm mem-max – Configure the maximum memory for a domain
- xm mem-set – Configure the current memory allowance for a domain
- xm vcpu-set – Configure active processors for a domain
- xm migrate – Move a domain to another server (e.g. using the -l operator to do so live)
- virsh nodeinfo – Shows information about each node
- virsh vcpuinfo – Shows information about virtual processors
- virsh dominfo – Shows information about domains
- virsh dumpxml – Dumps the same information just in parseable XML
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!
The 10.7.2 to 10.7.3 update for Lion Server has introduced a few issues in some environments that I’ve seen. It just so happens that the update corrects a lot of behavior with Lion Server while also introducing new features, so it’s something you’re gonna’ need to do eventually. Therefore, before I update, I would strongly recommend backing up all of your services, your service data and Open Directory. Once you’ve run the 10.7.3 update, there are a few things that I’ve seen happen. The first is that the web server won’t start. If this happens, reset the web server back to factory default:
serveradmin command web:command=restoreFactorySettingsOnce it’s reset, you should be able to import any data that was backed up before and get things back to normal. The second is calendar data. On a few different systems I’ve seen users have to nuke iCal and then reimport data. To nuke and pave iCal, see this post: http://krypted.com/mac-os-x-server/nukepave-ical-server-in-lion-server. Once iCal Server has been restored to full working order (after the last step in that article) you can use psql to restore your data from the location of your backups (here called /backup/caldav.sql):
psql -U _postgres -d caldav -f /backup/caldav.sqlThere’s also a script located in /usr/share/caldavd/lib/python/calendarserver/tools called fix
calendardata.pythat can be used to scan and possibly fix any issues with the data itself. If that doesn’t not work though, you may be starting over. The script does not give root execute permissions by default and so you will need to chmod it to provide execute and then run it. If you nuke CalDAV and you nuke OD and then restore them both, the GeneratedUIDs can be mismatched. Use the Directory Editor in the new Directory Utility to browse users and attach the GeneratedUID back to the correct entry in CalDAV. To locate all of the entries in CalDAV, run:
psql -U _postgres caldav -c “select * from calendar_home"If Profile Manager won’t load it could be one of three issues (in the following order seemingly). The first is the web server, which the first command will fix. Another issue I’ve seen is that Open Directory gets a little messed up. The fix for this is to use Server Admin (not slapconfig) to burn OD down and set it back up. You can then promote replicas and finally restore the archive you did before upgrading the server. The third is to reset the Profile Manager database using wipeDB.sh:
sudo /usr/share/devicemgr/backend/wipeDB.shAfter wiping the data, you can re-run the setup in Server app for the Profile Manager service to restore an empty Profile Manager instance to working order. You can restore data into the empty Profile Manager database using the same commands I showed earlier for CalDAV, just use devicemgrd instead. Note: I am pretty sure you need sudo for most every command I use on this site, but more specifically you need it with this stuff. So sudo is assumed if not explicitly stated. Finally, be on the lookout for custom designs in the Wiki interface. OS updates are known to change things, but more specifically when things are not documented they can easily change. Hacking the pages nested within /usr/share/collabd is basically not supported any more. Each OS update to 10.7 has broken some of the hacks we’ve done to collabd, making me wonder whether it’s a good idea any more… Note2: I have had little issues running these updates in walled gardens. It’s production data that is the problem. It seems that most of the issues are data driven (the opposite of data driven design is not devops driven design).
I don’t believe in upgrading major operating systems for servers in place. There, I said it. If I’m doing an upgrade from Snow Leopard to Lion, I’m about 99.9% of the time going to do so with a clean install. Before I do so, I’m going to export all the data from my old server and when I’m done with the fresh, clean, loving installation, I’m going to import that data back into my server. Actually, before I import the data, I’m going to install all of the point releases, application updates and security patches. That’s my process for production servers. Open Directory isn’t very different. I Archive and Restore servers as often as I reinstall, upgrade or even downgrade Open Directory Masters. I treat Replicas differently: mostly in that I don’t treat them at all. Instead I clean install them and just re-promote them once my Master is back in place. If I have any schema extensions or other mods I’ll just sync those myself prior to promotion. I trust my process, it’s worked for me for more years than I care to admit. Before You Upgrade Archiving Open Directory data is a pretty straight forward process. Open Server Admin from /Applications/Server and then click on the Open Directory service. From here, Click on the Choose… button for Archive in: and select a location to store the Open Directory data. Then, click Archive and provide a password. Pretty easy so far. Now, check your Kerberos Realm, IP address and hostname on the server. For the IP address, you can take screen shots of the Network System Preference pane, or pipe the output of ifconfig to a text file. For the hostname, I don’t trust the GUI of OS X (no offense to the excellent UX developers employed at Apple). Therefore, use scutil for the names. Also, we’ll want that Kerberos information. I usually just grab that from my Server Admin Open Directory screen. Finally, we’re also going to get the OD policies using slapconfig again. In sequence, these commands would be:
ifconfig > ~/Desktop/mytextfile scutil --get HostName >> ~/Desktop/mytextfile scutil --get ComputerName >> ~/Desktop/mytextfile scutil --get LocalHostName >> ~/Desktop/mytextfile sudo slapconfig -getmasterconfig >> ~/Desktop/mytextfile sudo slapconfig -getmacosxodpolicy >> ~/Desktop/mytextfileAlso, backup any certificates, custom service principals you may have installed or other service data or data data that is needed on the host, if any. Installation Once you’ve got all of the important stuff backed up and know what you’re going to call the server moving forward, it’s time to install the operating system. If the server came with a Lion operating system pre-installed, skip this part. Use a Lion computer to create a recovery partition using the Recovery Disk Assistant. Once you have a valid recovery partition (on a thumb drive for now), boot to it on the server you are upgrading and wipe the system through Disk Utility. This step is probably pretty scary. And it should be. Make sure all your data is backed up before you do it. By the way, if you haven’t copied the mytextfile then think long and hard about whether there’s anything else missing before you start the reformat process on that drive (I seem to have to learn all of my lessons the hard way)… I also like to have a clone of the system as a back-out plan, just in case there are any problems with the upgrade. It adds a little latency but I’ve had to revert a few times with these upgrades, and having that clone sure beats pulling an all nighter… Once wiped, Choose the Reinstall Lion option and install the operating system. Then install all available patches (10.7.3 or higher is very, very important, btw). Once installed, use the App Store to buy Lion Server and install it, but don’t open it just yet. Remember those commands from earlier. When possible, Open Directory upgrades the smoothest when the IP address and host name are the same. Therefore, look at your mytextfile. Setup the IP information the same as it was, verifying against ifconfig and then use the first host name from the scutil output to configure the HostName (using mdm.krypted.com as my example):
sudo scutil --set HostName mdm.krypted.comThen the second host name:
sudo scutil --set ComputerName mdm.krypted.comAnd finally, the third:
sudo scutil --set LocalHostName mdmNow check changeip:
sudo changeip -checkhostnameIf it gives you the all clear, you’re ready to proceed. Next, download the Server Admin tools from Apple at http://support.apple.com/kb/DL1488. Provided that the installation is good, the host names match up in scutil and the IP address is the same as it was, open the Server app for the first time (from /Applications). The server will install the various components that complete the installation. Once installed, click on the Next Steps drawer and verify that the host name is good. If it is, you should see a message similar to the one below. Promotion Now promote your server. It’s going to be tempting to use Server Admin or slapconfig. If you use slapconfig you will regret it unless you use the new options supplied by Apple. Why? Because the Server app gracefully creates SSL certificates used in directory services binding; certificates that are not created with the old style slapconfig commands. Given that I’ve not seen complete documentation for slapconfig (many of the options required for correct scripted promotion in Lion aren’t actually in the man page), I’d just use the GUI for now (and if you don’t like using a GUI, then I challenge you to build OpenLDAP, Kerberos and all the other components setup by the Server app from source – that might cure the CLI snobbiness we all have from time to time). Also, be careful with how you promote/demote – this article outlines some reasons not to use slapconfig -destroyldapserver any more. From the Server app, click on Users in the Server sidebar. Here, you’ll notice that all of the accounts that are listed are black busts of users. Groups are similar. So far, all users created are automatically local users. If that’s not what you want, remove any of those accounts prior to continuing. Click on Manage Network Accounts… to bring up the Configure Network Users and Groups wizard. Click Next at the introductory screen. Then provide the Directory Administrator information (e.g. diradmin with a password of diradmin for the security conscious) and click on Next. At the Organization Information enter the information you want on the SSL certificate that is automatically generated for Open Directory. This includes the Organization Name and Admin Email address (this might not be enough information for some SSL providers, but it’s a good start) and click on Next. At the Confirm Settings screen, verify your information is as intended and then click on Set Up. The Open Directory Master is created. Once created, all new users will have the same icon as the local users, with the exception of a globe to indicate they are network accounts. Now check your logs to make sure everything installed smoothly. Importing Users, Groups and Computers Provided that the host name and IP address are the same on your server, importing the data back into Open Directory couldn’t be easier. Open Server Admin and then click on Open Directory and then on Archive in the top icon bar. Here, click on Choose and browse to the dmg you created when backing up the server. Click Restore and enter the password previously supplied. You can also import users from within the Server app. Now that your users are back, it’s time to make sure they’re a member of the groups that provide access to services. These are hidden by default, so in the Server app, use the Show System Accounts option under the View menu or if you’d rather use Workgroup Manager use Show System Records under the View menu to see the groups. Each service has a different group name. For example, Profile Manager is the Profile Manager ACL (or com.apple.access_devicemanagement for the short name) group. Add each user into the group that needs access to these services, click Save and you’re ready to bind some clients! Binding Clients Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane. To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted. Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name. It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user. Provided everything works that’s it. The devil is of course in the details. Good luck!