A power user’s guide to OS X Server, Mavericks edition

The Mountain Lion version of OS X Server marked the end of a transition for Apple’s server software. When Apple released OS X 10.6 in 2009, Server was an expensive and entirely separate version of OS X that only shipped on Apple’s rack-mountable XServe systems and cost $1,000 if you wanted to run it on any of your other Macs. Fast-forward to 2012 and the XServe was long-dead, OS X Server was a $20 add-on to OS X, and the powerful-but-complex tools used to manage and configure the server software had been thrown out in favor of a greatly simplified application primarily controlled via big on/off switches. It took a couple of years, but Apple had done the same thing to its server hardware and software that it did to Final Cut Pro. The company made its features more accessible for small businesses and high-end consumers at the expense of features important to a subset of professional users.

The Mavericks version of OS X Server ushers in no such sweeping changes. In fact, the scope of the update is closer to the incremental updates that the Mountain Lion version has received between its launch in July of 2012 and now. Despite a version number increase from 2.X to 3.X, OS X Server is finished with the major overhauls. The software has been changed from an enterprise-targeted package to one better suited to power users and small businesses. Now that the transition is complete, it’s clear that slow, steady improvement is the new normal.

This means there’s a little less truly new ground to cover than there was last year, but in keeping with last year’s review, we’re still going to go through all of the services OS X Server offers item by item. This will serve as both an evaluation of those services as well as a basic how-to guide for those who are new to the software—in cases where nothing has changed, we have re-used portions of last year’s review. If you’d like to read more about OS X Server’s transition from an enterprise product to a “prosumer” product, that’s background information that we covered last year.

Installation, setup, and getting started

When configuring a new OS X Server, the install process is the same as it was in Mountain Lion: take any Mac running OS X 10.9 and download and install the Server software package (hereafter Server.app) from the Mac App Store. Unlike Mavericks itself, Server.app 3.0 is still a $19.99 download both for new customers and for people upgrading from Mountain Lion or Lion Server, though download codes are being offered free of (additional) charge to members of Apple’s $99-a-year OS X and iOS developer programs. The older Server.app versions won’t run in Mavericks, and Server.app 3.0 won’t run in Lion or Mountain Lion, so the upgrade process is an all-or-nothing proposition.

Apple has removed most of the more intimidating configuration screens from the Server installation process. Where Mountain Lion Server and older versions would ask for hostname and IP address configuration (among other things), the new Server.app gets right to the point. Agree to the EULA, input an administrator’s username and password, and wait for the first-time setup process to complete. Configuring those more advanced settings can still be done after the fact in Server.app, but for home users, the more intimidating barriers to installation have been removed.

Another consumer-y touch is the addition of new Server Tutorials, which pop up in front of the Server.app window first thing after the first-time setup has completed. The old Server.app had a persistent “Next Steps” area across the bottom of the screen that would assist newbies through some of the server basics, but the Server Tutorials are more friendly and more comprehensive all around.

The new Tutorials aren’t a new feature per se, but they make existing features easier for newbies to learn. Credit: Andrew Cunningham

The older, more exhaustive Help files are still available, as is Apple’s extensive online documentation. Credit: Andrew Cunningham

Each tutorial starts with an objective stated in plain language: “share files” or “provide centralized backup” or “host a website.” Clicking on each section opens up a tutorial that explains services like File Sharing and Time Machine at a high level before providing step-by-step instructions with screenshots and some resources for further reading—the “Advanced Topics” section of Apple’s online OS X Server help is generally the first stop.

Apple’s online help and the old-style Server Help files are all still there in the Mavericks version of OS X Server, but the new Server Tutorials fill a pretty obvious user education gap from older versions of the software. Along with the simplification of the setup process, they make it easier for a Mac enthusiast to make the jump from being a regular old OS X user to an amateur server administrator. Learning OS X Server before was a study in digging into Help files, Googling, and just poking around at stuff until it seemed like it was working, but the tutorials provide neophytes a clearer path from Point A to Point B.

Meet Server.app

