Tag Archives: carddav

Mac OS X Server

Configure The Contacts Service In Mavericks Server

Mavericks has an application called Contacts. Mavericks Server (OS X Server 3) has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. However, there is a layer of Postgres-based obfuscation between the Contacts service and CalDAV. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.

I know I’ve said this about other services in OS X Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the Contacts entry in the SERVICES section of Server app.

Screen Shot 2013-10-05 at 10.30.27 PMClick the Edit button to configure the Apple Push Notification settings for the computer. When prompted, click on Enable Push Notifications.

Screen Shot 2013-10-05 at 10.31.08 PMIf prompted, provide the username and password for the Apple ID and then click on Finish.

To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.

Screen Shot 2013-10-05 at 11.03.35 PMThe Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click the Accounts menu and then click on Add Accounts.

Screen Shot 2013-10-05 at 10.49.18 PMAt the Add Account screen, click Other contacts account.

Screen Shot 2013-10-05 at 11.05.03 PMAt the “Add a CardDAV Account” screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.

Screen Shot 2013-10-05 at 11.08.23 PMWhen the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.

Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.

Screen Shot 2013-10-05 at 11.13.03 PM

Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.

Screen Shot 2013-10-05 at 11.13.43 PM

At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:

sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase

Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.

The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:

sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443

The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:

sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

The service is then stopped with the serveradmin command:

sudo serveradmin stop addressbook

And started with the serveradmin command:

sudo serveradmin start addressbook

And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:

sudo serveradmin fullstatus addressbook

The output of which should be as follows:

addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1

If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:

sudo serveradmin settings calendar

By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:

sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001

And then let’s see what it is in addressbook:

serveradmin settings addressbook:MaxAllowedInstances

Mac OS X Mac OS X Server

Configuring Mountain Lion Server's Contacts Server

Mountain Lion has an application called Contacts. Mountain Lion Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service was called Address Book in Lion and below and is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.

I know I’ve said this about other services in Mountain Lion Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the name of the server in the Server app. Then click on Settings and check the box for “Enable Apple push notifications”.

Provide the username and password for the Apple ID and then click on Finish.

To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.

The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click Accounts and then click on the plus icon (“+”).

At the Add Account screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.

 

When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.

To create additional lists of contacts, hover over the name of the server and a plus sign appears, click on it to create a group on the Contacts service.

Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.

Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.

At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:

sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase

Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.

The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:

sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443

The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:

sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

The service is then stopped with the serveradmin command:

sudo serveradmin stop addressbook

And started with the serveradmin command:

sudo serveradmin start addressbook

And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:

sudo serveradmin fullstatus addressbook

The output of which should be as follows:

addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1

If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:

sudo serveradmin settings calendar

By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:

sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001

And then let’s see what it is in addressbook:

serveradmin settings addressbook:MaxAllowedInstances

If two services share a port and share all the same settings and even a binary then are they in fact the same service?

You know, there’s a million fine looking women in the world, dude. But they don’t all bring you lasagna at work. Most of ‘em just cheat on you.

Mac OS X

Getting The Address Book Debug Menu

A number of Apple applications have debug menus. In these menus are advanced options, or options used for troubleshooting that don’t need to be presented to users in everyday use of the tools. Address Book has such a menu. To see it, write a boolean ABShowDebugMenu key into the com.apple.addressbook defaults domain as true:

defaults write com.apple.addressbook ABShowDebugMenu -bool YES

Once run, a number of new features will be available, allowing you to, amongst other things, browse an Address Book Archive, open Time Machine from within the Address Book application (allowing you to restore specific contacts), export detailed database information and disable global searching. 

This still isn’t the kind of information you’d get with dmesg or something like that, but it’s worth checking out when you’re having issues with Address Book. To get rid of the debug menu:

defaults write com.apple.addressbook ABShowDebugMenu -bool NO

public speaking

MacTech InDepth In New York

I have been added as a speaker at MacTech InDepth in New York. If you haven’t signed up yet, and you work with Mac OS X Server then you should really check out the sessions that have been planned:

  • The Elephant in the Room: The New Lion OS X is out, now what? There are a lot of differences to contend with between Lion and Snow Leopard. Now with the new Mountain Lion update, what changes can we expect to see? We discuss the differences in advanced services, GUI simplicity, and Apache management GUI’s. We help you understand the updates in the new OS and make the transition easier. We go over the new updates of Lion over the Snow Leopard server.
  • Setting solid foundations: To truly grasp the power of Lion, you need to set up solid foundations. We go over minimum requirements for internet DNS, and tackle router tricks. We discuss open directory and what it was used for.
  • Mobile Device Management 101: Apple’s IPCU/Apple Configurator: Mobile Device Management is vital to businesses, large or small. We have an extensive overview of profile manager and how you can use mobile device management on OS X. For those still using Snow Leopard, we go over your options and discuss the possibility of using third parties as a solution.
  • DNS, Ahh, run away, run away: In this session, we tackle DNS and break it down and show how simple it is to work with. We go over how DNS works and cover different components such as internet DNS and internal DNS.
  • Administering a Server with just Server.app: We show you how to use server.app and control administrative programs. For the services, we go over Address Book, iCal, iChat, and Mail.
  • Web Administration of OS X Server : Web Admin on Lion Server versus Snow Leopard is covered, dealing with the differences and how to use each system effectively. On Lion server, we cover using FTP without a GUI.
  • Going old school, using the old tools: After getting used to Snow Leopard we go over the major differences between Snow and Lion and how you can handle the transition. We go over server admin and what is still left in the program and why it has been left.
  • Deployment Part I: Tools & Concepts: In tools and concepts we learn that there aren’t stark differences between Lion server and Snow Leopard. NetBoot, NetRestore and third party tools are covered; we talk about how NetBoot works and what the differences between NetBoot and NetRestore are. Along with this we cover Network configuration requirements and using software update server.
  • Deployment Part II: DeployStudio: DeployStudio is covered in-depth; we cover creation techniques and management techniques.

Overall, this represents a nice, fast way to update your skills to allow for managing Lion Server and to get up to speed with those new to the platform. One thing I like about the session list is that it goes beyond the stock server implementation and looks at DeployStudio, MDM and other important topics not purely server oriented. I hope to see you all there!

These vagabond shoes, are longing to stray
Right through the very heart of it – New York, New York

iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment

Managing iOS Devices with Apple Configurator

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

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.

Apple Configurator

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:

  • 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).

Apple Configurator has some caveats:

  • 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).

I see a number of uses for Apple Configurator. Some of these use cases include:

  • 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.

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.

Apple Configurator

Apple Configurator

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).

Configuring AppleIDs with Apple Configurator

Configuring AppleIDs with Apple Configurator

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).

Configuring AppleIDs with Apple Configurator

Configuring AppleIDs with Apple Configurator

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).

Configuring Lock Screen Settings In Apple Configurator

Configuring Lock Screen Settings In Apple Configurator

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.

Apple Configurator's Prepare Devices Screen

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.

Saving Backups in Apple Configurator

Saving Backups in Apple Configurator

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.

Preparing Devices in Apple Configurator

Preparing Devices in Apple Configurator

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.

Naming Your Profile in Apple Configurator

Naming Your Profile in Apple Configurator

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.

Adding Wireless Networks with Apple Configurator

Adding Wireless Networks with Apple Configurator

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.

Importing a Trust Profile Into Apple Configurator

Importing a Trust Profile Into Apple Configurator

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.

Show Apps in iTunes

Show Apps in iTunes

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.

Install Apps in Apple Configurator

Install Apps in Apple Configurator

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.

Adding VPP Codes in Apple Configurator

Adding VPP Codes in Apple Configurator

Once the codes are imported, you’re ready to configure a device.
App Indicator Counts

App Indicator Counts In Apple Configurator

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.
Imaging Devices in Apple Configurator

Imaging Devices in Apple Configurator

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.

Supervising Devices in Apple Configurator

Supervising Devices in Apple Configurator

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).

Device Supervision in Apple Configurator

Device Supervision in Apple Configurator

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.

Get Info on Devices in Apple Configurator

Get Info on Devices in Apple Configurator

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.

Pushing Content in Apple Configuration Utility

Pushing Content in Apple Configuration Utility

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.

Checking Devices Out To Users

Checking Devices Out To Users

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.

Choosing An App For Content

Choosing An App For Content

When you click Choose, you’ll then be able to select files to use with that application.

Selecting Content

Selecting Content

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!

Mac OS X Server

Fixing Service Issues When Upgrading to 10.7.3 Server

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=restoreFactorySettings

Once 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.sql

There’s also a script located in /usr/share/caldavd/lib/python/calendarserver/tools
called fix calendardata.py that 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.sh

After 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).

Mac OS X Server

Address Book Server "Groups"

I use the term “groups” loosely here. On my list of features that are needed in Lion Server (a much smaller since the advent of 10.7.3 btw) is the fact that Address Book Server doesn’t have groups, resources or whatever you want to call a logical structure that is a place for groups of users to keep contacts whose access can be limited to only certain users. The Address Book client fully understands such constructs, given that it separates the GAL from a user’s contacts and that user’s can themselves have groups of contacts. This area is a huge miss. The reason this annoys me is that you have the ability to do this stuff with iCal Server, which uses roughly the same technology (Twisted CalDAV vs. CardDAV). You can include LDAP contacts in an Address Book search, which just gives users access to users configured on the local server. Helpful if your user base is a walled garden. And don’t tell me that it kinda’ works the same in Exchange. Because a contact is not a user in Exchange…

Anyway, one way to get a shared list of contacts is to create a user just to be the shared list. This user is going to have a password. That password is going to end up in the keychain for all users who we install this account for. Furthermore, all of those users can delete contacts. And those users will invariably delete an account and blame said deletion on the server. Given that servers don’t delete data on their own, the blame is basically poorly placed.

If you need granular permissions control over shared contact lists, then Address Book server is not for you. But if you just need a “group” or two that is wide open permission-wise for all users, then consider this strategy. First, let’s enable Address Book services. To do so, first open the Server application from an Open Directory Master. Then, click on the Address Book entry in the Server application’s sidebar. Here, click on the ON button (by the way, I could have just used this paragraph as an article on Setting Up Address Book Server).

 Now that the service is started, click on Users. Then click on New User.

At the New User screen, let’s pick an arbitrary name that someone who gets access to this computer won’t think anything of, should they notice this account.

Once created, to make sure that the user has access to the Address Book service. To do so, click on the account and then select Edit Access to Services… from the cog wheel icon and verify that the Address Book service is enabled for the user.

Now, let’s check out how this looks on a client. These accounts can be deployed through profiles easily. But we like doing things the hard way. Therefore, let’s open the nifty Mail, Contacts & Calendars System Preference pane and then click on the Add Account… button. From the Choose an account type  field, click on the Add a CardDAV account button. Click on the Create… button.

Provide the username and password recently created, as well as the name or IP of the server.

Now open Address Book. Click on the red bookmark icon. You’ll then see your contact stash. Click on it and you can create, delete and otherwise do whatever you like here. If you create contacts and install this account on multiple machines then you’ll be able to edit or delete them from any of the stations they’re installed on.

You can install the accounts on iOS devices as well, using the Mail, Contacts & Calendars option in the Settings app.

Good luck. And may Billy Madison have mercy on your Address Book.

Mac OS X Server Mac Security Time Machine

Using ServerBackup to Backup Lion Servers

ServerBackup is a new command included in Lion Server, located in the /usr/sbin/ServerBackup directory. The ServerBackup command is used to backup the server settings for services running on a Lion Server. The command is pretty easy and straight forward to use, but does require you to be using Time Machine in order to actually run.

In the most basic form, ServerBackup is invoked to run a backup using the backup command. Commands are prefixed with a -cmd followed by the actual command. As you might be able to guess, the commandlet to fire off a backup is backup. The backup command requires a -source option which will almost always be the root of the boot volume (/):

/usr/sbin/ServerBackup -cmd backup -source /

The data backed up begins in a .ServerBackups directory on the root of the host running Time Machine. Once the backup is complete the data is moved over to the actual Time Machine volume, using a path of:

/Volumes/<TimeMachine_volume_name>/Backups.backupd/<hostname>/<date>/<GUID>/<Source_Volume_Name>/.ServerBackups

The output of a backup should look similar to the following:

2012-02-01 10:05:17.888 ServerBackup[15716:107] Error encountered creating ServerMetaDataBackupFolder at path := /.ServerBackups!
*** nextPath := 40-openDirectory.plist
*** nextPath := 45-serverSettings.plist
*** nextPath := 46-postgresql.plist
*** nextPath := 55-sharePoints.plist
*** nextPath := 65-mailServer.plist
*** nextPath := 70-webServer.plist
2012-02-01 10:05:18.480 ServerBackup[15716:107] SRC := /etc/apache2/
DST := /.ServerBackups/webServer
Failed to copy /etc/apache2/ to /.ServerBackups/webServer/etc/apache2; ret -> 0
2012-02-01 10:05:18.483 ServerBackup[15716:107] SRC := /etc/certificates/
DST := /.ServerBackups/webServer
Failed to copy /etc/certificates/ to /.ServerBackups/webServer/etc/certificates; ret -> 0
*** nextPath := 75-iChatServer.plist
*** nextPath := com.apple.ServerBackup.plist
curServicePath := /.ServerBackups/openDirectory/openDirectory.browse.plist
WARNING: Service openDirectory folder does not exist for browsing.
curServicePath := /.ServerBackups/serverSettings/serverSettings.browse.plist
WARNING: Service serverSettings folder does not exist for browsing.
curServicePath := /.ServerBackups/postgresql/postgresql.browse.plist
WARNING: Service postgresql folder does not exist for browsing.
curServicePath := /.ServerBackups/sharePoints/sharePoints.browse.plist
WARNING: Service sharePoints folder does not exist for browsing.
curServicePath := /.ServerBackups/mailServer/mailServer.browse.plist
WARNING: Service mailServer folder does not exist for browsing.
curServicePath := /.ServerBackups/webServer/webServer.browse.plist
WARNING: Service webServer folder does not exist for browsing.
curServicePath := /.ServerBackups/iChatServer/iChatServer.browse.plist
WARNING: Service iChatServer folder does not exist for browsing.

There are usually a lot of warnings, as any given server might not be in use on the server. There is a postBackupComplete commandlet that is supposed to remove the .ServerBackups directory following the backups; however, the default behavior seems to be to remove the directory without requiring that option.

You can then view the backup snapshots by path (they can also be viewed by cd’ing straight into them):

/usr/sbin/ServerBackup -cmd list

To delete a snapshot from the list shown (where <PATH> is a path from the output of list):

/usr/sbin/ServerBackup -cmd purgeSnapShot -path <PATH>

The backup files themselves are actually the service name followed by a .conf extension; however, the data in the configuration files are just the output of a serveradmin settings of the service, such as what you would get from the following:

serveradmin settings afp > afp.conf

For running services, there’s also a .status file (personally, I’d prefer a .fullstatus file instead if I had my druthers). While all services are exported, and can be manually restored by flipping that > from the above command to a <, some services can also be restored using the services commandlet. To see a list of services that are backed up specifically and can be granularly installed as an option:

/usr/sbin/ServerBackup -cmd services

To restore:

/usr/sbin/ServerBackup -cmd restore -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target /

To restore a specific service (for example, the iCal Server):

/usr/sbin/ServerBackup -cmd restoreService -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target / -service

Currently, ServerBackup is not included in the daily, nightly or monthly periodic scripts and it does not back up actual data, just settings, so if you’re going to rely on it, you might need to automate server settings backups as needed. The ServerBackup command does a few pretty cool things. However, there is a lot more work needed to get it to be holistic. We’ve been working on scripts for similar tasks for a long time. For more information on that see sabackup.sourceforge.net (although we’re likely to relocate it to github soon). For more information on ServerBackup itself, see the help page (no man page as of yet):

/usr/sbin/serverbackup -help

To see what version that ServerBackup is using (not actually very helpful but can be used to programatically verify ServerBackup is using the latest version):

/usr/sbin/ServerBackup -cmd version

Supposedly there is a prefs command, but I have yet to actually get it to do anything:

/usr/sbin/ServerBackup -cmd prefs

Finally, if you are scripting this stuff, don’t forget quotes (as you might have a space in the hostname). Also, a quick sanity check to determine size and make sure there’s available capacity using the size command let, which only outputs the required space for a ServerBackup backup:

/usr/sbin/ServerBackup -cmd size

Ubuntu Unix

Server Admin on Linux

Apple recently announced the end of the Apple Xserve. The data center is a funny thing, and being such rack space is critical to most who spend a lot of time there. Many of the previous Xserve customers will continue to buy Mac Pro’s and use them in racks as tall Xserves. Others will purchase Mac Mini’s and use them for certain situations. But many will move on to using the same iron in the data center that they use for everything else, finding a way to duplicate or replace the functionality that was previously in the Xserve with something else.

Server Admin is not going to run on Linux. But you can get kinda’ close and if you really miss the GUI for DNS (not likely) and the other services (possible and in some cases highly likely) then you can hax0r the stuff to look as much like Server Admin as you want. In fact, given the number of developers and the open source nature, the tools available on Linux are likely to even blow away what you could do before. However, there’s a much steeper learning curve and that’s why many (not all) in the Xserve camp have stuck it out with Apple all these years.

The easiest and most mature of the solutions that can be used here is Webmin. We’re going to look at installing Webmin on an old Dell Dimension 5150 that’s running Ubuntu Server 10. Warning, there’s gonna’ be some command line here to get ya’ started, but feel free to cut and paste.

First up, install the webmin dependencies. Dependencies are to many the most frustrating thing about working with Open Source software. But never fear, the Webmin team has posted their dependencies as perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime and libio-pty-perl. So, let’s install those with elevated privileges, using apt-get:

apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl

Next, let’s install Webmin itself. Download Webmin:

wget http://prdownloads.sourceforge.net/webadmin/webmin_1.520_all.deb

If that fails, check the version at the Webmin site and re-run using the correct URL, listed on the site. Once you’ve downloaded, it’s time to install. One of the reasons (in my opinion) that Ubuntu is so popular is that like Apple they use a package-type of format for installers. Therefore, think of the dpkg command like the installer command in Mac OS X when used with the –install or -i operator. So assuming your working directory is where you downloaded that package to (*.deb)

dpkg -i webmin_1.520_all.deb

Once it’s finished fire up a web browser and go to port 10000 on your box. You should be prompted to authenticate, which can be done using root as the username and the root password of your box as the password. Once done, go to the module page or search for a third party module if the package you’d like isn’t include, and download the modules you need.

I’m not a huge fan of Webmin, but I’ve heard a lot of talk about “wouldn’t it be great if there were something similar to Server Admin”. Well, the way Roles work in Windows Server is similar and Windows Server can pretty much do anything (include make me coffee). If you are averse to Microsoft servers and/or paying per CAL for licensing, plugging modules into Webmin is pretty darn close as well. Looking at services included in Mac OS X Server, Webmin can manage FTP (Frox/WU-FTP/ProFTPd), NFS, Samba, SSH, SpamAssassin, Squid, Apache (and Webalizer), VPN (PPP/PPTP/IPsec), Mail (Dovecot/Postfix/Sendmail/Procmail/Majordomo), database (MySQL/PostgreSQL), Shorewall, LDAP w/ Kerberos, DHCP, Bind, Jabber, CVS/Subversion, VNC and even Bacula (replacing that Time Machine server concept).

You have way more choices (which isn’t always a good thing). Sure, Webmin is not nearly as pretty as Server Admin and it has many of the same issues of interpreting what are in config files and developing a WTF complex if you make a change in one place vs. the other. But it can also manage VMs and do a lot of other things (ie – monitoring). I still prefer Mac OS X Server for a lot of things, but if someone adds Netatalk (trivial), ports the Apple .schema file in and DAViCal/CardDAV, you’ve got a new version of spaghetti open source pretty similar to Server Admin. A little CSS and you can even make it look just like Server Admin.

Not everyone is going to want to use Ubuntu. I personally end up using Redhat more than I do any other flavor of Linux. For Redhat users, getting Webmin installed is actually even easier. Simply run rpm, specifying the package and you’re off to the races:

rpm -U webmin-1.520-1.noarch.rpm

Finally, I really and truly do not condone a knee-jerk reaction to Apple’s decision to terminate the Xserve. Unless Sarah Connor can do something about it I don’t think it’s coming back. If you absolutely have to move certain services to a different 1U box, then here ya’ go. Otherwise, stay with those new MacPro Servers, you’ll be happier with them in the long run!