My takeaway from reading this — and mind you, I have not seen the software yet — is that it’s another step towards the convergence of the Mac OS and iOS. There are a lot of iOS configuration tools, and lot of simplification, and even the removal of some GUI configuration tools. Most surprising to me is that for any sort of web server customization you’ll need to use the command-line; the GUI tools are gone:

“There is something odd going on here though. Go take a look at the web service pane in Server App. Let’s see, on/off; make PHP go and folder paths. That’s it! There isn’t a web service module in Server Admin anymore either. So, um, yeah. What’s up with that?

“What’s up is that it’s all about the command line again. Need a web redirect or an alias? Command line. Need to enable some Apache modules? Command line again. In all this madness is something pretty cool though for web apps.”

Apparently they also removed Windows PDC functionality. I can see no technical reason for these removals, frankly. They seem to be all about communication. They seem to be Apple saying, yet again, we’re moving towards less Professional, less customizable, simpler, more iOS- and consumer-focused products. Get used to it.

Nevertheless, some of the simplifying sounds good to me; it’s ease-of-use that made Mac OS X Server such a fine product. I don’t think I would have ever used it for a web server anyway. Still, it’s worrisome to see things removed for no particular reason.

My guess is that some version of Mac OS X Server will be around for a while. But more and more it will be focused on iOS device configuration and, perhaps (I hope), user management, which is what I always used it for.

Still, as I’ve been saying in the comments lately, it’s probably a good time for Mac Admins to start learning some Linux, or dare I say, even some Windows.

Check out the article and let me know what you think. Or, if you have some experience on Lion Server, I’d love to hear about it.

Mac OS X 10.7 — or Lion as it’s affectionately codenamed — is certainly no exception. In fact, Lion looks to be a very exciting release, both for its wealth of new features and for its refinements to Apple’s already sparkling OS.

It’s an exciting time to be an OS junkie, really. Snow Leopard was a wonderful release that brought stability and refinement to what can finally be called a mature Mac OS X. From here on out OS development seems to be less about making Mac OS X work quickly and succinctly — less about the guts of the OS —  and more about making it work well. That is, from here on out, Mac OS X developers are concentrating on making the Mac OS X experience a wonderful one. And that means even further refinement to an already polished OS, with maybe a dash of experimentation thrown in for good measure, thanks to convergence with Apple’s mobile OS.

I haven’t installed the beta, but I’ve read as much as I’ve been able to find. Here are some images and links, with just a dash of commentary from yours truly thrown in.

Mac OS X Server
One of the shockers about this release is that Mac OS X Server will be included, for free, with the standard Lion DVD. It will be a separate install, but has been discontinued as a separate, paid release. Looks like Apple’s professional server platform is dead, but I’m glad it will live on in some form, at least for the time being.

Images Via AppleInsider

Administrative Tools and Goodies
One of the great things about OS updates — particularly the latest Mac OS X updates — has been further expansion and refinement of any and all administrative tools. This is, needless to say, of particular interest to SysAdmins like us. Here are some updates that Lion brings to the table baked right into the About This Mac window.

Images Via AppleInsider

The Finder
Of course I’m always, always, always happy to see Finder improvements and refinements, and it looks like there will be plenty in Lion.

We have some new and potentially very useful Finder views, though I must admit to not being a great fan of the iOS-like buttons in the toolbar. The sidebar is also toned down (a-la iTunes) and features some new and potentially useful items.

Image Via AppleInsider

Spotlight in The Finder is now smarter and more useful.

Image Via AppleInsider

And my favorite Finder view, column view, even receives some love.

Image Via AppleInsider

And finally, the big Finder news: windows can now be resized from any edge. Just like in Windows.

Image Via TheAppleBlog

Other Improvements
There are a bunch of additional refinements to the core OS. One of my favorites is support for automatically saving documents, or Auto Save as they’re calling it.

Images Via AppleInsider

Auto Save is accessed just like Time Machine, which is just brilliant.

A signature capture utility also makes its way into Preview, allowing you to sign digital documents using that app and your built-in iSight camera.

Image Via 9to5Mac

Dock and Exposé get refinements as well.

Images Via Engadget

Even Spotlight gets better, with larger icons and inline previews.

Image Via AppleInsider

All-in-all, from what I’ve sen so far, Lion is shaping up to be a very nice release. I’m sure there will be under-the-hood improvements that will add performance gains as well. I am, as always, really looking forward to using Apple’s next OS release.

Let’s start with a rundown of the existing approaches.

Roaming Profiles
The approach Windows computers use is called Roaming Profiles. The way Roaming Profiles work is pretty simple. Users’ home account data is stored on a centralizd server. When the user logs in to a client system her data is downloaded from the server to the client machine. She will access her data locally for the duration of the session. When she logs out the data will be synced back up to the server. The advantage of this approach is that the user has local access to her data and isn’t beholden to the network while actually working. This makes data access generally faster and more reliable. The big disadvantage here is that if the user makes any big changes or creates any big files, a large data transfer will happen at log out, and then again at login to subsequent machines that aren’t yet synced to the server. This both slows down the login/logout process and places an often undue burden on the network.

Because of the sorts of environments I tend to work in — data-intensive, video and image oriented facilities that create a lot of data — my experience with Roaming Profiles has been fairly poor. For my uses they’ve required a lot of management and have been somewhat unreliable. But, for the purpose of maintaining a user environment across multiple networked systems, they work well enough if you understand and plan for their inherent limitations.

Network Home Accounts
The method used by *NIX systems, Mac OS X included, for time in memorial, is generally referred to these days as Network Home Accounts. In the Network Home Account model, as with Roaming Profiles, the user’s home account data is stored on a server. But when the user logs in using Network Home Accounts no data transfer occurs. Instead, the home account data is accessed directly from the server: new files are written directly to the server; settings files are read directly from the server; everything happens over the network and the network share that contains the user’s home account data is treated just like a local volume. The speed advantage over Roaming Profiles at login and logout is obvious; there’s simply no lag time as data gets transferred between the client and the server, because there simply is no data transfer. On the other hand, accessing your entire home account over the network can be slower than a local account even on the speediest of networks. And on slower networks, or networks with a great deal of traffic, you’ll definitely notice the slowdown. There are also potential problems due to the constant reliance on the network and server. If the network becomes congested or the share becomes unavailable even for a second you’re liable to feel the pain. If either goes down you’re dead in the water until they’ve returned to service.

As network home account models go, I like this one the best. I’ve used it a great deal in educational settings in which resources are almost completely shared and it’s fairly reliable and usable. But even this model can be frustrating and is less than ideal when compared to working from a local home account.

Portable Home Directories
The final model is called Portable Home Directories. Devised by Apple for laptop computers with occasional — but not constant — access to the network hosting home account data, Portable Home Directories attempts to combine the best of the Roaming Profile and Network Home models by providing finer-grained control over the sync process in what is otherwise a Roaming Profile approach. So, Portable Homes sync to specific data at specified times when they’re on the network. Fine-grained control over what is synced and when is intended to mitigate performance issues at login and logout.

My main problem with this approach is that, in my admittedly limited tests, it doesn’t seem to work very well. I also don’t like the level of management required. The other models, once set, require little if any tweaking whatsoever. But I could see spending a great deal of time and effort getting my Portable Home Directory settings just so.

The Problem
But my overarching beef with all these models is that they don’t really jive with the way most people in most of the environments I’ve encountered actually use their computers. This makes them use system resources less efficiently and yields a poorer user experience than if they did.

So how do most people work? Well, what I’ve tended to see in the media-based environments in which I’ve worked is that users are generally assigned a single computer. It’s this computer from which they work almost all the time. Indeed, this is how I work in my current job. I’m almost always working from the computer in my cubicle. Almost.

Every now and then, however, I need to work from a different machine, and there are often times when I’m doing this that I realize that it would be extremely handy to have my entire home account — all my environment settings, files and folders — available to me on this other machine. But I don’t. They’re over there, on my cubicle machine. If only I could use the home account on my main computer directly, as thought it were a Network Home Account.

And this is the basic idea behind Satellite Home Accounts.

Satellite Home Directories
All the current models rely on the user’s data being stored on and accessed from a centralized server. But why? Why can’t the server be the user’s main computer? In the Satellite Home Account model, the user’s primary computer becomes the home account server for any user that sets her account as a Satellite Home Directory.

The way I envision it, it would actually be quite simple to set up. In the Accounts preference for the user would a be a tickbox to activate Satellite Home Directories. Once activated, the user’s system would begin broadcasting Satellite Home Directory information, just like Mac OS X broadcasts Network Home Account info. The user would then work locally as normal, but when logging into another system on the network — a system that’s listening for SHDs — the user would be presented with her home account over the network, shared directly from her primary system rather than from a centralized server. Simple.

Among the great benefits of this system are its simplicity and the fact that it requires no server. But the chief advantage comes from the fact that the Satellite Home Directory system works the way users tend to work. When you’re on your main computer, which you are 99% of the time, you get a fast, responsive, local home account. When you move temporarily to another system, your environment follows you. It’s a bit slower, sure. But hey, it’s only temporary. The network overhead is significantly reduced from the other methods, and the user experience is also enhanced. It’s win-win.

There’s certainly no technical reason an implementation like this would be impossible or even particularly difficult. Most of the technology already exists, either in Mac OS X client or Server. All we need is for someone to program it. And while I doubt there’s likely much interest on Apple’s part to build something like this, I really think it’d be damn sweet.

And a boy can dream, can’t he?

First off, for the server nerds in the house, Apple now officially sanctions using Minis as workgroup servers.

Bargain Server

We’ve all been doing this for a while now, of course, so it’s nice to see Apple finally offering a bundle. Small, cool, headless and powerful enough for most tasks, the Mini is, for many purposes, an excellent server platform. And, with the client license restrictions removed, Mac OS X Server is a flat $499, making the bundle clock in at just under a grand, so they’re cheap too.

And, of course, this Magic Mouse is simply brilliant.

Magic

It brings together everything I love about my trackpad and my mouse in one device and solves a bunch of input device problems (like left- or right-handedness, and gunked-up moving parts), all in one fell swoop. I can’t wait to get my sweaty mitts on one.

I have to say, I find these surprise product announcements much more thrilling than the usual over-hyped events. I hope to see more of them in the future. This is exciting stuff.

I have noticed (as have many others) a few changes to how Snow Leopard handles certain server-related tasks, and I thought I’d just jot them down for the record — mine as much as yours.

Directory Utility
The first, and possibly weirdest, change is that Directory Utility is no longer a readily available application. It now lives in the very unintuitive /System/Library/Core Services, which tells me that Apple would rather us not use it unless absolutely necessary, which, generally speaking, it should not be, at least not for binding to Open Directory servers. Much of its functionality has moved to other applications and parts of the OS.

OD Server Binding
Curiously, OD binding now happens in the Login Options section of the Accounts preference pane. Even more curiously, you can open the Directory Utility from here as well:

Snow Leopard OD Binding

NFS Mounts
Directory Utility used to have a pane for configuring NFS automounts. That pane has been moved to the arguably more logical Disk Utility application, where you access it under File->NFS Mounts, but it looks pretty much the same as it did before:

Snow Leopard NFS Mounts

Root User
Since 10.5 the root user has also been activated via Directory Utility. I haven’t found a new way to do this. It looks like if that’s your bag you’ll need to either find a way to open Directory Utility, or use the command-line. ‘Course, if you know what root is, you shouldn’t find either of these things terribly difficult. Especially since I just told you two ways to do the first thing.

Directory
There used to be an app called Directory in the Utilities folder, but it too is gone. I’m assuming some of its functionality has been added to Address Book, which now has its very own Accounts preference pane:

Snow Leopard Address Book Accounts

And I’ve read that some of its functionality has been moved to the iCal Server Utility app now included with the 10.6 Server Admin Tools:

iCal Server Utility

I’ve also read that there is some functionality that is completely gone now.

MCX Cache
A fellow SysAdmin has posted his own groovy list of Snow Leopard changes as well. My favorite:

“New command, mcxrefresh, used for refreshing managed preferences on clients”

Hallelujah! I’ve bitched frequently about Mac OS X Server’s overly aggressive cache. Having a way to clear it makes all the difference.

Conclusion
So we have a bit of a shuffling around here, but overall it looks to me like Apple is trying to keep simplifying the OD binding and setup process in Snow Leopard, as they have done with each iteration of Mac OS X. The most obvious features are in obvious places, whereas the more obscure features have been moved to more obscure locations. Most of these changes make sense, too, though dedicated apps for OD setup make sense on some level too. Must everything be another preference pane? In any case, it’s just good to know that all the same stuff is there, it’s just been moved around a bit.

On a personal note, it’s a bit of a bummer to not get to play with Snow Leopard Server. I may never get the chance, actually. It could be long gone by the time we get new hardware, and we just don’t rely on Mac OS X Server like we did at my old job. Ah well life goes on.

If anyone has any Snow Leopard Server stories to share, I’d love to hear them in the comments. As far as reportage goes, though, I’m gonna have to sit this one out.

DokuWiki’s front page describes it thusly:

“DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required.”

No Database
That last little bit — the lack of a database — is actually one of the things that makes DokuWiki unique. It is both its strength and its potential weakness, and one of its defining characteristics.

DokuWiki

If you are looking to install a documentation engine for a small to medium-sized workgroup, it’s true: DokuWiki is great. It’s very easy to install and only requires Apache and PHP be running on your server. This means it can be installed on any Mac OS X machine without having to install or configure much beyond Personal Web Sharing. I say, “much” because you will have to activate (not install) PHP, which isn’t too hard for savvy users, but isn’t exactly mom-friendly either. Still, it beats having to also install and enable a database application like MySQL, which most other wikis require. So DokuWiki is relatively easy to setup.

That lack of a database is nice, in that it makes installation quick and easy. But it’s also a potential drawback, albeit a minor one. DokuWiki writes all its entries to flat files and that could affect scalability, and to some extent performance, if your wiki ever became extremely large. The merits of databases vs. flat files for storing data are debated all over the Internets, but databases usually only offer a significant advantage when dealing with complex, relational data, and that advantage is usually only seen by the developer. For small to mid-sized or even large-ish sites, DokuWiki is great. If you’re worried your wiki might need to grow very large some day (like, to the point where load balancing across multiple servers is required, for instance — we’re talking big!), DokuWiki may not be for you. Otherwise, the flat file system offers additional advantages, like easy-to-parse and repair backups, to name just one.

Wherefore Wiki?
That said, once installed, DokuWiki is very easy to use. It does use its own markup for page layout, but that markup is exceedingly sensible and easy to learn. My biggest stumbling block was getting started: How do you create a page? Well, once you know, it’s pretty simple, but figuring it out took me a minute. The easiest way to create a page, is to navigate to that page. If the page doesn’t exist, DokuWiki allows you to create it. See? Easy! Maybe too easy!

So what’s it for? Well, I’ll tell you, TASB was almost a wiki rather than a blog. While both are types of Content Management Systems (CMSes), and essentially do the same thing — allow a person to easily and rapidly build and read a structured store of text and media data — the difference is intent.

Blogs — and therefore blog engines — are geared toward personal, diaristic, periodic writing. They’re usually organized chronologically, like a diary, and require no special markup when creating entries. Entries, once made, are rarely revised. One of the things I enjoy about writing this blog is that it’s a bit more personal. It’s a record of personal experience as much as, if not more than, documentation. So I stuck with using the blog format. I like to be chatty.

Wikis, on the other hand, are made to be accessed like a reference, like an encyclopedia, for instance. They’re not chronological, but are usually ordered and read alphabetically; and wiki articles are made to be maintained and updated as information changes. Wikipedia is a great example of this. There is also a blog called the Tao of Mac that uses a wiki engine for content management, showing that, in the end, the two types of engines do essentially the same thing. They simply present different capabilities to their users based largely on the purpose of the site.

Conclusion
If you’re looking for a quick, easy-to-use and easy-to-maintain storehouse of information (either for yourself, or for use with others), a wiki is a great thing to have. Need to document a procedure for your workgroup? Put it on the wiki. Need to let everyone know where that essential file is? Put it on the wiki. Just want to jot down some notes for the general use? Put ‘em on the wiki.

After using one for a few days I can already see just how damn handy a wiki is to have. And DokuWiki is super-easy both to install and learn. If you just need something small to document procedures or productions — or if you’re just looking to dip your toe into the world of wikis — DokuWiki is very nice indeed.

UPDATE:
I’ve edited the article for clarity and accuracy regarding the use of flat file systems vs. relational databases. Thanks to DokuWiki’s author for pointing out the error.

Keychain Not Found

The Keychain application also refused to read my keychains. The keychains were there, as they always had been, in ~/Library/Keychains. Keychain.app just refused to see them. Refused to add them — or anything else for that matter — as well. Keychain First Aid reported everything as fine, but the damn things just wouldn’t show up.

Suspecting some sort of weird, post-PHD permissions snafu, I copied the Keychain application to my Desktop and then launched it. This seemed to remedy the problem; the keychains became visible in Keychain.app. But upon re-launching iCal, my keychains became inaccessible again.

Mucking around in Keychain.app, everything looked fine. But I wanted to make sure that my “login” keychain was set to be the default. So I selected another keychain I have, right-clicked it and chose “Make keychain ‘systemsboy’ Default,” then did the same to the login keychain, thus resetting it as the default keychain.

Remaking the Default

After doing this I launched iCal and the password complaints were gone; the calendars all loaded properly. Launching Keychain again, however, seemed to break everything. Again! WTF? No matter what I did, Keychain would eventually lose track of my keychains, and this would cause any application that relied on them to screw up. But I did eventually figure it out.

The solution? Well, it’s so simple and so idiotic it’s hardly worth a post. But here you go: I rebooted.

That’s right. A simple reboot and all my troubles were gone.

Remember, kids: reboot, reboot, reboot!

Almost Proper
Wanting to get PHDs working, I decided to try doing things a bit more by the book. I set up our NFS Home Account Server as an NFS Reshare and shared it out over AFP. I also set my home accounts up properly in WGM, using the AFP share as my network home, and a local folder as my local one.

But PHD kept incorrectly syncing things, to the point where I’ve actually now lost some data. Seems PHD, when it syncs, is for some reason using the data on the network drive as the master data set. Files I’ve modified before leaving for work have been reverted back to their old versions — the ones on the network — over night. (Which is weird considering the fact that I was logged out.)

I’m sure this works in a perfectly standard environment, with no existing users and no NFS Reshares, when set up from scratch. But I have to say, I could not be more frustrated with PHDs. So I’m giving up for now and setting my home account back to the local drive. Of course, even reverting back to a non-managed, non-PHD, local account is difficult in this case.

Cache Insanity
The reason for this — and one of the things that’s made testing PHDs so difficult in general — is the insane level of caching the server does with regards to PHDs. Caching is so aggressive that, even after disabling PHDs on the server and restarting the client machine, the SyncAgent on the client continues to attempt to sync my homes. If I try to stop it I get an error that says I can’t stop it because I don’t have a PHD. I’m a big fan of irony, but not in my server software, thank you very much.

No Mobile Account

So now the PHD service is incorrectly syncing my local home account with a network home it shouldn’t even see. Thousands of conflicts are occurring. I’m losing data. Though I’ve disabled the service, the settings persist. This is terrible. Horrible. Godawful.

PHD Conflict Resolution: Why?

And there is no sanctioned, GUI way to stop this from happening.

Freedom!
Eventually I was able to stop the errant syncing by running the ever-trusty:
sudo dscacheutil -flushcache

Jesus! What a kludge!

You can imagine how difficult this has made my testing. I can’t be sure that any change I’ve made on the server is actually happening on the client, so it’s impossible to know where this is failing or what I might be doing wrong without starting from scratch every time I make a configuration change. And starting from scratch is pretty damned difficult as well, as the PHD settings are persistent to a fault.

Is That All There Is?
I’m not sure what to do with PHDs at this point. I don’t think they’re useful for our environment, or for any existing users. Testing them is downright painful. And data loss is a real possibility, and not a risk I’m willing to take with other users’ data.

So, after a couple weeks of some very frustrating testing, I’m afraid I’ll have to pass on PHDs. It’s a nice idea, but not ready for prime time from where I sit.

There’s a slight chance I’ll try PHDs from scratch with a fresh home account, just to see if it works at all. But we’ll see. I’m pretty annoyed at this point.

More annoyed than I ever was with Windows Roaming Profiles. And that’s a feat.

After some water-cooler-side conversation, and some excellent comments by my excellent readers, I’ve decided I might be just be a perfect candidate for something that may offer the best of both worlds.

Portable Home Directories

Portable Home Directories (PHDs), as they’re called by Apple, essentially allow a user to keep and work from a local copy of his network home account. The local account is synced up with the network account using various strategies, which I’ll talk about in a bit. It’s essentially an intelligent implementation of Windows’ crappy Roaming Profiles. The big difference is those strategies I mentioned.

Windows’ Roaming Profiles are problematic, particularly in production environments where users store a lot of data, because Windows simply hard syncs those profiles at login and logout. This means that if you’ve generated a lot of data in any given session, you’re in for a long wait when you log out — and another long wait if you log into another machine — while Windows syncs your local and network profiles. It’s a nice idea — giving you the centrality of a network account and the responsiveness of a local one — but it fails in practice because it is, essentially, dumb, causing the sync process to ruin the experience.

The experience we’re going for here is, of course, seamlessness. Or as close to it as possible. So: I want to be able to log in to my workstation and have the responsiveness and normalcy of a local account, but I then want to be able to log in to another workstation and have my documents follow me throughout a given facility. Moreover, I want the synchronization of said documents to be as invisible as possible to the user. It should “just work.” With as little waiting and confusion as possible.

This is, of course, easier said than done.

Apple takes a noble stab at this with its Portable Home Directory settings. See, where Microsoft simply syncs account data at login and logout, Apple affords some granularity in what gets synced and at what times. Apple gives you precise control over what gets synced, as well as allowing for not just login and logout syncing, but periodic syncing as well. Smart! And it could make all the difference.

But I’m getting ahead of myself again. Let’s actually step through the process of creating a Portable Home Account. I’ll show where it shines and where it falls apart for me.

Activate Mobility Preferences

• This all starts in Workgroup Manager. So fire that up and navigate to the user you want on Portable Homes.
• Make sure that user’s current home account is a Network Home Account (i.e., it lives on a server somewhere).
• Click the “Preferences” button from the toolbar, and then open the “Mobility” pane. This is where all the action happens.
  

  Mobility Preferences

Set Account Creation Options

• The first thing to set up is how and when the local portable account is created. Click on the Account Creation tab and set Manage: to Always.
• Since I already have a network home account that I’ve been using from an NFS share (on a non-Apple server), I set my user to “Create mobile account when user logs in” using the “default sync settings.” I assumed this would copy everything over from the network account to the local drive and start the ball rolling fresh, but that’s not what happened. More on that in a bit.
  

  Account Creation

• Under Account Creation’s Options tab I set a custom path that pointed to a folder that contained a local version of my home account that I’d rsynced previously. Again, I did this thinking it would speed the initial sync process, but that turned out to not be the case.
  

  Account Creation Options

Set Sync Rules

• Finally it’s time to define how the syncing between local and network homes will behave. This is the real genius behind the Portable Home Directory system, and what distinguishes it from Roaming Profiles.
• First under the Rules tab you have “Login & Logout Sync.” This allows you to set specific items to sync only at login and logout. The suggested defaults for this are mainly your account settings, i.e. your entire ~/Library folder. This is quite sane, and I stuck with this setting.
  

  Login & Logout Rules

• Note the “Merge with user’s settings” checkbox. I initially checked this, but later found it problematic. It was useful on my first sync, but it doesn’t appear to track deletions and such, so I ended up disabling it.
• Also of note is the “Skip items” section. This allows for what rsync users would call exclusions. This also greatly speeds syncing as you can exclude unneeded items such as cache and trash. I stuck with the sane defaults here as well.
• Next up are your Background Sync settings. Again, very sane defaults are provided: We back up your entire home account, periodically, in the background. Skip the usual suspects and don’t merge.
  

  Background Sync Rules

• Finally, under Options, we can set the frequency with which the server will run the background sync.
  

  Background Frequency

• I also set the option to “Show status in menu bar.” This, as you’ll see, becomes quite useful for the way I ultimately ended up using this feature.

Some Disclaimers
Portable Home Directories are actually not specifically intended for the sort of use-case we’re applying them to here. PHDs are actually designed for users with laptops that come and go onto a network that is also populated with stationary workstations. It’s really made to be used in conjunction with network home accounts, allowing laptop users to use network home accounts without being completely tethered to the network.

So to be clear, this is an experiment. I’m doing things a bit outside the norm. (I mean, what fun would it be if I weren’t.) And any problems I had were likely because of this fact. Still, it’s hinted at in the documentation that PHDs can be used for users of non-portable machines to some advantage, so I wanted to see how we could apply them to our (okay, my) particular situation.

I started off a bit outside the realm of the typical first time setup. I had two things at the outset that essentially represented a test of how we might migrate to a PHD-style system: I had a network home account already populated with data, and I had a copy of that data on a local hard drive. This represents our typical user. But I was also hoping that I’d be able to use these to get the Portable Homes process underway more speedily. This was not the case at all.

Initial Experiences
The first thing that happened when I logged into my newly Portable Homes-activated account was that I was greeted with a prompt asking me if I wanted to create a portable home.

Initial Prompt

I chose to do so (“Yes”), since that was pretty much what I was here to do. And upon login I was greeted, not with my previously set up network home account nor my rsynced local account, but rather with the standard boilerplate skel account you see when creating a new user. Worse, the server seemed to get confused as to where my home account should be placed on the local drive. Though I had defined it on my server as a custom path, it seemed to want to go in a folder called “User” on the specified drive, no matter what I entered for the custom path. Apparently, for me anyway, the custom path — and my hopes of speeding the sync process — just plain old didn’t work.

Default Login Environment: Not What I was Hoping For

After this I decided to try again. I moved my custom folder off the local drive and, in Mobility Preferences, simply defined the drive I wanted to use for my Portable Home. I also chose to “Merge with user’s settings” for this go ’round under the Rules section of the Mobility prefs. The thought was that this should pull down my network home account and create a local version from it. And this is exactly what happened. And for a time life was good and I thought I was done. I thought I’d found my magic settings. But the next day I logged in to find that once again my account had reverted back to the default, first-login settings. Yikes!

Portable Homes Weirdness

(Here I’d just like to point out the benefits of having a backup of your entire home account if you’re going to play around with this. Or just use a spare, dummy account. I actually did lose data numerous times during my testing, as you’ll see in Part 2.)

After poking around a bit I discovered that my machine had logged me into my network home. Or at least that’s where the Finder went when I hit Command-Shift-H. But my home account settings were the defaults, not my network home account settings. WTF? Logging out and logging back in I found myself in what I considered to be the right local location, and all my custom settings had returned. But this was clearly getting weird and flaky. And no matter how I configured things, the weirdness persisted. The biggest problem, though, was the fact that my local and network home accounts never synced in the background. And that was sort of the most important part.

Manual Sync
For a time I used Portable Home Directories the only way I could get it to work for me. Remember that tickbox to “Show status in menu bar?” Well, it turns out that you can use this menubar widget to manually sync your local and network home accounts. And manual syncing actually worked okay for me. In fact, it was the only way I could get my network and local data in sync.

Menubar Icon

During this time I pretty much using the default Mobility settings, but my account was on my Work drive. Portable Homes had placed it at:
/Volumes/Work/systemsboy.xahomes
for some strange reason, but I could live with that. Every so often — particularly if I thought I might be going to another machine and logging in as myself — I’d hit “Sync Home Now” in the Menubar pulldown.

Sync Home Now

This would begin the Home Sync process. The process is far from immediate, but it’s not too slow. It takes a few minutes. Once it’s done I can verify that my network and local homes are synced up.

Home Sync Status

Conflicts that the service couldn’t resolve were handled similarly to iPhone-to-AddressBook conflicts, though, with the usual PHD flakiness: often conflicts occurred where they shouldn’t have.

PHD Conflict Resolution

But the biggest problem with Manual Sync was that logging in to another computer failed. A popup alert appeared telling me I was unable to log in at this time because “an error occurred.” Great.

I was really hoping for this to be seamless, of course. But it just may not be possible with this particular setup. The best I can get out of Portable Homes so far is not much better than a glorified rsync script with a pretty GUI for running it and some semblance of conflict resolution. And it completely breaks my ability to log into other computers.

Conclusion (For Now)
In the end I decided that my troubles were likely due to the fact that I was not working in the typical Mac OS X idiom. It’s my guess that Portable Homes failed for me in this instance mainly because my network home account is on a completely different, non-Apple server, one that my Mac Server is not set up to share as a network home location. I would venture that if you set Portable Homes up just like it says in the manual, using Apple kit and AFP and the like (possibly AFP reshares would work), Portable Homes works like a charm. But if you don’t you’ll get some strangeness like I did. Ah, the joys of the bleeding edge!

On my first shot at Portable Homes I experienced a number of surprises and inconsistencies. While Portable Homes is a great idea, and in theory looks to be perfect for someone like me, there are major pitfalls in a complex, multi-platform environment that prevent it from being usable for much of anything. But Portable Homes has potential and I plan to delve more into how to get it working for us in our complex environment. In our next installment I’ll be trying a setup more closely aligned with the Apple-sanctioned method for implementing PHDs. We’ll see how it goes.

1. Activate the service in Server Admin.
   

   Activate Software Update Service

2. Configure the service. I like to configure the SU Server to “Automatically copy all new updates from Apple.” This is the easiest, and I like things easy. But otherwise I use the default settings.
   

   Configure General Options

3. Start the service and list the updates. And here’s one of the gotchas: when you first start the service there is no indication that anything is happening. There is no progress bar and nothing will appear in the list of updates. But in fact the SU Server is downloading all the updates (several Gigs) in the background. The easiest way to prove that this is actually happening is to run the df command, then run it again. You should see your root drive getting gradually fuller as the server downloads the updates. This first download will take a long time. I like to let it go overnight.
   

   Updates

4. When you return the next morning, the list should be populated with all the available updates, as seen above. (Also, you see about 10-15 GBs of data in the Software Update Server’s data store, which is here: /usr/share/swupd/html/content/downloads/.) The last step then — and the thing I often forget — is to tell your client Macs where to get their Software Updates. To do this you’ll need a computer list in Workgroup Manager. Add any computers you want to use your SU Server to the list. Then go to the Preferences pane for the group and select Software Update. Set the URL for the SU Server to: http://server.domain.com:8088/index.sucatalog
   

   Create Computer Group

5. After saving that configuration, logging out and logging back in should be all you need to do on your clients to pick up the server. After doing so, run Software Update and you’ll see the name of your SU Server in the menubar of the interface. This confirms you’re successfully getting updates from the server.
   

   It Works!

Congrats! You’re not a total moron. Enjoy!

UPDATE:
Reader Dennis points out in the comments that individual clients can be configured to look to the SUServer for updates without being part of a WGM group or managed by the server at all. This is done by modifying a preference on the client system, which you would do thusly:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "http://systemsboy.su.server.com:8088/"

That command can, of course, be sent en masses using Apple Remote Desktop’s “Send Unix Command” directive.

And, if you want to revert to the standard method of checking for updates, looking at Apple’s servers, delete the “CatalogURL” entry in the preference file by running:

sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

Thanks for the tip, Dennis!