There are three basic methods in use today for hosting home accounts on networks in such a way that users have a single home account that follows them from computer to computer, giving them the same environment no matter where they log in. None of these three strategies works in a way that reflects how most people in the lab I currently work in — nor many of the labs I've freelanced for — use their computers and access their data. So I'd like to propose a third strategy that does.
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.
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?