For a project at work, we decided to use Mac minis as clients. They’re small, cheap, and quiet, and they have enough horsepower to run the applications we wanted to test.
In order to build a stand-alone classroom, we decided to drive them with a Mac mini server running the server version of OS X. This has caused me no end of amusement, frustration, and bemusement, so naturally I thought I’d write about it from the perspective of an experienced Windows admin.
Summary: OS X Server gives you a lot of functionality out of the box, but much of it is feature-poor compared to Windows, or buggy enough to make it useless. Documentation is scanty, and Apple’s support resources are poor compared to Microsoft’s.
Installation is simple, with no worries about drivers or any of the other niggling little hassles attendant on installing Windows Server. OS X asks for an install key code, but it doesn’t validate it with a central server or phone home for activation.
The default installation ships with a large number of services, including DNS, DHCP, netboot, mail, iChat, calendaring, SMB and AFP file sharing, and web publishing. You have to enable and configure each of these services separately through the Server Admin application. I’ll go out on a limb and say that this is roughly the equivalent of the ubiquitous Microsoft Management Console, except that the MMC has an open plug-in architecture that means any vendor can write snap-ins for it. The Server Manager interface is straightforward: servers and services appear in a tree on the left, and details of the selected services appear in a tabbed view on the right. Service status is shown with a small icon next to the service name, and there are controls at the bottom of the window for adding, starting, and stopping services.
Setting up the server with the services I wanted (AFP, netboot, Open Directory, WWW, and Software Update) was a breeze… until I wanted to change the DNS name of the machine. I tried without success to do this; the changeip -checkhostname command reported that my hostname was correct, but it remained stubbornly wrong according to the clients, which could no longer find the original server and refused to try finding the new name. I eventually decided to demote the server from an Open Directory master to standalone and back again– the equivalent of decomissioning a Windows DC and then re-running dcpromo.
Good idea in theory. In practice, the conversion process threw tons of errors, none of which were documented anywhere. (Does “-14893” mean anything to you? Me neither.) The solution: pave the box and start over.
Normally I would have been throwing fits about this, but the installation process was fast and smooth enough that I didn’t mind; I had plenty of other work to occupy me in the meantime. After the reinstall, I gave the server the correct new name, converted it to an Open Directory master, and was off to the races.
In the meantime, some other people had been unpacking and setting up the clients. Now it was time to join them to the Open Directory server. This is like joining a domain in Windows, except that it isn’t much like that at all. Joining a client to OpenDir is more like telling it “hey, look here for account data.” There’s no machine account or object in the sense we think of them in Windows unless you manually create one. When you first boot a virgin Mac OS X client, if it sees an OpenDir server it will offer you the opportunity to connect to it. Once that’s done you can use OpenDir accounts for logon. If not, you can manually join it at any time from the Login Items pane in the Accounts preferences item.
One of the big reasons we wanted to use OS X Server is so we could push policies to the client machines. Apple calls these preferences, and they can be applied to individual user accounts, user groups, computers, or computer groups. There are all sorts of policies; the ones we were interested in were for controlling logon, access to removable media, and a few other related things. Setting up policies is trivial: find the scope you want the policy to apply to, click the appropriate icon (helpfully, these match the icons used in the System Preferences app), and choose which settings to enforce.
In our case, we wanted policies to be applied to computers. Registering a computer requires you to look up the computer’s unique ID and its MAC address, then enter both of these when you create the computer object. At that point you can assign policies to individual computers or computer groups. It was never clear to me when policies were actually applied: some seemed to take effect immediately, others only after a reboot of the client. (No doubt it’s documented somewhere and I just haven’t found it yet.)
The policies themselves are a mix of the obvious (“don’t allow users to mount USB devices”) and the Apple-only (disable Front Row, for example, or force the use of Mac OS X parental controls.) However, there are only a few settings compared to the huge number available in Windows. However, there’s an escape hatch: you can modify the contents of any preference plist file, so even options that can’t normally be changed through the GUI on a local machine can be managed. This is a handy feature.
Unlike Windows group policy there’s no way to push or publish applications to the clients. For this, you need Apple Remote Desktop, for which no precise equivalent exists in the Windows world. It is a combination of a management and inventory tool, a remote shell, and a desktop support application. You can use it to push files, remotely install applications, run arbitrary shell commands, and watch or control a user’s desktop. In our application, we use it to push a bootstrap installer, run it, and take care of some assorted housekeeping. It also has a neat-o mode that lets you observe multiple clients at once in a grid display. This is extremely useful for our environment, because it lets us see a classroom full of client desktops at once.
It’s easy to use ARD for a building-block approach: test a command on one machine, save it for later, run it on multiple machines when needed, and then string it together with other actions into a single set of actions. This made bootstrap setup of our clients much, much easier.
Next: time sync. OS X Server has an NTP service, and it’s easy to turn on and run. You cannot, however, easily instruct clients to use it. You have to push an update to /etc/ntp.conf onto every machine. That’s a pain. Apple Remote Desktop to the rescue, again.
Now, for the complaints, in no particular order.
The Software Update service is balky and buggy. Essentially it’s a custom CGI that runs on the built-in Apache installation. You can pull updates from Apple, choose which ones you want clients to get, and then allow clients to pull them. Great idea in theory, but it just doesn’t work well. Some clients see the right updates, and some don’t. The interface for choosing which updates you want to pull in the first place doesn’t let you select or deselect updates until after you’ve downloaded them, which means you have to wait for your server to sync before you can choose which updates you’d like. I spent about an hour trying to figure out why none of the clients could pull updates, only to learn that the path suggested in the setup dialog is wrong.
Logging is a mess. There are about two bajillion log files, each in a different location, each with different formats. The system console log can be searched, as can the individual component logs shown in Server Manager. However, the event management tools in Windows are easier to use and more complete. The bigger issue is that Windows event log messages are usually quite detailed. Microsoft’s gotten pretty good at writing meaningful event log entries over the years. Apple, not so much.
Bugs! I mentioned the problem I had with OpenDir master-ism earlier. I didn’t run across any show-stopping bugs, but there are still a fair number of rough edges. In fairness, some of these were probably due to me bumbling around.
Documentation: it’s a set of PDF files. I much prefer Microsoft-style layouts that have an easily accessible table of contents in one pane and the content in another. My preferences aside, the docs are nowhere near as detailed as Microsoft’s. You would be hard pressed to deploy Mac OS X Server in an enterprise without an awful lot of around-the-campfire knowledge passed down from greybeards, because the docs don’t include many of the things you’d want to know before basing your business networks on OS X.
Having said that, I found the Mac Enterprise mailing list to be extremely helpful, though I wasn’t always sure what they were talking about. They were able to efficiently answer the few questions I asked, not at all unlike the golden days of mailing lists for Exchange. From reading the list I learned about two very cool system management technologies I plan to make use of: Puppet (a cross-platform scripting language for system management) and Sikuli, which is hard to describe except to say that it’s a screenshot-based scripting environment.
Thus far everyone is happy: the client Macs work, they’re being managed the way we want them, and life is good. As I learn more about how to make OS X Server do cool tricks, I’ll try to post them here.
Tag Archives: Mac OS X
For a project at work, we decided to use Mac minis as clients. They’re small, cheap, and quiet, and they have enough horsepower to run the applications we wanted to test.
Windows users have more security options, and that’s just the way it is. Or is it?
Let’s start with the obvious: I love BitLocker and I cannot lie. Despite its faults, it remains a great example of a real-world security feature that delivers immediate value. It’s fully supported by the OS manufacturer, meets government security standards, and doesn’t have to rely on skanky hacks to work its magic.
Windows laptop users can also take advantage of Seagate’s Momentus FDE line of disk drives. These disks, sometimes called self-encrypting disks or just SEDs, perform hardware encryption, and they are qualified by the US National Security Agency as meeting NSTISSP #11. Unfortunately, these drives require support in the BIOS. Since Apple’s laptops all use EFI instead of the standard x86/x64 BIOS, you can’t just plop a Momentus FDE into your Mac and expect it to work.
The only solution I’ve found to get an SED to work in a modern Mac laptop is from WinMagic. Their SecureDoc product is essentially a full-volume encryption tool that competes directly with BitLocker, as well as with other FVE products from PGP, PointSec, and so on. The big difference: the Mac version of SecureDoc supports Momentus FDE disks. Naturally I had to try it.
Installation is simple: you run an installer, which adds a couple of kernel drivers and modifies the boot loader. If (and only if) it detects an unlocked Momentus FDE as the boot volume, it will ask whether you want to use hardware or software encryption. (The installer also tells you that it will change the system’s hibernation mode, but let’s not get ahead of ourselves yet…)
When you’re done, you must reboot, at which point you see the new (and quite ugly) SecureDoc login screen. When you log in here, the SecureDoc bootloader unlocks the FDE disk and the normal Mac OS X boot cycle proceeds.
The docs ask that you turn off pagefile encryption by unchecking the "Use secure virtual memory" option in the General pane of the Security preferences tool. This makes sense: there’s no reason to ask the OS to encrypt the page file if the disk on which it lives is already encrypted. You must also turn off the "Put hard drive to sleep whenever possible" checkbox, as the OS doesn’t deal well with having the disk go to sleep (and thus get locked) while you’re using it.
In my test install, I ran into an odd problem: the machine would freeze when waking from sleep. The cursor and keyboard would work normally, but I’d get the spinning rainbow pizza of death. After doing some digging, and with the help of WinMagic’s tech support folks, I determined that the system’s hibernation mode wasn’t properly set by the installer. (Page 4 of this document is the only place I’ve found the different hibernation mode codes explained.) Uninstalling the SecureDoc software, manually setting the hibernation mode with the pmset tool, and reinstalling it fixed the problem and it has worked flawlessly since.
The standalone version of SecureDoc doesn’t have the same set of management or control features that BitLocker does. Of course, that’s because WinMagic wants you to buy their server-based toolset, which uses a group policy-like mechanism to enforce whatever encryption policies you choose. Without having tested either the server tool or the Windows version, I’m not ready to pick a winner between BitLocker and SecureDoc, but for the Mac it’s a low-impact solution that does what it says, and I’m happy with it so far.
Given that I’m in Palo Alto, and that probably half of my coworkers use Macs, it’s no surprise that I installed Snow Leopard today. I’m not going to review the OS, or even the Exchange capability, but here are a few notes based on my long-time Entourage use (and not a little time spent with Outlook 2010 over the past few months). Herewith my thoughts:
- The first thing I noticed: Mail.app is smokin’ fast compared to Entourage EWS. I mean, we’re talking lightning. EWS has much improved sync performance compared to DAV sync, but Mail.app leaves it in the dust when it comes to scrolling, searching, and message rendering. I haven’t tried to compare the two programs’ sync speed (and probably won’t, since it’s mostly relevant when you set up a new account).
- Speaking of setup: I was able to set up 4 Exchange accounts in about 10 seconds each: enter e-mail address and password, then let Autodiscover do the rest. EWS Autodiscover works well most of the time, but occasionally it will fail to detect an account.
- By default, Mail creates a single unified Inbox view– exactly what I use in Entourage (and what I wish for in Outlook 2010). However, nowhere can I find where Mail tells me how many messages are in a folder, something I like to keep track of.
- I like it that Mail.app uses the same sounds for sent and received mail that the iPhone does. On the other hand, I dislike the fact that you can’t change these sounds (on either platform). C’mon, Apple.
- Ironically, older versions of Mail would hide some Exchange folders when you connected because Mail couldn’t handle them. Guess what? This version fails to hide some folders, such as “Conversation Action Settings” and “Quick Step Settings”, that Outlook 2010 creates as ostensibly hidden folders in your mailbox root. Oops.
- Entourage seems to do a better job of masking temporary connectivity problems. When Mail.app decides that one of my servers is unreachable, it grays out that server’s entire folder tree and puts the little tilde-looking icon next to the account name. By contrast, Entourage will discreetly add “(Not Connected)” to the account name and leave it at that.
- iCal… well, what can I say? I still don’t like it after all these years. Yes, it syncs with my Exchange calendars now, but its visual display is ugly compared to Entourage (especially for overlapping events), it’s lacking in features, and the task support appears to have been hastily bolted on.
- I’ve never been a user of the Address Book app. Given the way this version works, I’m not about to start. Too much wasted white space and too many missing features. For example, want to see someone’s management chain? Too bad, Address Book doesn’t show that. Feel like searching the GAL? Sorry, no can do (at least not that I can find.)
There are other problems, too– no support for setting your out-of-office status, for example. In terms of fit and finish, there are lots of little grace notes that Entourage gets right but that Apple stumbled with. To show just one example, take a look at these two screen shots, one for each program.
IMHO, Entourage does a better job all around. It tells me that my machine and my appointment are in different time zones. It clearly shows the important data about when my test meeting’s invitees are available. Once you type in an invitee’s name, there’s no way to delete the event in iCal unless you remove all invitees first. Attempting to close the window gives you a chance to edit or send the invite, but not get rid of it altogether. (Bonus: thought it was interesting that Entourage could get and display Atalla’s status (OOF, in this case) but that iCal couldn’t, even though I took the screen shots on the same machine and more or less at the same time.)
More broadly I don’t like going back to the world of having three separate apps for PIM functions. It reminds me of Sidekick for DOS. I much prefer the Outlook/Entourage model of having several different (but related) data types in one place. What makes this worse is that there’s relatively little integration among the Snow Leopard apps. For example, if you’re looking at a contact in Address Book and want to send that person a mail message– too bad. There’s no way to do so. You can, however, right-click an e-mail address in Mail to open that address’ contact card.
Still more broadly, these applications are not very flexible or customizable compared to Entourage. For example, let’s say you want your message reading pane on the right. Too bad! There’s no way in Mail.app to customize it; you need WideMail or something like it, of which there is no Snow Leopard version (yet).
So, Snow Leopard delivers what Apple promised: basic Exchange integration. There are so many things that they’ve left out, though, that I remain disappointed, and I’m thinking that the Microsoft Mac Business Unit has a huge lead already as they move into full-scale development of Outlook for Mac
Big news on the Mac e-mail front.
First, Microsoft has released the Exchange Web Services (EWS) edition of Entourage, which you may remember from back in January. If you’ve been using the beta version, you will almost certainly be pleased with the vast improvements in sync speed since the beta. MS has also fixed a number of annoying sync bugs. Remember, the EWS version requires that you have Exchange 2007 SP1 with update rollup (UR) UR4 or later.
Next, MS announced today that the next version of Mac Office will contain… not Entourage but Outlook for the Mac. They have not yet announced the exact details of what “Outlook” means in the Mac context (except to say that it includes support for AD RMS), but the Entourage Outlook for Mac team is well aware of the major features that Outlook for WIndows has, and based on my discussions with them I am pretty optimistic about what we’ll see in the next version.
A couple of weeks ago, I mentioned that Microsoft had announced their plans to release an Exchange Web Services-based version of Entourage 2008. Well, they’ve gone and done it: this Mactopia page has the link you need to sign in to Microsoft Connect and get the beta bits. Just to reiterate: you won’t see any major changes in the user interface, because there aren’t any. Consider this release to be the UI of Entourage 2008 with a completely different (and much improved!) mechanism for talking to Exchange under the hood.
Great news from Microsoft’s Mac Business Unit: they’ll be releasing a version of Entourage that uses Exchange Web Services. This is great news because WebDAV, the protocol that previous versions of Entourage have used, doesn’t provide full support for every type of Exchange data item. The Exchange Web Services (EWS) version of Entourage will support full synchronization of tasks, notes, and categories with servers running Exchange Server 2007 SP1 or later. This should please some of the folks who have been lamenting the lack of Exchange sync functionality in Entourage. The best part: they’ll release this as a free update to Entourage later this year.
I was recently in Seattle for meetings with my partners (protip: the Bell Harbor Convention Center is an awesome meeting venue). During that time, my team landed a project that requires use of a Mac, so I made the (easy) decision to hand my first-generation MacBook Pro (2.16GHz, 2GB of RAM, plus a 250GB drive I added earlier this year) to Tim and replace it with a new machine. I used it all day yesterday and quite a bit last night, and now I’m using it on my flight home. Here are my first impressions:
- Despite its odd “chiclet” look, the keyboard has a great tactile feel– it’s much less mushy than my old MBP, and it compares favorably with Lenovo’s keyboards (still the best IMHO). Apple has changed around the function key behavior, meaning that I finally have keyboard shortcuts for iTunes control. Interestingly, the cursor arrows still work as paging keys when you hold down “Fn” but they don’t have the labels on them. I sort of miss the small “Enter” button to the right of the space bar, but I’m getting used to it.
- I love the new trackpad, except that it’s a bit noisy. I already used tap-to-click on my prior machine, so the noise isn’t a huge deal. I didn’t have any trouble adapting to the click-and-drag behavior of clicking with my thumb on the pad’s bottom edge and then dragging with a finger. The multitouch behavior is handy, when I actually remember that it exists and use it.
- Screen brightness and quality is outstanding. In my limited testing so far, I haven’t had any problem with the glossy screen finish.
- Battery life is a HUGE improvement over my old machine. I will easily get 4 hours out of this battery on my default workload (mostly Word, some Ecto, and an occasional TV show in iTunes).
- The body structure is a major improvement over the old machine. The screen hinge isn’t floppy, so the screen stays put even with my hardcore typing style, and the perimeter of the case on the bottom half has no flex or give.
- The Migration Assistant did a flawless job of moving about 85GB of data to the new machine over an Ethernet connection. John was quite envious of this feature.
- It’s easier for me to open the lid since there is no longer a release button. (I still prefer Lenovo’s slide-to-unlock mechanism, though)