Available since version 10.4, Portable Home Directories have become one of the most elegant and well-implemented features of a full Mac OS X Server deployment. Functioning much like Windows' roaming profiles (or earlier Solaris NFS/NIS environments), they allow a user to log in from any computer on your network while retaining their personal data and settings. Unlike entirely network-based systems, however, they do so by synchronizing user data to the server (so that a full copy of the home directory exists in both locations), eliminating the need for constant connectivity.
Portable Home Directories make for simpler backup of user data, both by copying off the server rather than each client machine, and by allowing remote users to synchronize via VPN. They also free users from being tied to a single machine, allowing for greater flexibility and less service down-time. It's because this functionality is so powerful that it's often assumed to be difficult to put into practice. Instead, with the proper infrastructure already in place, deploying Portable Home Directories is practically the reward for having done everything else right.
Planning For Portable Home Directories:
Before you actually implement any kind of server-based account storage, you'll want to make sure you have sufficient storage and bandwidth on an available OS X server. This may seem obvious to some, but for reasonable performance, fifty users with a 40GB quota requires at least 2TB of relatively high-speed (and hopefully redundant) disk attached to a gigabit network switch. This isn't an exotic setup by any means, but it may be more than you just have lying around.
You'll also need clients bound to a functioning Open Directory environment, complete with internal DNS. If you don't yet have this set up, refer to our earlier series on how to master Open Directory. Once Directory Service users and groups are in place, Portable Home Directories are nothing more than cleverly deployed managed account preferences. There's a lot to keep track of, but very little you wouldn't already know how to do.
Configuring Portable Home Directory Preferences:
In Workgroup Manager, browse to the "LDAPv3" directory (as opposed to the local user directory), then choose the multi-headed "Groups" button on the left and the "Preferences" icon from the toolbar. Select the group (or groups) you're offering Portable Home Directories, then click the "Mobility" icon in the center of the window to configure that group's settings. If you're deploying this feature to all your users, you're better off creating an all-encompassing "Employees" group to do so.
Beginning in the "Account Creation" tab with the "Creation" pane, choose to manage these Preferences "Always", the check "Create mobile account when user logs in to network account". Uncheck the box which requires confirmation, as this allows the user to skip the Portable Home Directory set up for their individual account. Below that, choose to "Create home" directories "with default sync settings".
Next comes the Account Expiry tab, new to 10.5. By allowing you to set a time limit after which the client-side copy of a home directory expires, it helps clean up the occasional "orphaned" set of user data (a full home directory left, for instance, on a machine only used once by that user during maintenance on their own machine. This feature can reduce the chance of accidentally filling client machines with multiple unused accounts, but does so at the risk of letting the computer determine when data should be disposed of. If you enable it, do so with caution.
Finally, the "Rules" tab lets you set what data will synchronize and when. Start with the "Login & Logout Sync" pane and once again click the button to "Always" manage, then check the box to "Sync at login and logout". The first list above allows you to set which directories you'll sync, and unless you feel you can fully predict your users' behavior the best approach is usually to select the entire home directory (as represented by the tilde symbol). You can then choose what not to sync in the second list below, including full paths, partial names, and even regular expressions. Be careful if you delete any of Apple's pre-configured items to skip, especially ~/Library/Application Support/SyncServices, which can result in synchronization issues and potentially data loss. The "Merge with user's settings" box allows you to decide if individuals can add or subtract to the list of data being synchronized.
The Background Sync pane, functions identically, and in most cases makes sense to configure identically as well. The only exceptions would be huge local files which change often, or live databases which won't sync properly. The Entourage database, for instance, sits both criteria and should be excluded from background synchronization. The "Options" pane also allows you to choose how often background sync takes place. With your configuration decided, click the "Apply Now" button to save your settings.
Next week, in part two, we'll set up the AFP share where your new Portable Home Directories reside and configure your Open Directory accounts to store user data there.
Recommended Reading: While I might not recommend implementing it in a production environment, Greg Neagle's multi-part article on Portable Home Directory Without Open Directory provides fantastic under-the-hood information on exactly how Portable Home Directories function at his "Managing OS X" blog.
Posted on 25 June 2008 by Ellis Jordan Bojar
Despite Apple's encouragement to install OS upgrades as soon as they're released, most systems administrators test updates for a couple of weeks to see if any obvious or significant issues occur in their environment. It's been two weeks since Apple released Leopard 10.5.3, and while the update fixes a laundry list of problems (including Active Directory, AFP, iCal, Time Machine, and SMB issues), it breaks one simple feature that most Mac users simply can't live without: With 10.5.3 on client or server machine, some Adobe CS3 applications (primarily Photoshop, but occasionally InDesign) can no longer save to network shares.
It's hard to tell who to blame for this disaster, if blame is important to you. The fact that saving documents to the server worked just fine in 10.5.2 (and that multiple sources have reported that the functionality returns in 10.5.4) makes Apple look like the bad guy. On the other hand, Adobe has very publicly resisted modernizing portions of its underlying application code, and their antiquated position of not officially supporting direct server usage is bewildering to anyone computing in the 21st century.
The obvious solution is to avoid installing 10.5.3 at all (or roll back to 10.5.2 if you've kept a Time Machine backup of your system volume) until the problem is solved. The immediate (and far-less obvious answer) is to always use the "Save As" option, which continues to work perfectly on servers of all types.
Update: On June 30th, Apple released their 10.5.4 update. Among it's improvements, they list "Resolves an issue with saving and reopening Adobe Creative Suite 3 files on a remote server".
Recommended Reading: The normally-reasonable John Nack (Senior Product Manager, Adobe Photoshop) first reported issues saving CS3 files to 10.5.3 servers in his otherwise entertaining blog. For those with strong stomachs, some very angry commentary can be found on Apple's own discussion boards.
Posted on 18 June 2008 by Ellis Jordan Bojar
After Monday's Exchange-laden WWDC Keynote, it would be hard for even the most jaded critic to claim Apple isn't taking the enterprise market seriously. With all the excitement over the new Exchange-loving iPhone, though, there hasn't been a lot of fanfare over Apple's other big announcement June 9th. Shipping next year, "Snow Leopard" has been announced as the next generation version of OS X. With a press release that plays up performance and quality "rather than focusing on new features", it's easy to overlook just how many new features are really being promised, and how many of them are aimed squarely at large business.
The marquee item for most Mac users in enterprise is that Snow Leopard will feature "out-of-the-box" support for Exchange 2007 for it's Mail, iCal, and Address Book applications. It isn't a big surprise, given Exchange support on the iPhone, but this is a dream come true for anyone who's spent the last seven years battling Microsoft's Entourage. And while that's the only significant new functionality promised for the client version of the OS, it's the single feature that could very well drive the bulk of upgrades. Also included is Safari 4, with it's turbo-charged Javascript engine and the ability to cache and run web applications offline.
On the server side, Apple has announced a bevy of significant improvements. The second version of iCal Server will offer multi-user group calendars, as well as better invitation compatibility for Outlook users (a huge oversight in the original Leopard version). As a companion product, Address Book Server is a WebDAV-based system for vCard exchange, replacing Leopard's half-baked Directory application. Snow Leopard's Mail Server will feature server-side email rules and vacation messages, and combined with the announced "Apple Push Notification Service" for iPhone, OS X Server should finally provide unix-based push email. These features in combination could make the dream of a fully OS X-based communications infrastructure for Macintosh and Windows a reality.
The OS also includes long-awaited read and write support for Sun's ZFS file system (allowing for storage pooling, dynamic volume expansion, and "shadow copy"-style snapshots) and a 64-bit kernel allowing for massive amounts of memory addressing (16TB) and the ability to handle huge numbers of simultaneous network connections.
Taken individually, none of these improvements is earth-shattering, but each and every one is a solid step forward in areas critical to enterprise adoption. Right now the details are thin, and they're far from final, but Snow Leopard's focus and features make it alluring to anyone administering Mac OS X in a business environment.
Recommended Reading: For (very little) more official information on Snow Leopard, see Apple's client and server product pages. For more speculation, rumor, and innuendo, turn instead to TUAW (who proudly first broke the Snow Leopard story).
Posted on 11 June 2008 by Ellis Jordan Bojar
One of Leopard's less beloved security features is the warning that appears when users first open downloaded applications. Given that most software now comes from the internet, this dialog has become a common part of the average Mac user experience. In some cases, though, that one-time process never ends, displaying the same dialog at every launch. The problem is especially common when applications are installed (but not run) by an administrative user.
"Example" is an application which was downloaded from the Internet.
Are you sure you want to open it?
The warning is triggered by an "extended attribute", an addition to the HFS+ file system that allows additional information on a file-by-file basis. In this case, a tag named "com.apple.quarantine" is added to any file downloaded on Leopard by an internet application. If that signature is added by an administrative user, it can't be removed using a standard account.
The solution is to remove that attribute through the Terminal, replacing FILENAME with the actual application name and typing:
sudo xattr -d com.apple.quarantine "FILENAME"
The command can be run on individual machines or, if you've already deployed a tagged application in a system image, it can be run via Apple Remote Desktop. This will remove the quarantine attribute and put an end to the constant nagging.
Recommended Reading: The new xattr command doesn't even have a manpage yet, but what little documentation exists can be found by typing "xattr -h". An enthusiastic explanation of extended attributes in OS X ran back in John Siracusa's exhaustive review of Tiger at Ars Technica.
Posted on 4 June 2008 by Ellis Jordan Bojar