Server.app has been spruced up, but it should still be familiar if you used it in Mountain Lion. Credit: Andrew Cunningham

If you want to do basically anything with OS X Server, you’re going to do it with Server.app. This all-in-one server administration tool has completely replaced the more advanced but less user-friendly Server Admin Tools from Lion and older versions of OS X, but it supports most of the same features. The look of the application has changed a little from its Mountain Lion incarnation—linen has been excised, the default window size is wider, and the way items are organized and presented has been rethought, mostly for the better—but it’s still largely the same interface.

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 Mavericks servers using their host names or IP addresses—just click Connect to Server from the Manage menu. Server.app in Mavericks is able to manage both Mavericks servers and older Mountain Lion servers, so if you manage multiple servers and don’t want to upgrade all of them at once, you’ll be able to use the same tool to control them both. Server.app in Mountain Lion couldn’t connect to Lion servers, so this is a welcome change.

Managing a Mountain Lion server from the Mavericks version of Server.app. Credit: Andrew Cunningham

Looking at the left of the screen, start at the top and work your way down. Items in the “Server” section are all about server monitoring and general administration. This is where you can view uptime and log information, usage statistics, log files from your various services, and any alerts that the server may have generated. Even in the Alerts section, Mavericks dumbs things down a bit in the name of user friendliness. Things like “S.M.A.R.T. status” and “Disk unreachable” have been consolidated under “Disk,” while most of the headings have been simplified.

Other Server.app uses include viewing and changing IP address and hostname information, managing your security certificates, and configuring the server’s remote administration options. Your server can be managed remotely using SSH, screen sharing, or other client Macs running Server.app.

Finally, the Server section of Server.app is where you configure push notifications for your services. Push notifications are used with the Mail, Contacts, Calendar, and Profile Manager services to alert your users when new messages or calendar invites or other data comes in. Apple’s support documentation recommends using push notifications with these services as a more efficient alternative to polling the server for data at a set interval. Push notifications 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 sent 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.

Most of your time in Server.app will be spent in the “Accounts” and “Services” sections. We’ll talk more about Accounts later in the Open Directory section, since it’s mostly useful for administrators of small to medium-size businesses using their Macs to manage user credentials and permissions. The panes for Server’s various services are where you’ll spend the vast majority of your time in OS X Server, and we’ll be going through each service one by one to explain their particular uses and features.

The only universal change to all Service panes is the addition of a new Access section that gives you more granular status messages about what the service is doing at a particular point in time, along with a link to an OS X Server help file with more information for each service. Most of the time this message will just tell you whether the service is on or off, but again, the name of the game is user-friendliness. This information will mostly be redundant or unnecessary for the power user, but Apple is working to make Server easier to learn for people new to the software.

Finally, there’s now a separate section in Server.app for “Advanced” services, including DHCP, DNS, FTP, NetInstall, Open Directory, Software Update, and Xsan. These services are all hidden by default in the View menu (again, one assumes, to keep newbies from stumbling onto them), but clicking any of them will cause all of them to show up in Server.app as they normally would in Mountain Lion. We’ll be going through all of them to talk about what they do, but unlike some of the non-advanced services, there are very few changes between the Mavericks and Mountain Lion versions.

Open Directory

Open Directory is one of the core services of OS X Server, and since we’ll be talking about users, groups, and permissions a lot in the next few thousand words, we’ll talk about it first (even if it has been stuck below the “Advanced” services fold in Mavericks).

Open Directory 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. 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. Credit: Andrew Cunningham

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. Your master and replica Open Directory servers will all need to be running the same version of OS X Server, though—trying to use our Mountain Lion server as a replica for our Mavericks server’s Open Directory setup resulted in an error message.

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

Creating a new Open Directory user. Credit: Andrew Cunningham

Users and user groups used to be configured using a Server Admin Tool called Workgroup Manager, which is still doable if you dislike the controls in Server.app. Workgroup Manager is also available as a separate download in Mavericks, 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 in to the server itself, network user accounts that can log in to 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, create, and edit 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 in to 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 users’ 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, as do Time Machine backups (this is a new feature we’ll examine more later on).

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.

Managing large numbers of users with Groups is more convenient than managing them individually. Credit: Andrew Cunningham

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, and a group mailing list, and you can 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—it hasn’t changed much since Mountain Lion. For a home or small Mac-centric business, the barrier to entry is unquestionably lower, and you’ll be able to get a directory up and running without much time investment.

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

Credit: Andrew Cunningham

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 /profilemanager into your browser of choice.

Profile Manager profiles can be distributed to users, user groups, devices, and device groups. This is in addition to the generic “Settings for Everyone” profile shown here. Credit: Andrew Cunningham

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 /myprofiles from each of the devices you want to manage. iPhones, iPads, iPod Touches, and Macs running OS X 10.7, 10.8, or 10.9 are all enrolled and managed pretty much the same way. Older OS X versions are not supported by Profile Manager, but they can still be managed with Workgroup Manager, which we’ll discuss momentarily.

The ability to remotely lock and wipe both iOS devices and Macs in the event of theft, included with Profile Manager, is also available through iCloud and Exchange servers, but this is a great fallback if you don’t have the latter and don’t trust your users to set up the former. Credit: Andrew Cunningham

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. One setting within the profile controls whether that profile can be removed from devices by users after the fact. If you don’t want people removing your profile and potentially compromising your security, make sure you configure that particular option.

After devices are enrolled, administrators can view them, lock or wipe them, and arrange them into groups for easier administration. Detailed hardware information, including MAC addresses, UDIDs, IMEI numbers, and specific model and software information, is stored in the server—for iOS devices you can even see the battery life level as of the last check-in. It’s a powerful tool for administrators looking to track their hardware. Users can also lock and wipe devices on their own without intervention from an administrator.

New to Mavericks are some additional app distribution options. Most notably, you can now distribute apps and media you’ve purchased as part of Apple’s Volume Purchase Program for businesses and educational institutions, a natural fit given Apple’s push into the textbook market. The VPP can also be used to deliver apps built specifically for your business that aren’t publicly available in the App Store, and the Profile Manager will also distribute in-house apps developed through the iOS Developer Enterprise Program.

Tech Republic has a nice overview of what is required to get into the VPP program, which involves confirming that you are who you say you are and that you’re authorized to purchase apps on behalf of your institution. Once you do, you’ll need to download a VPP token and plug it into Server.app to manage your purchases. Using OS X Server along with the VPP site, you should be able to automate installation, uninstallation, and license tracking for the apps and books you buy (similar functionality is also being introduced in other mobile device management services like MaaS360).

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

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 you can 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, the tool can be used to expose more advanced options, but where it’s most useful in Mavericks 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 have any computers that old still in active service.

File sharing

As ever, the File Sharing service in Mavericks is 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.

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.

Choosing protocols, taking names. Note that SMB, not AFP, is now listed first. Credit: Andrew Cunningham

The biggest change to the File Sharing service this time around is so subtle on its service that you might miss it if you don’t use OS X Server all the time: as we reported several months ago, Apple has announced its intention to move away from the AFP protocol, opting instead to use SMB as the default file-sharing protocol for OS X. In Mavericks Server, visible evidence of this shift includes the fact that the SMB protocol is now the first in the list of options when you’re setting up a share and that some AFP-only features like the ability to send messages to connected users are now gone. AFP is still there (and Apple is still willing to improve it if need be, as we’ve seen in our coverage of OS X’s now-resolved 802.11ac problems) and it’s not likely to go away soon, but it will likely become less and less of a priority for Apple as time goes on.

OS X’s SMB implementation has also been upgraded to SMB2, a newer version of the protocol introduced in Windows Vista and improved upon and upgraded further in later versions of Windows. SMB2 was designed in part to reduce the amount of overhead required to transfer files and to make server-client connections more robust. We’ve already seen how drastically SMB file transfers have improved since 10.8.5 over 802.11ac, but are there any differences when transferring files over wired Ethernet?

To test, we hooked one 10.8.5 server, one 10.9.0 server, and one 10.9.0 client up to a router with gigabit Ethernet cables. We ran two different tests—one copying a single large 3.6GB file from each server to the client, and one copying 6.4GB folder of 3,530 images from each server to the client.

The performance improvements are impressive. Copying large files was about 54 percent quicker in Mavericks, while copying smaller files was about 36.5 percent faster. As long as all of the computers on your network have been upgraded to Mavericks, your SMB transfer performance in OS X should be much better than it was, and after years of lagging behind, it’s nice to see that the performance gap between SMB and AFP has been all but eliminated.

Uploading a file to a WebDAV server from Pages in iOS 7. Credit: Andrew Cunningham

WebDAV sharing works the same way it did in Mountain Lion, and it’s still quite persnickety 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):///webdav/. 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.

FTP and SFTP

FTP sharing isn’t part of the core File Sharing service, though it is sort of tied to it. The FTP service in OS X Server can be used to share one of your AFP or SMB shares from the File Sharing service or one of the sites you’ve configured with the Websites service, or you can elect to create a custom standalone share. However, you can only have one FTP share point configured at a time, making it a poor choice if you’re serving several sites you’d like to access via FTP.

Remember, there’s no security inherent to the FTP protocol, and by default any data you send or receive from an FTP share point will be unencrypted. If you’d like to enable encrypted SFTP transfers instead, enable remote login using SSH from your server’s settings as shown above. 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. Enabling SSH enables SFTP—there’s no way to have one without the other, and there’s no way to serve standard FTP with SSH enabled.

Time Machine

The Time Machine backup service really didn’t change a whole lot in between its introduction in Leopard and the version that shipped with Mountain Lion, which is unfortunate given how much low-hanging fruit there was (and still is) to harvest here. At its core, it remains unchanged: if you don’t have a NAS device that supports Time Machine backups, the service in OS X Server is a useful way for home users to back up their Macs without having to plug an external drive in. Turn on the service, select the folder you’d like to store your backups in, and then select your server from the list of available backup disks on each client you’d like to back up.

One minor change in Mavericks makes Time Machine much more useful and partially addresses our complaints from last year about the service’s inflexibility. When creating a backup destination folder, you can now set a limit to the amount of space backups can consume. Previous versions of Time Machine would just keep filling up your drive until there wasn’t any free space left, at which point (and not before) it would begin to delete older files.

Adding an OS X Server share as a backup volume isn’t much different from using an external drive.

There are still plenty of limitations. You can set quotas, but they have to be the same across all Macs, for example—you can’t let one Mac’s backup use 200GB and another 500GB. Plus, only Macs running Mavericks will respect the quotas you can set. You still can’t tell computers you manage through Open Directory or Profile Manager to make backups without touching individual client computers. If you want to set a different backup interval (either on the server or on your client computers), you’re out of luck.

Setting a disk quota for Time Machine backups. Credit: Andrew Cunningham

We’ve still got gripes, but even basic support for backup quotas is an incredibly useful tweak, and it’s exactly the kind of no-brainer feature that the Time Machine service has needed since its inception. It resolves my biggest gripe with the service as someone who uses it at home: I no longer have to put my backups on a separate volume if I don’t want them to expand to consume my entire drive. If you do want user- or device-specific quotas, you could theoretically work around the lack of them by creating a different backup destination with a different disk quota for every Mac you want to back up. It’s not perfect, but for small-scale backup operations it’s much more workable than it was before. For those who need more than the service has to give, a paid alternative like CrashPlan is still worth looking into.

Xcode

The Xcode service is the only one here that’s entirely new to Mavericks, and it will only be useful to those of you who are registered Apple developers with paid-up accounts. If that describes you, you may find it quite useful: the service allows you to set up a local Xcode repository so that several people (or one person on several computers, if that’s your thing) can easily access and change a single Xcode project at the same time.

Setting the service up is relatively simple: you have to install Xcode on your server to build projects with, and you’ll want to either create your own Git repository or connect the server to an existing Git or Subversion (SVN) repository (communication between the server and its clients can happen over HTTP, HTTPS, or SSH). To test on iOS devices you’ve registered with your developer account, you also have to add at least one registered Apple Developer account to the “Developer Teams” section.

Creating a local Git repository. Credit: Andrew Cunningham

Git repos can also be created from within Xcode once you’ve connected to your server. Credit: Andrew Cunningham

One of the core features of the Xcode service is the ability to create and run “bots,” processes that automate the continuous integration of your new code with your existing code. Bots can be scheduled to run at certain times (as often as hourly, as seldom as weekly) or can simply be set to run every time there’s a new code commit. By default, your bot will let people who have committed conflicting code know when they’ve committed conflicting code; you can also set bots up to notify committers about successful integrations and to e-mail third parties about both successful and unsuccessful integrations.

Bots can be added from within Xcode itself on your development Mac, but they can also be added, monitored, and edited from the Web interface accessible at /xcode/bots. From there, depending on the permissions you’ve configured in Server.app, your users can create and view bots, and logged in users can force a manual integration by hitting the “integrate” button.

Creating a bot from within Xcode. Credit: Andrew Cunningham

All of my bots cheerfully humming away, telling me that I’m doing it wrong. Credit: Andrew Cunningham

The Web monitor will give you detailed histories for all your bots as well as allow you to download code.

I’m not much of a coder, so I’ll leave you to dig through Apple’s documentation if you think you might like to use the Xcode service (as a place to start, there’s some enlightening information about the continuous integration features here). It’s a new service that fits right in with the rest of OS X Server—it’s targeted at smaller shops made up of mostly Mac and iOS developers, but in that context it can be quite useful.

Caching

The Caching service isn’t quite new, but if you’re jumping straight from last year’s OS X Server review to this one, you may have missed it—it was one of the services added midway between Server 2.0 and Server 2.2.2. Caching can be thought of as a modern-day replacement to the Software Update service. Where Software Update grabs OS X system updates and other Apple software (think iTunes and Safari updates, not updates handled through the Mac App Store) and stores it for local use, the Caching service grabs those updates in addition to content from the Mac and iOS App Stores, iBooks, iTunes U, and Internet Recovery files and stores them locally to cut down on the amount of traffic between your network and Apple’s servers.

Here’s how it works, with an illustration from Apple’s Help files to elucidate. Turn the Caching service on, and every time a Mac or iOS device on your local network requests any of the listed software from Apple’s servers, your local server will download and store a copy of that software. The next time a device on your local network tries to download that content, it will download from your local server instead of from Apple’s.

This both cuts down on your external bandwidth usage and can drastically speed up transfers—downloading the 5.29GB Mavericks installer to a MacBook Air via a gigabit Ethernet connection took 12 and a half minutes when downloading the software from Apple’s servers. Deleting the installer and downloading it again after verifying that it had been cached shortened the download time to just over one minute. The more Macs and iOS devices you have hitting Apple’s servers for various software and app updates, the more bandwidth and time you’ll save.

An illustration of the Caching service serving multiple clients on different subnets. Credit: Apple

The Caching service works with Macs running OS X 10.8.2 or later and iOS devices running iOS 7 or later, and the only other requirement is that the devices share a public IP address behind a NAT (or, to put it in simpler terms, they need to be on the same local network for the feature to work). Even networks with multiple subnets can use the same Caching server (as shown above) if the various subnets share the same external IP address. Unlike the old Software Update service, the Caching service doesn’t require any additional configuration on your clients or that they be enrolled in Profile Manager or bound to your Open Directory; as long as the clients are running the right software versions, they can take advantage of the service.

There are a few server-side settings to look at as you configure the Caching service: you need to select which volume to cache the content on and how much of that volume’s free space the service can use. The service will begin deleting the least-used content when it reaches the space limit you specify (if you tell it to use “unlimited” space, it will start deleting things when the caching volume has less than 25GB of free space).

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.

OS X clients all the way back to Tiger can be kept updated with the Software Update service (though if you still have Tiger clients in need of updates in 2013, I’d say you’ve got bigger problems). Credit: Andrew Cunningham

The Software Update service can update all of the same things that Apple’s servers can, including Mac firmware updates; updates for Safari, iTunes, and other Apple app updates not handled through the Mac App Store (you can use the Caching service to handle updates for those); 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.

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. The best way to skirt this limitation is to use the Software Update service in concert with a management tool like Apple Remote Desktop, which can force update checks and install manually or on a schedule of your choosing.

Additionally, there’s 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. Like many of OS X Server’s services, Software Update is useful in a home with many Macs or in a small business with Macs numbering in the low-to-mid double digits, but organizations with hundreds or thousands of Macs to manage may find that it doesn’t scale particularly well.

Areas of overlap

If you’re running the Software Update service and the Caching service on the same server at the same time, there are a couple of things to keep in mind. First, since both services will cache system updates, you might end up storing the same update multiple times; OS X point updates are regularly over a gigabyte in size, so this could add up over time. However, since the Caching service only downloads things you and your users actually need, you won’t have to waste gigabytes of space on the ancient OS X updates that Software Update will download in Automatic mode.

Finally, Software Update gives you the ability to hold back certain updates for testing if you’d like, while Caching caches and serves everything without restriction. The same set-it-and-forget-it configuration that makes the Caching service so easy to start using also makes it difficult to live with if you need more granular or advanced controls.

Taken together, the Mail, Calendar, Contacts, and Messages services are OS X Server’s answer to Exchange, though none of them are nearly as complicated or feature-rich. Each service has seen relatively few changes since Mountain Lion, but we’ll check in on all of them just the same.

Mail

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 setting; 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.

The Mail service provides you with just a few basic configuration options. Credit: Andrew Cunningham

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

That client, 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. Otherwise, Mail is about as basic as IMAP mail services get. If your needs are such that they can’t be met by services hosted by the likes of Google and Microsoft, it’s likely that you’ll want something a little more powerful than this.

Calendar

The Calendar service gives each of your users their own calendar and Tasks list (which integrates with the Reminders apps in OS X 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. New to Mavericks is an “Accept group” option to exclude certain groups from delegation; if you want managers to be able to reserve meeting rooms or equipment as they please but would like lower-level employees to have their requests vetted by the delegate, you just have to plug the user group or groups those managers belong to into that field.

Assigning a delegate who can approve or reject all scheduling requests for my new meeting room. The ability to exclude some users from delegation is new to Mavericks. Credit: Andrew Cunningham

Unlike Mail, the Calendar service’s Web client remains intact in Mavericks as long as you’ve also got the Websites service turned on, accessible from your browser at http(s):///webcal. Using the Web client, you can create and view appointments and invitations—aside from some minor rendering differences, it’s identical to the Web client found in Mountain Lion, right down to the inability to read your tasks lists from the Reminders apps. If you need to see those, you’ll need a local client. 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.

Many of OS X Server’s services are equally useful to OS X and iOS clients, but iOS lacks any sort of built-in chat client and so can’t take advantage of a local Messages server by default (despite including an app of the same name). It’s not difficult to find XMPP-enabled chat clients in the App Store if you want them, but you’ll have to navigate those waters on your own.

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

Connecting to the services we’ve configured in the Internet Accounts pane. Credit: Andrew Cunningham

To connect to your services in OS X, open up the Internet Accounts preference pane, scroll to the bottom, and click Add Other Account. Select “Add an OS X server account” and enter your server’s address if it doesn’t appear automatically in the list of nearby servers. Click Continue, enter your user credentials, and then select the services you’d like to use. Only Mountain Lion and Mavericks clients will support 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.

NetInstall

The NetInstall service, known in older OS X Server versions as NetBoot, is a BOOTP-based system that allows Macs to boot from network volumes. This is usually done 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 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 for larger numbers of computers.

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

Before you can enable the NetInstall service, you’ll have to give it a place to store images and other data. Credit: Andrew Cunningham

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 (Wi-Fi 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 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 Mavericks installer located in the Applications volume (if your installer was deleted during an update from an older version of OS X, it can easily be re-downloaded from the Mac App Store again).

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

The System Image Utility comes with Automator actions you can use to customize your OS X images. Credit: Andrew Cunningham

Clicking the Customize button reveals an Automator-like workflow builder that you can use to customize your images with application install packages and 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 Mavericks installer. Credit: Andrew Cunningham

For our purposes, let’s just download the Mavericks installer from the Mac App Store and create a basic NetInstall image of it so that we can install the OS on our Macs without having to re-download the installer a bunch of times or tote around a USB drive. Once you download the Mavericks installer, start up the System Image Utility, select the Install OS X Mavericks entry from the Sources menu, select NetBoot, and click Continue.

One handy addition in Mavericks that wasn’t present in Mountain Lion is the ability to create an Administrator account that will be configured automatically on every Mac that installs OS X from your image. This will save home users a couple of configuration steps, but it’s more useful for businesses that use a local administrator account on all of their computers for use when troubleshooting or fixing things. Name the image whatever you want, create an Administrator account if you’d like, and click Create. Agree to the license agreement and the System Image Utility will automatically dump a NetBoot image in our NetBootSP0 folder from earlier (or anywhere else you specify, if the computer you’re creating the image on won’t actually be serving it).

Configuring images for booting

Return to Server.app and double-click the newly created Mavericks image to configure it for distribution. Check the box under Availability and choose whether to distribute your images using the NFS or HTTP protocol. HTTP is the default, and you’re less likely to run into firewall problems if you stick with it.

After choosing a protocol, you can then set up MAC or model-based restrictions on individual images—this is in addition to the global access restrictions you can configure in the service’s Settings tab. Once you’ve configured your options and enabled an image, the service will turn itself on automatically, 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.

The Mac Model Filter can keep your Macs from trying to boot OS X versions they don’t support. Credit: Andrew Cunningham

Because NetInstall has been a feature on Macs for so long, you should be able to host images for and support PowerPC Macs alongside both newer Intel Macs and older ones dropped from the support list in Lion and Mountain Lion (Mavericks, happily, did not drop support for anything). Using properly configured filters, you can easily provide network booting for Macs going all the way back to the G3 iBooks and PowerBooks if you still have a need for those older machines in your home or business.

Websites

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 backend is supplied by Apache 2.2.24—you’re already using this if you’re running Server 2.2.2 on top of OS X 10.8.5, and both are a few versions behind the current 2.4.6. You can also run PHP (version 5.3.17) and Python (version 2.7.5) code on the server if you’ve enabled those features. If you need access to Apache’s directory structure, it’s located at /Library/Server/Web/Config/apache2.

The Websites service’s simple landing page with links to some of my other services below. Credit: Andrew Cunningham

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 as many new sites as you have space and bandwidth for. Credit: Andrew Cunningham

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 OS X Server’s Help files and also in 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. It’s fine for a basic site and may even be usable as a testing server, but as usual, more advanced administrators will be left to look for a more powerful, customizable solution.

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 sample Wiki page. Credit: Andrew Cunningham

Deciding who can view and who can edit my Wiki page. As usual, these fields are populated by local and Open Directory users on your server. Credit: Andrew Cunningham

The Wiki service fills a role similar to Google Sites in the Google Apps suite, and it 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.

Except for some extremely minor rendering changes and consolidation of a few buttons here and there, the Wiki service’s features are identical to what they were in Mountain Lion Server.

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.

VPN

With proper port forwarding, OS X Server’s VPN service provides a fairly cheap, easy way to set up your own VPN server. Credit: Andrew Cunningham

The VPN service in Mavericks Server continues to support 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 high 200-range, so most home users won’t run into any trouble there—and set separate DNS settings for VPN-connected clients. You can 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.

If you do intend to run your own home VPN server (and there are definitely benefits, particularly if you find yourself working from cafes or other locations with unsecured Wi-Fi networks), there are some other concerns to keep in mind. If you have a standard home Internet connection, the odds are good that your IP address changes from time to time—not the IP address of your computer connected to your home router, but your external IP address that identifies your network to the rest of the world. You might consider a service like DynDNS, which will track that IP address as it changes and make sure the right one is associated with your hostname. You might also look into a business-class Internet connection, which is usually more expensive than a home connection but generally comes with less restrictive terms-of-use, better support, and an option for a static IP address.

Finally, you’ll need to make sure to open the appropriate ports in your router’s firewall to make your server’s VPN service accessible from outside networks. Apple’s comprehensive list of TCP and UDP ports used by OS X and OS X Server is helpful here. The VPN service typically uses UDP 500, UDP 1701, TCP 1723, and UDP 4500.

DHCP

The DHCP service was originally missing from Server.app in the original Mountain Lion Server release but was restored in a subsequent update. Most home and small business users will have a router that already handles this service, but if you have lots of clients on your network, it might behoove you to provide the service using more capable hardware than what comes in most wireless routers.

As in Mountain Lion, the service allows you to configure multiple subnets on different physical network interfaces (or VLANs, for Macs with only one physical network interface), configure your DHCP ranges, set DHCP lease time, reserve specific IP addresses for specific clients, and view information on connected clients. Depending on your router’s firmware, you may actually have more network configuration options there than OS X gives you, but for homes or small businesses it’s nice to have all of these settings available in one simple tool, especially if you’re using it in conjunction with the DNS service and don’t want to have to jump around between different administration tools.

DNS

The DNS service. Credit: Andrew Cunningham

The different types of DNS records available. Credit: Andrew Cunningham

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.

Click the Settings button and then click Show All Records, and you’ll be able to access more granular and advanced DNS settings. These include primary and secondary zones, a number of different types of DNS resource records, and reverse DNS records. There aren’t many other frills, but it will get the job done.

Xsan

The Xsan Admin is a bit of a niche service in an operating system packed with niche services. It interfaces with Xsan 3.1 (up from 3.0 in Mountain Lion), a 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 big Fibre Channel storage arrays.

Because setting Xsan up requires a Fibre Channel network, a couple of OS X Servers, and at least one networked storage array, we can’t give you much more information on the service’s operation than this. The Help files for Server.app and the Xsan Admin tool should be enough to get you started if this is something you’re interested in.

You’ve just been served

And so OS X Server has settled into its new “normal.” Having completed the move from an enterprise-class server product to a home-and-small-business server product in Mountain Lion, Apple has set about simplifying Server’s interface in Mavericks and making its services easier to set up, learn, and use. Major releases will bring changes to Server.app and, on occasion, brand-new services (the Xcode service is the only big addition since 10.8.5 and Server 2.2.2). In between major releases, bugs will be squashed, and smaller services and features will be added and extended. Mavericks in no way alters the Server’s trajectory. Rather, it drives home the “consumerization” of OS X Server that has been happening since the beginning of the decade.

In a very literal sense, OS X Server specializes in push-button solutions—most of them are enabled by toggling a single big button. Its services are easy to set up, but they’re difficult to expand if your needs aren’t met by the baked-in features. When it comes to almost any feature that isn’t exclusively OS X and/or iOS-centric (Mail, Websites, Wiki, and so on), power users and businesses will likely outgrow the services in short order. Thanks to Server’s reliance on standard software like Apache, it’s reasonably easy to install your own custom services yourself if you know what you’re doing, but if that’s the case, you might find yourself wanting server hardware more robust than a Mac Mini (the $999 version of which is Apple’s only offering as of this writing that even approximates server hardware, now that the Mac Pro Server and the Xserve are both dead).

None of this is to say that Server is a bad product (it’s not), just that you should be fully aware of its strengths and weaknesses when you set it up. The Apple-centric stuff here is very useful. The Software Update and Caching services work as advertised, Time Machine is newly useful thanks to its disk space quotas, and Profile Manager is as good a way to manage Macs and iOS devices as any third-party offering. OS X Server also remains one of the more user-friendly ways to run your own VPN, and it’s not half-bad as a file server thanks to its easy UI and diverse protocol support. You get a truckload of features for your $20; it’s just that most of the time a more powerful (and, often, free and more platform-agnostic) alternative already exists.