In many ways, OS X 10.5.7 is a huge improvement for Leopard users, enhancing Finder network reliability, iCal server interaction, and portable home directory performance. In a managed Open Directory environment, however, it may also have the unfortunate side effect of locking you out of your legacy PowerPC machines.

OS X Server offers an extremely simple system to manage account preferences, at least those user preferences predefined by Apple. Systems administrators, however, typically find themselves needing to control application settings that haven’t been singled out in Workgroup Manager.

Aside from the files an OS X Server shares across your entire enterprise, there’s often the desire within individual workgroups to have private storage areas for their own projects. These group folders are essential for departments like HR and Accounting, but they can also be helpful for less security-conscious groups as a staging area before sharing their final work company-wide. Fortunately, while the process of creating these file shares isn’t obvious, it also isn’t complicated.

Last week, in part one of this series, we took began deploying Portable Home Directories, reviewing their prerequisites and enabling the mobile managed preferences. This week we’ll continue the process, by setting up an AFP share to host our user homes and configuring our Open Directory accounts to take advantage of them.

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.

The Kerberos authentication protocol is an encrypted ticketing system at the heart of Apple’s Open Directory. It is the basis for Mac OS X’s “Single Sign On” features, and a required component for integration with Windows Active Directory domains. Unfortunately, it’s possible for the Kerberos service to stop functioning properly, and when it dies, a good number of your network services die with it.

One of the long-standing complaints from IT departments about Mac OS X is the lack of a granular administration system. Users are either administrators or they aren’t; It’s a simple and appealing set up for home studios, but a serious problem for companies laboring under HIPAA and Sarbanes-Oxley regulation. In our earlier series on how to master Open Directory, we deployed centrally managed network accounts for Macintosh. Administrators who need finer control of the user environment can build on that deployment to manage account preferences.

Last week in part one of this article, we explored the basics of getting Open Directory up and running on your OS X Server. This week, we’ll set security policy to restrict access to your network services, then create or migrate user accounts to the LDAP directory for distribution and set up your workstations to use them.

It can control your company’s user accounts, their password policies and preferences. It allows access to home directories from anywhere on the network, and mirror that data safely to your server. It forms the basis for features like shared calendaring and contacts, single sign-on to computing resources, and enterprise-level security for all your network services. In the past, Open Directory may have been Apple’s best-kept secret, but it’s now the essential element of business-class Macintosh deployment.

The Art Department is cranking out proposals. Marketing is knee deep in spreadsheets. Everybody’s working furiously, when suddenly the panicked phone calls start. The Macintosh users can’t save their Office documents, and these cryptic messages appear when they try: