Server, simplified: A power user’s guide to OS X Server

Update: We've covered the new features in updates 2.1 and 2.2 here.

Even long-time Mac users could be forgiven for not knowing anything about OS X Server, the business-oriented version of the operating system that has been developed alongside the better-known consumer version for as long as OS X has existed. For a long while, the software shipped only with the Xserve, Apple's enterprise-class server hardware. Standalone licenses for the unlimited client version of the software cost $1,000 all the way up until Snow Leopard, when the price dropped to a still-imposing $500.

All this changed in early 2011 when Apple discontinued the Xserve and replaced it with repurposed configurations of the Mac Mini and Mac Pro. The former sold (and continues to sell) at the $1,000 price so appealing to power users and small businesses, though the Mini lacks the Xserve's hardware monitoring features or expandability.

With Lion Server and now Mountain Lion Server, the software has followed the hardware in becoming cheaper and simpler, and in shifting its focus from large businesses to small ones. At $50, Lion Server cost only five percent of what Leopard Server did; at $20, Mountain Lion Server costs less than half of that. As the product has gotten cheaper and within reach of regular people, the tools used to administer it have become correspondingly less complex, both in terms of how difficult they are to use and in how powerful they are.

Because of OS X Server's newly lowered price, because so much has changed since Snow Leopard, and because Ars Technica's lengthy OS X reviews have never touched on Server before (with the exception of a piece we ran in January about using Lion Server in the home), we've got a lot of ground to cover. This article should serve as an introduction to the software's capabilities, an evaluation of how those services work compared to the competition, and a basic how-to guide for getting everything up and running. By the time you're done reading, you should have a decent working knowledge of what this software can do, how to configure it, and whether it's right for you.

Introduction and installation

Unlike Windows Server, which contains a huge number of under-the-hood changes that make it substantially different from the client versions of Windows, Mac OS X Server is and always has been more or less indistinguishable in operation from Mac OS X. The server OS is really just the client OS with the server bits tacked on, and all of the observations made in John Siracusa's characteristically thorough review of Mountain Lion also apply to the server product.

Installing Mountain Lion Server is done through the Mac App Store, just as Lion Server was. Downloading the OS X Server app (hereafter "Server.app") will turn any Mac running Mountain Lion into a server. Snow Leopard Server and previous versions of the software required you to run the software on some sort of desktop, like an iMac or a Mac Mini or an XServe, but Lion Server dropped that stipulation and Mac laptops can now be used as servers, too. Once you've purchased Server.app, you can make as many Macs into OS X Servers as you want. You can also use Server.app to remotely manage your OS X Server from an OS X client.

When you first run Server.app, its wizard will get your server up and running in a few uncomplicated steps. It first walks you through configuring your server for use on a local network or with a domain name you've registered, setting up the server's host name and IP address, and enabling Push Notifications. We'll talk more about how Push Notifications in OS X Server work a little later, but all you need to set them up is an Apple ID (Apple recommends you use a separate Apple ID for your organization, not a personal Apple ID used to purchase apps), which will get you a Push Notifications certificate that needs to be renewed yearly. Once those steps are complete, you're ready to configure your server.

Downloading and running Server.app prompts a few changes to the operating system itself: the Screen Sharing and Remote Login features are both enabled automatically to make remote administration easier, for example. A Lion server would also set itself never to go to sleep while plugged in, and it would also change the About This Mac dialog to tell you that you were in fact running OS X Server—but these changes aren't made in Mountain Lion.

The first issue is easy enough to correct if you need an always-on server. The second was only ever a superficial change, but it makes a point: "OS X Server" no longer exists as a separate product. There's only OS X, which runs something called Server.app. OS X Server lives on in Apple's branding, but such a distinction is no longer made in the operating system itself. Depending on how Apple chooses to proceed, this could be the beginning of an effort to separate Server from the normal OS X development cycle, making it a version-agnostic app instead, but that's something we probably won't know for sure until we start hearing about OS X 10.9.

Goodbye Server Admin Tools, hello again Server.app

The primary tools used to administer past OS X Server versions were called the Server Admin Tools. These tools—which included Server Admin, Workgroup Manager, and System Image Utility—were each separate applications that gave users fairly comprehensive control over their server's settings. Server Admin, in particular, was the bread-and-butter administration tool that exposed the settings for most of OS X Server's features. (For you Windows Server admins out there, Server Admin in OS X is roughly analogous to Server Manager in Windows.)

Lion changed that with something called Server.app, which took some of OS X Server's services and greatly simplified their administration, to mixed effect. Server.app's role was to make the product more appealing to users and to novice server administrators, and it's no mistake that the services managed by Server.app in Lion were the ones of most use to home users and small offices: file-sharing, mail, calendar, chat, Time Machine, VPN, podcast, the Web and Wiki servers, and basic user, group, and device management. And talk about simplicity—many of these services were reduced to big On/Off switches and a couple of checkboxes. If you wanted to do anything more complicated, the GUI wasn't going to help you much.

To unlock all of Lion Server's features, however, you still needed the Server Admin Tools, which were and still are available as a separate download. Installing and running Server Admin granted access to some of the more advanced services (DHCP, DNS, NAT, the NetBoot service, the Software Update server, Open Directory, the firewall, and a few others) while exposing more advanced settings for the Mail service, while things like Workgroup Manager enabled more advanced user and computer management. Other services that had been present in Snow Leopard Server and older versions (Print, QuickTime Server, and others, most of which could safely be considered vestigial) didn't make the jump, and aren't present in either Server.app or Server Admin.

In Mountain Lion, though, the Server Admin Tools are dead with only a couple of exceptions. Server.app picks up most of the slack, adding DNS, FTP, NetBoot, Open Directory, Software Update, and Xsan to the list of things it could already do, but basic networking functions like DHCP and NAT are gone from the GUI, and are now handled through the command line and by Internet Sharing in the System Preferences, as is the server's software firewall. The Podcast service is gone entirely.

The move to bury things like DHCP makes sense: most home users and small offices are going to have a router that already takes care of DHCP and NAT for them, while medium-to-large businesses will likely have Windows or Linux-based implementations already in place. Mountain Lion's subtractions should be harmless for many users, but if you relied on OS X Server for any of this before, you'll either have to re-learn the GUI or look elsewhere to provide these services now.

Notes for upgraders

When upgrading a computer running Snow Leopard Server to Lion from the App Store, the installer was intelligent enough to download and install Server.app along with it, transferring settings from Server Admin to Server.app. The Server Admin Tools were still a separate download, but settings for services managed by Server Admin were still there.

The upgrade path from Lion Server to Mountain Lion Server is slightly less automated: Mountain Lion will keep Lion's version of Server.app (which won't run in Mountain Lion), and you'll need to download the current version from the App Store separately. Happily, most of your Lion Server's settings remain intact (with the notable exception of File Sharing share points), and the settings from the last of the old Server Admin services seem to come over into Server.app without any issues, but it's odd that upgrading requires a manual download of Server.app when Apple is clearly able to provide it automatically. Once you've installed the Mountain Lion version of Server.app, the Lion version can be trashed; if the Server Admin Tools were present on your Lion computer, they are uninstalled automatically during the upgrade.

One final recommendation for upgraders: I recommend patience even when upgrading OS X clients since the updates that fix the most severe bugs usually come out quickly, and this recommendation is doubly prudent for OS X Server. Check out the release notes from the server version of 10.7.4 and compare them to the client version—OS X Server's updates contain major and far-reaching fixes for services, and the unreliability and inconsistency that new OS X versions often exhibit at first is much, much harder to tolerate in a server room than on your desktop. If you're the type to install new OS X versions on your Macs as soon as they're out, you should wait until at least 10.8.2 before you even think about upgrading a server. The fact that Mountain Lion Server doesn't drastically change or upgrade many of Lion Server's services should make this wait easier.

Using Server.app

With the death of the Server Admin Tools, Server.app has become the heart of OS X Server: if it's not in here, you either 1) can't do it or 2) you will need to hack around in the command line to make it happen.

Server.app is used to:

• Manage local and Open Directory users and groups
• Enable, disable, and configure services, all of which we'll be discussing individually
• Add SSL certificates
• Set remote management preferences
• Enable push notifications
• Check your server's status and log messages

You can launch the app directly from the server itself, or you can install it on any OS X client computer and connect to your Mountain Lion servers using their host names or IP addresses—just click Connect to Server from the Manage menu.

The old Server Admin could be used to manage servers running the current version of OS X Server and the immediately preceding version, but Server.app can only be used to manage the same version of OS X. That is, Lion versions of Server.app can't manage Mountain Lion servers and vice versa. The Lion version of the Server Admin Tools also cannot be installed on a computer running Mountain Lion, and the Server Admin Tools will be removed during installation when upgrading from Lion to Mountain Lion.

The Hardware tab is, obviously, where you can see your server's tech specs, but it's also where you configure remote administration settings, network settings, and push notifications. Push notifications are used with the Mail, Contacts, Calendar, and Profile Manager services to alert your users when new events or messages occur and to push out new configuration settings, and they are also used to alert server administrators when new Alerts are generated—any Mac that has connected to your server using Server.app will receive these Alerts in its Notification Center.

Push notifications can be pushed from your server to any OS X or iOS client that it manages—you first need to get a Push Notification Service certificate from Apple using an organizational Apple ID, as opposed to the personal Apple ID that you might use in the Mac App Store or with an Apple Developer account. The certificate, which is used to encrypt the communication between your server and your clients, is free, but it must be renewed yearly.

You also manage your server's SSL certificates from Server.app—one self-signed SSL certificate is created automatically for you, but clicking Edit will allow you to create new self-signed certificates and import signed certificates. You can choose to use one certificate for all services your server offers, or assign separate certificates to different services.

The Status section is where you can view service logs, resource usage information, and alerts about your server's status.

Customizing Alerts settings in Server.app. Alerts allow for some light hardware monitoring, including disk space shortages, hard drive S.M.A.R.T. status, and network configuration changes.

Server.app has two major shortcomings: the first is that while its extreme simplicity is great for consumers, almost every service here has fewer options than it did in the old Server Admin. Some things can still be changed via the Terminal, but the GUI has become far less sophisticated.

The second problem is that Server.app can be a bit unstable. In the weeks I’ve spent with the Mountain Lion version, I’ve had it crash on me a number of times, normally while trying to change settings. At best, it’s a bit laggy—Lion Server has some of the same lag problems, but I don’t experience many crashes with it, so I’d expect at least these problems to be ironed out as Mountain Lion point updates begin to filter out.

Open Directory

Open Directory, one of the core services of OS X Server, is an LDAP-based directory system that allows you to create and manage user accounts and groups of user accounts. Like Microsoft's Active Directory, it allows your users to log in to computers and services using one username and password, and administrators can use it to enforce preferences and security settings on Macs and iOS devices, which we'll get into when we talk about the Profile Manager.

Open Directory creation and administration is handled completely within Server.app—open the service and switch it on to trigger the configuration wizard.

Creating a Directory Administrator account for Open Directory.

We'll be creating a new Open Directory domain for our testbed, but note that you can also bind one Open Directory server to another to create a replica server which will provide redundancy in the case of server failure. If any of your servers go down, your client computers should automatically fail over to one of the working replicas until the borked machine comes back up. If you have multiple Open Directory servers, you can use the Locales feature to assign different servers to different network subnets to help with load balancing.

While setting up a new Open Directory, you'll be asked to set up a directory administrator account that's separate from the administrator account used to manage the server itself. We'll stick with the default "diradmin" username for our purposes, but the account can be named anything you want. Once you've finished this step, you're basically done with setup; you can turn to the Users and Groups sections to begin building your directory.

Users and Groups

Users and user groups used to be configured using a Server Admin Tool called Workgroup Manager, which was still doable in Lion if you didn't like the new controls in Server.app. Workgroup Manager is still available as a separate download in Mountain Lion, but the Users and Groups panes in Server.app have been tweaked to include the most important of the old options.

Three different kinds of users can live on your Open Directory server: local user accounts that can only log into the server itself, network user accounts that can log into computers bound to your directory and make use of your server's services, and network service accounts that can only be used to access services. You can view and create all these types of users in the Users pane.

When creating network users, you must give them a full name, a short name, and a password, and you can also enter an e-mail address for them—the Contacts service pulls from Open Directory to autofill names and e-mail addresses, so be sure to input the information just as you'd like to see it. The Home Folder drop-down menu is where you choose whether to make this a standard network account or a service account.

If you set up a file share to store user Home folders in the File Sharing service, you can also choose whether to let your network users have their profiles stored on the hard drives of Macs they log into, or whether the profile is saved to the server. The second option is Apple's version of Microsoft's Roaming Profiles—logging in and working with files can be a bit slower due to network latency, but all of the user's files and settings are automatically available no matter what computer they're using.

Using the Disk Quota field, you can limit the amount of server space a user's profile is allowed to consume. It's worth noting that this quota amount doesn't apply to all services—Mail accounts have their own quotas, and the Time Machine service doesn't appear to respect any quota settings at all.

Once created, you can manage users' access to individual services on your server—allowing them to use Mail, for example, without using Time Machine or the VPN. Within the users pane, you can also set password policies (including things like minimum length and expiration dates), and the Edit Mail Options field allows you to set up mail forwarding for individual accounts if you won't be giving them access to their own e-mail account on your server.

If you have a large number of users, splitting them up into groups and managing their settings that way may be more convenient. While you can't set disk quotas and home directories according to group, you can grant and block groups' access to services, and you can also give each of your groups a file share, a Wiki page, a group mailing list, and automatically make group members buddies in the Messages application if you have the service turned on.

Comparison with Active Directory

Open Directory is without a doubt simpler to configure than a full-blown Active Directory implementation. Configuring users and groups in Server.app is also much simpler than it was in the old Workgroup Manager, while not being as useless as it was in Lion's Server.app.

That simplicity comes at the cost of features, however. Most notably, Open Directory lacks any of the software installation features of Active Directory—administrators will need to rely on Apple Remote Desktop or a third-party product like the Casper Suite for the installation and patching of third-party applications.

Another missing feature (one that has been missing since Snow Leopard) is the ability to bind Windows computers to an Open Directory server. For mixed networks of Windows and OS X computers, Apple now tells server admins to bind Macs to both an Active Directory server and an Open Directory server, a configuration it calls a "magic triangle"—the Active Directory server handles authentication and settings for the Windows computers and authentication for the Macs, while the Open Directory server controls settings for Macs. It's a pretty big feature to lose, though in practice most businesses aren't going to notice. Active Directory is more or less ubiquitous in the enterprise, so it's usually enough for OS X Server to be able to integrate with those existing directories rather than trying to supplant them.

Profile Manager

In previous versions of the software, Mac settings were managed centrally with the Workgroup Manager app. Lion Server introduced a tool called Profile Manager, which manages the same settings for Macs and also allows you to manage iOS devices.

After Open Directory, Profile Manager is probably the most valuable service included in OS X Server—with it, you can create and disseminate configuration profiles to your Macs and iOS devices, automatically configuring everything from e-mail accounts to passcode requirements to Dock icons. Once clients have installed one of your configuration profiles, you can also push out updated settings automatically if you have a Push Notifications certificate enabled on your server.

Profiles are created in the form of .mobileconfig files, the same sort of files that are created by the iPhone Configuration Utility and the Apple Configurator, but they can also be used to manage Macs. Once you've enabled the Profile Manager, enable Device Management and enter the settings it wants—an organization name and e-mail address and an SSL certificate—and you'll be ready to start managing devices.

The default profile is called "Settings for Everyone" and can be configured or replaced by using the Web-based Profile Manager portal. For services that you've configured—Mail, VPN, Calendar, and a few others—checking the "Include configuration for services" box is an easy way to make sure everyone connected to your network can at least have access to those services. If you need more granular options, click the Open Profile Manager link in Server.app, also accessible by typing <your server name>/profilemanager into your browser of choice.

Profile Manager profiles can be distributed to users, user groups, devices, and device groups.

Once in Profile Manager, you can view all of the users and groups we created in Open Directory earlier. We can also see fields for devices and device groups, but they aren't populated yet. To make things show up there, we'll need to navigate to the Profile Manager login page at <your server name>/myprofiles from each of the devices you want to manage. I'll be using an iPad in all of my examples here, but iPhones, iPod Touches, and Macs running OS X 10.7 or 10.8 are all handled pretty much the same way. Older OS X versions are not supported by Profile Manager, but can still be managed with Workgroup Manager, which we'll discuss momentarily.

Once you've signed in using a network user account, you'll be presented with a big blue button that will let you enroll your device. Once enrolled, it will show up in your administrator's Profile Manager, where you can view, edit, and push out new settings as desired. If you're working with a self-signed SSL certificate, you may also need to install the Trust Profile for your organization from the Profiles tab before your devices will be able to install your profiles.

After devices are enrolled, administrators can view them, lock or wipe them, and arrange them into groups for easier administration. Users can also lock and wipe devices on their own without intervention from an administrator.

Grouping many devices that need to share the same settings—like Macs in a computer lab, for example—can simplify administration.

Almost every setting available in the iOS Settings app or OS X's System Preferences window can be controlled using the .mobileconfig files generated by Profile Manager. Click Edit and you'll see all of the settings you can configure. Some, like Mail, VPN, security certificates, and wireless network settings can be configured for both OS X and iOS, while others are restricted specifically to iOS (device restrictions like the use of iCloud backups or in-app purchases) or OS X (Dock icons, Gatekeeper settings, roaming profiles, printer settings, and others). You can also upload custom .plist files to apply to your OS X computers to configure third-party apps not accounted for in the Profile Manager, and deploy volume licensed iOS apps.

Profile Manager is a powerful tool for directory administrators, and it's also usable if you have a large number of OS X and iOS devices at home (or if your children have their own iOS devices and you'd like to be able to set universal restrictions on them)—you'll just have to decide if managing the devices centrally is more of a hassle than just configuring each one manually.

Workgroup Manager: Managing older Macs

The Workgroup Manager is the sole Server Admin Tool still available from Apple as a separate download. If the Users and Groups options in Server.app aren't to your liking, it can be used to expose more advanced options, but where it's most useful in Mountain Lion Server is in its ability to manage older Macs, since pre-Lion operating systems don't support the configuration profiles that Profile Manager spits out.

After downloading and installing the Workgroup Manager, open it and connect to your server using the Directory Administrator account you created when you first configured Open Directory. Once authenticated, you'll be able to view all users and user groups in your directory, as well as all of the Macs that you've bound to Open Directory. These Macs can also be placed into groups for your convenience.

Selecting any user, user group, computer, or computer group and clicking the Preferences button at the top of the window will expose a System Preferences-like list of settings that you can use to configure your Macs' docks, network settings, login window settings, and more. You can already do all of this for Lion and Mountain Lion-equipped Macs using Profile Manager profiles, but Workgroup Manager enables management of all settings for both Leopard and Snow Leopard, and management of some settings for Tiger as well, in the event that you still have any computers that old still in active service.

File Sharing

The file-sharing service in Mountain Lion is unchanged from Lion. It's still an extension of the file-sharing features in the client version of OS X, adding WebDAV support and more robust permissions management to the existing Apple File-sharing Protocol (AFP) and Server Message Block (SMB) protocols supported by the client version of the operating system. You can also add custom greetings to your AFP share points here, and you can view the IP addresses, protocols, and usernames of all users connected to one of your share points. The AFP protocol also allows you to send messages to connected users and disconnect them from the server in the event that they've been idle for too long or are causing other problems.

After enabling the service, the system will create a number of default share points, all of which can be edited or deleted as needed. Click the plus button to add a new volume or folder as an additional share point, and then click the Settings button and "Edit share point" to adjust the permissions on the share. You can grant users read-only access, read and write access, or no access; allow or disallow guest access for a particular share; and choose to make certain shares available for the roaming user profiles that we touched upon earlier.

The AFP protocol is rock-solid as you would expect, but communication over the other protocols is a bit spottier. For example, trying to run any executable on a Windows computer from a Mountain Lion-hosted SMB share will result in an error message. In Lion, Apple switched to using its own in-house SMB protocol rather than the open-source Samba implementation it had been using before, and while there are some benefits (browsing an SMB server with many files is much faster from a Lion client than from a Snow Leopard client), it also introduces some quirks. For example, I found running Windows executables from an SMB share on my test server to be impossible, a problem I also had with Lion Server. In both cases, running files required me to first copy them from the share to my hard drive.

WebDAV sharing isn't as flaky in its operation, but it is particular about who can use it and how WebDAV shares are accessed. Most notably, the service will only allow Open Directory users, not users local to your server, to access WebDAV shares. You'll also need the precise URL for every share point you'd like to access; the format is http(s)://<your server name>/webdav/<case-sensitive share point name>. Once I was doing all of these things properly, I was able to connect to my WebDAV shares from both OS X and Pages and copy some documents back and forth.

If you're a home user who wants to make your files available over the Internet (or if you'd like to make any of your services available when you're away from your home network), you'll probably need to configure port forwarding on your router, and to make things easier you'll probably also want a DNS name to go with your IP address (since the address used to reach your network from the Internet sometimes changes for most home users). Portforward.com keeps excellent guides for configuring port forwarding on a wide range of routers, and services like DynDNS offer DNS services for home Internet users (they've recently discontinued their free product, but their Remote Access tier is still only $20 per year).

FTP (and SFTP)

The FTP service was completely removed from Server.app and Server Admin in Lion, and had to be enabled via the command line. Mountain Lion brings it back. FTP isn't technically part of the File Sharing service, but it works much the same way and it fits in nicely with the other file transfer protocols. You can enable FTP for any sites you've configured with the Websites server, turn on FTP for share points already available over one or more of the File Sharing protocols, and configure separate standalone FTP shares as well.

Remember, there's no security inherent to the FTP protocol, so you'll want to be careful with what you use it for. If you'd like to enable encrypted SFTP transfers instead, enable SSH in the Hardware settings in Server.app. You can also do this from within System Preferences on the server. Go to Sharing and enable Remote Login, which will enable SFTP along with the SSH remote login service.

NetInstall

The NetInstall service, formerly known as NetBoot, is new to Server.app in Mountain Lion. While the interface has changed in its move from Server Admin, its underpinnings remain the same: NetInstall is a BOOTP-based system that allows Macs to boot from network volumes, usually for the purposes of recovering files, running diagnostics, or installing clean or pre-configured OS X images on Macs.

Booting from a networked volume can be initiated either by holding the N key as your Mac starts up, or by selecting a network volume in the Startup Disk preference pane. NetInstall forms the backbone of the Lion Internet Recovery feature that lets newer Macs download a fresh copy of OS X from Apple's servers; the difference is that with NetInstall you can serve up your own OS X bits locally. Apple provides tools for the creation of bootable images, though third parties like DeployStudio also use the technology to simplify OS X imaging and deployment.

Apple distinguishes between three different kinds of bootable volumes: first are NetBoot images, which allow computers to boot to a full OS X installation hosted on a server. To store user files, NetBoot images can use space on the local Mac's hard drive or they can be "diskless" images that store user data on the server and allow for the built-in hard drive to be completely unmounted—useful for disk imaging and diagnostics. Second, there are NetInstall images, which are more or less network-hosted versions of OS X install media. Third, you have NetRestore images, which can dump a custom OS X image directly to your Mac's hard drive.

We need to attend to a couple of things before we can flip on the NetInstall service: first, choose which Ethernet port you'll use to serve these images (WiFi isn't an option) and the volume you'll use to store both the images themselves and any user data they generate. You'll only really need to worry about the latter if you're configuring diskless NetBoot images. If you store the images on the boot volume, which is the default setting, the NetInstall service creates a NetBootSP0 folder for images and a NetBootClients0 folder for user data in the /Library/NetBoot folder.

The last step is to give the service an image to work with—this is a job for the System Image Utility.

Creating a basic image with the System Image Utility

The System Image Utility can make NetInstall images from bootable volumes and OS X installers from the Mac App Store.

The System Image Utility, the only one of the old Server Admin Tools to survive the transition to Mountain Lion, is buried in Server.app's Tools menu. By default, it gives you a simple menu that you can use to make NetBoot, NetInstall, and NetRestore images from either a bootable OS X volume (either on an external disk or a separate volume on the Mac's hard drive; you cannot make an image of the boot volume) or a Mountain Lion installer located in the Applications volume (this installer can easily be re-downloaded from the Mac App Store after installing Mountain Lion).

One of the System Image Utility's limitations is that it can only create images of the currently running version of OS X—Mountain Lion's System Image Utility can only make Mountain Lion images, Snow Leopard's version can only make Snow Leopard images, and so on. This can make it a bit tedious to create images for multiple OS X versions if you need to support Macs dropped by newer OS X releases.

Clicking the Customize button reveals an Automator-like workflow builder that you can use to customize your images with application install packages, local user accounts, and to set model and/or MAC address-related restrictions on the Macs that can use the image you're creating.

Creating a network-bootable image of the Mountain Lion installer.

For our purposes, let's just download the Mountain Lion installer from the Mac App Store and create a basic NetInstall image of it so that we can install Mountain Lion on our Macs without having to re-download the installer a bunch of times or hack around with a USB drive. Once you download the Mountain Lion installer, start up the System Image Utility, select the Install OS X Mountain Lion entry from the Sources menu, select NetBoot, and click Continue. Name the image whatever you want, click Create, and agree to the license agreement, and the System Image Utility will automatically dump a NetBoot image in our NetBootSP0 folder from earlier.

Configuring images for booting

Return to Server.app and look under the Images tab, then double click the newly created Mountain Lion image to configure it for distribution. Check the box under Availability and choose the protocol you'd like to use to distribute the images. Distributing images over HTTP won't make you open any new ports, but it means that anyone sniffing your Web traffic can see your images and everything in them. Using NFS, which has historically been the default, gets you some security-through-obscurity, but you'll need to open up more ports in your firewall.

In past OS X versions, the service has worked more reliably with NFS than the HTTP protocol, which would often hang while machines attempted to boot, but Mountain Lion doesn't seem to have the same problem. Your mileage may vary depending on your server’s configuration.

NetInstall can host bootable images for multiple OS X versions at once, so you can support older Macs even if they don't support Mountain Lion.

After choosing a protocol, you can then set up MAC or model-based restrictions on individual images—this is in addition to the universal access restrictions you can configure in the service's Settings tab. Once you've configured your options and enabled an image, you can turn on the service, at which point your NetBoot images will be visible in the Startup Disk preference pane on other Macs on your network. You can host multiple images at once, but the image set as default will be the one your Macs try to boot from if you start them while holding down the N key.

When working with Mountain Lion images, the Mac Model Filter is now intelligent enough to let you select only Macs that the image can actually boot—for Lion and older images, OS X Server just gives you a big list of all Mac models, allowing you to do something as counterproductive as setting a Snow Leopard image as the default for PowerPC computers. As long as you're up on your OS X compatibility lists, though, you can happily host images for PowerPC Macs alongside both newer Intel Macs and older ones dropped from the support list in Lion and Mountain Lion.

Bizarrely, some of the names and descriptions of the Macs in the filter list don’t match their actual model number, but if you hover the cursor over the entry you can get the exact model identifier (MacBook 3,1, iMac 11,3) just to be sure. Using properly configured filters, you can easily provide network booting for Macs going all the way back to the G3 iBooks and PowerBooks.

Mail, Calendar, Contacts, and Messages

The Mail, Calendar, Contacts, and Messages services don't need much explanation beyond their names, which have been changed to reflect the name changes in their corresponding OS X apps (Address Book, iCal, and iChat are out, Contacts, Calendar, and Messages are in).

Taken together, they're OS X Server's answer to Exchange, though none of these services are nearly as complicated or feature-rich. With the exception of Mail, all of these services had already migrated from Server Admin to Server.app in Lion, and there haven't been many changes since, apart from sync support for Mountain Lion's new Notes and Reminders apps (and their iOS counterparts).

Mail

Mail was one of the services that appeared in Server.app in Lion, but left most of its advanced settings back in the old Server Admin app. A few new settings have been added to Server.app to compensate for the loss of Server Admin, but Mail remains one of the services most affected by Lion and Mountain Lion's quest for simplification.

You can use the Mail service to provide POP and IMAP e-mail service for your domain and other domain names that you configure, and you can set the server to accept authentication from local users, Active Directory, and Open Directory users depending on your server and network configuration. You can also add an SMTP mail relay if your Internet service provider puts you behind a firewall that prevents you from sending e-mail directly from your server, and you can set a universal e-mail quota for all accounts here as well (this appears to be an all-or-nothing settings; if one user needs a quota bump, you'll need to give it to everyone). Simple virus and junk mail filtering as well as support for third-party blacklist servers round out the service's features.

Of the many things that Mail has lost since Lion (including the ability to easily set maximum attachment sizes, view user accounts with usage and quota information, and more flexible options for creating mailing lists), the webmail client is probably the one that people will notice the most.

The webmail client in Lion, based on the open-source Roundcube client, could be politely described as "antiquated," and was in desperate need of an update (perhaps with the comparatively slick client that iCloud uses) but Apple instead chose to replace it with... nothing. You'll have to rely on the built-in Mail clients in OS X and iOS (or your IMAP client of choice) by default, though if you're really interested, you should be able to use the Websites service to manually install and configure a webmail front end for your mail server.

The one addition that Mountain Lion Server makes to the Mail service is that it can now be used to store Notes for use with the OS X and iOS apps of the same name, just as third-party e-mail services can store Notes now.

Calendar

The Calendar service gives each of your users their own calendar and new-to-Mountain Lion Tasks list (which integrates with the Reminders apps in Mountain Lion and iOS), and will also let you create locations (like meeting rooms) and resources (like loaner laptops or projectors) that people can reserve. When creating locations and resources, you can either choose to let reservations be approved automatically or assign one of your users to be the delegate who approves and rejects them.

Unlike Mail, the Calendar service's Web client remains intact in Mountain Lion as long as you've also got the Websites service turned on, accessible from your browser at http(s)://<your servername>/webcal. Using the Web client, you can create and view appointments and invitations; oddly enough, while the Tasks list is visible in the Web client, events can't be added (or even viewed once they're added in the OS X and iOS applications). If you've used calendar software in the last few years, you won't be surprised by any of OS X Server's Calendar features.

Contacts

There's very little to say about the Contacts service. It will sync contacts you create across multiple computers (making it potentially useful for families or other groups who want to maintain a shared list of contacts), and will optionally allow results from your directory's users to be displayed when you perform a search in the Contacts app.

Messages

The Messages service enables a simple Extensible Messaging and Presence Protocol (XMPP, or the protocol formerly known as Jabber) server that allows your users to communicate with one another without using a third-party service like AIM or Google Talk. The service's only options allow you to archive all chats (located on the server in /Library/Server/Messages/Data/message_archives) and enable something called "server-to-server federation," which can both enable and restrict communication between user accounts stored in separate directories on different servers.

Connecting to your server

In OS X and iOS, the easiest way to get your clients connected to these services is to include them in configuration profiles you're pushing out. If you're not using Profile Manager (or if you've got Windows, Linux, Android, or other clients), Apple's use of well-supported protocols in all of these services means that you can connect manually from just about any client without much trouble.

To connect to your services in OS X, open up the Mail, Contacts & Calendars preference pane, scroll to the bottom, and click Other. Select "Add a Mac OS X server account" and enter your server's address if it doesn't appear automatically. Click Continue, enter your user credentials, and then select the services you'd like to use. Only Mountain Lion supports the syncing of Reminders and Notes, but older OS X clients can still connect to and use the older services.

To connect with other operating systems, you'll just have to plug your server's name and credentials into programs that support the protocols Apple is using: IMAP and SMTP for Mail, CalDAV for Calendar, CardDAV for Contacts, and XMPP/Jabber for Messages. The process is not as automated as in OS X, but it works.

Analysis

Mail, Calendar, Contacts, and Messages are usable, but even when they were more full-featured they couldn't quite compete with Exchange. The features stripped from the Mail app make them even less competitive now.

Whatever their feature set, I don't see most users getting much mileage out of them: individuals and small businesses will be better served by Google Apps or Office 365, and enterprises could get by either with those services or with their own locally installed Exchange or IMAP servers.

Websites

Even if it isn't activated, the Websites service provides the backbone for several of the other services we've talked about: Profile Manager, the Web-based Calendar, and the Wiki service. The service's back end is supplied by Apache 2.2.22—not, you might notice, the most recent version, which is 2.4—and you can also run PHP (version 5.3.13 with the Suhoshin security patch installed) and Python (version 2.7.2) code on the server if you've enabled them. If you need access to Apache's directory structure, it's located at /Library/Server/Web/Config/apache2.

Turning the Websites service on creates a default website, which you can see if you type localhost/default in your server's browser. By default, it's just a simple landing page with links to some of the different Websites-supported services (like the Web-based calendar and the Profile Manager) linked below, but you can drop different files into the /Library/Server/Web/Data/Sites/Default directory to change that up. Clicking the Edit pencil will allow you to change who can access the site, where its files are stored, and what domains, redirects, and aliases it uses.

You can create new sites by clicking the plus button and setting the domain name, access permissions, SSL certificate, and other settings, and you can configure as many sites on your server as you have storage space (and bandwidth) for. Configuring advanced settings requires going into the Apache configuration files, a process which is partially detailed in Apple's advanced server administration documentation and also on Apache's own documentation for version 2.2.

There are two deterrents to using the Websites service to host anything other than the pages for Server's other services: the first is that, as we saw above, Apple is using less-than-current versions of Apache, PHP, and other software packages. The second is that updates for these packages are bundled with OS X point updates (and later, the security update roll-ups that are released periodically for older OS X versions). If these point updates fix critical problems with one service but an included PHP update breaks a bunch of your code, there's not an easy way to separate them from one another.

Wiki

The Wiki service goes hand-in-hand with the Websites service, both because Wiki depends on Websites to operate and because it's the easiest way to get your users doing something useful with Websites. If you've got any experience with Wikis of any kind, the Wiki service doesn't have many surprises in store for you—they're simple websites that you can use to collaborate with other users, create and maintain posts, and upload and share files.

Creating a Wiki page.

Credit: Nedroid

The Wiki service fills a role similar to Google Sites in the Google Apps suite, and also has more than a little in common with Microsoft's SharePoint (though that software is both more complex and more capable than what's on display here). Using this Wiki software, you can edit and comment on pages, associate pages with other, related pages, see revision history, and get notified when documents or comments are added to a site. Users with access to the Wiki service can create as many Wikis or pages as they want, and user groups you create in Open Directory can be given their own Wikis to facilitate collaboration.

The built-in Wiki service is admittedly pretty simple, but if it isn't to your liking, it's easy enough to install something like MediaWiki to your Websites server and use that instead—OS X Server already includes Apache and PHP, so you'll just have to set up some database server software and you'll be good to go.

Everything else

The aforementioned services are the biggest pieces of the software, and the ones with the most moving parts to talk about. The rest of the offerings range from the practical to curios—by the end of our guide, you'll know about every service OS X Server has to offer, big and small.

VPN

As in Lion Server, the VPN service in Mountain Lion server supports both L2TP and PPTP VPN connections. All you need to do is select the protocols you want to support, your VPN server's hostname (which is separate from your server's regular hostname, a feature new to Mountain Lion), and your shared secret password.

If you'd like to provide VPN settings to clients without handing out information like the shared secret password, you can save a standalone .mobileconfig file right from the VPN service window to hand out (useful if you're not already handing out these settings with the Profile Manager).

You can define the IP address range that VPN-connected clients will use—by default it uses 31 addresses in the 200-range, so most home users won't run into any trouble there—and set separate DNS settings for VPN-connected clients. New to Mountain Lion is the ability to define routes for your clients as well.

The VPN service is considerably easier to set up and configure than something like OpenVPN, and L2TP and PPTP are both widely supported protocols that can be used with most extant versions of Windows, OS X, Linux, iOS, and Android with no issues. The biggest nit to pick here is that offering VPN services on an OS X server doesn't provide any particular benefits for Macs and iOS devices.

Microsoft introduced a feature called DirectAccess in Windows 7 and Windows Server 2008 R2 that allows for seamless, always-on, VPN-like connections between servers and clients that make things a bit less messy for users who need to get on the corporate network from remote locations. While not a requirement for a decent VPN solution, it's too bad that Apple hasn't come up with its own attempt to "fix" the VPN problem.

Time Machine

Time Machine is another service that hasn't really changed since Lion—on the server side, you can enable and disable the service and specify the volume to use for your backups, and all other settings (including file exceptions) are controlled by the clients, as Profile Manager offers no built-in configuration options for Time Machine.

Time Machine backup functionality is offered by most home and small businesses network-attached storage devices at this point, but if you don't have one, the Time Machine service is especially useful for home users with multiple Macs and some free hard drive space. The service can simplify the backup process compared to passing around an external drive.

Once you've configured the Time Machine service, the volume you've configured for backups will appear as an option when choosing a Time Machine drive on your Mac clients. Local and network users or service accounts allowed to use the Time Machine service will be able to authenticate and use the drive as they would any local Time Machine disk.

What's frustrating about the Time Machine service is its complete lack of options—you can't specify disk usage quotas for particular users or computers (user disk quotas defined for network users don't seem to have any bearing on Time Machine's operation), you can't specify backup intervals or bandwidth caps, and while you can specify exceptions for folders and files on client computers, you have no ability to make these exceptions on the server side.

I've been using the Lion version of the Time Machine service on my home network for about six months, and the backup and restore processes are pretty quick and seamless if you're just backing up two or three Macs at once. The service won't scale very far beyond that, though, making it virtually useless in businesses with more than a few employees. If you've got more than a dozen Macs to back up, I'd strongly suggest looking into a third-party alternative like CrashPlan instead.

Software Update

The Software Update service is Apple's equivalent of Microsoft's Windows Server Update Services (WSUS). Your OS X server downloads updates directly from Apple's software update servers. Then, using Profile Manager, you point your Mac clients toward the local update server and they get their updates from you instead of from Apple, saving Internet bandwidth and increasing the speed of large downloads.

When set to Automatic, the service will automatically publish new updates to your Mac clients as they're made available from Apple. Selecting Manual gives you the option to hold back updates for testing before pushing it out to all of your clients. Anyone who has ever installed a new OS X point update on the day it's made available knows that you're taking a certain amount of risk by doing so, and holding all but the most critical security updates for at least a few days makes some sense if you're trying to reduce support calls.

The Software Update service can update all of the same things that Apple's servers can, including Mac firmware updates; iLife, iWork, and other updates for Apple programs; and system updates for OS X versions reaching all the way back to 10.4. A full copy of Apple's update catalog is going to require several gigabytes of hard drive space.

The ability to download and distribute iOS updates from your local server still isn't included, however.

There are also a few other limitations here compared to something like WSUS—while you can hold updates back from your users, there's no way to push them out. Once you've approved an update, your users can pull it down through the normal Software Update process, but you can't mandate that the update be installed and there's no way to check update compliance throughout your organization. If your users choose to defer the updates, there's really not much you can do about it. There's also no way to approve updates for certain groups or individuals while holding them back from other groups and individuals, functionality that WSUS has because of its tight Active Directory integration.

DNS

Of the networking services that used to be included in OS X Server, DNS is the only one left standing in Mountain Lion—DHCP and NAT both went out the window with the Server Admin Tools. This was no mistake: home users and small businesses making use of OS X Server are usually going to have both of these functions handled by their routers, and larger businesses will already have Windows or Linux-based boxes providing both of these services.

As DNS servers go, the one in OS X Server is pretty simple: you can specify forwarding servers to handle requests that your OS X server can't handle (which can either provide redundancy or allow you to use OS X for some DNS requests but not others), decide the computers for which your server should perform lookups (for the server only, for clients on the local network, and for clients on other networks), and configure your host names, IP addresses, and aliases.

The main thing about DNS in Lion, as with all apps that were moved from Server Admin to Server.app, was the degree to which it was condensed and simplified. This screen in Mountain Lion…

…manages to fit more configuration options in a less confusing way than this screen from Lion:

Despite this simplification, you don't lose options in the move from Lion to Mountain Lion, though that's not immediately obvious. Click the Settings button and then clicking Show All Records will let you add primary and secondary zones, and then add a number of different types of records to those zones. Many services gave up complexity in the move from Server Admin to Server.app, but the DNS service at least shows that Server.app is capable of complexity where necessary.

Xsan Admin

The Xsan Admin is a bit of a niche service in an operating system packed with niche services—it interfaces with Xsan 3, an updated version of a formerly stand-alone product that serves as Apple's storage area network (SAN) implementation. Part of the tool lives in Server.app, and the other part can be found in Server.app's Tools menu; between the two of them, they allow you to manage a group of pooled network storage arrays connected together via Fibre Channel.

Because setting Xsan up requires, among other things, a Fibre Channel network, a couple of OS X Servers, and at least one networked storage array, I can't give you much more information on the service's operation than this, but Apple's documentation on the subject is fairly extensive. Suffice it to say that most homes and small businesses won't need to worry about it.

State of the server

When Apple discontinued the Xserve at the beginning of 2011, it sent a message: it was abandoning whatever ambitions it had harbored for the enterprise market, starting with the hardware. That message was restated emphatically when Lion Server came out later that year sporting a consumer-friendly price point and the dumbed-down Server.app in lieu of the administration tools OS X Server had been using for its first decade.

The enterprise has never been a particularly strong market for Apple. As ZDNet's David Chernicoff observed in an Xserve post-mortem, Apple didn't even use Xserves or OS X Server in its own datacenters. The Mac server hardware and software of 2012 has been redesigned to appeal to two different kinds of people: consumers and power users who would never have considered it before because of its price and complexity (i.e., new customers), and small Mac-only businesses or Windows shops that were trying to integrate Macs more fully into their networks (i.e., most of the people who were buying and using OS X Server in the first place). For those people, the functionality you get is a steal at $20, and the product can still do most of the important stuff it could do in previous versions.

My fear in this brave new world is that OS X Server will suffer the same fate as Apple Remote Desktop, another enormously useful tool if you're trying to manage a large number of Macs. Remote Desktop's last major update, version 3.0, was introduced all the way back in 2006. Though it is still technically being maintained and sold in the Mac App Store—its current version is 3.6—most of those point updates have served only to add compatibility with new OS X versions and add incremental feature improvements like IPv6 support.

There's still some good, low-hanging fruit that Apple could harvest to make OS X Server better for the kinds of users they're gunning for—things like centralized FileVault management, the ability to patch iOS with the Software Update service, and local iOS device backups. If the software goes into maintenance mode, I worry that we'll never see server features that keep pace with the features in the OS X client.

We'll probably know whether these fears are founded or not when we start seeing builds of OS X 10.9. For now, especially for home users who have never tried it, OS X Server's new $19.99 price point makes it a tempting proposition. That's a pretty reasonable price even if you only intend to use one or two of the services I've outlined here—Time Machine, File Sharing, VPN, and, to a lesser extent, NetInstall are the only ones I use at home. If you were on the fence at $50, buying Server at $20 is an easier call.

It's no longer a serious alternative to Windows or Linux servers—if in fact it ever was—but most power users in Mac households should find at least something to like.

Update: We've covered the new features in updates 2.1 and 2.2 here.