If you’ve got a box in this not-uncommon state, the important thing to remember is that it isn’t locked up completely. The graphical interface may be frozen, but the Unix subsystem is still running just fine underneath. It’s for times like these that it’s so useful to have SSH (Secure Shell) enabled on client machines, which is done by checking “Remote Login” in the “Sharing” pane of System Preferences.

Faced with a machine that consistently lets users log in, but get no further, the problem is very often a corrupt font cache. This causes the system to have issues rendering type, prevents the menu bar from displaying properly, and therefore stops the login process before the user can take control of their work environment (even after reboot). One way to correct the problem is to type the following from the Terminal of another machine:

ssh USER@MACHINE ‘rm -r /Library/Caches/com.apple.ATS/*’

Replace USER with the name of any administrative user, and MACHINE with the hostname or IP, belonging to the workstation. You’ll be asked for that user’s password, after which the command will remove the Apple Type Server caches from the frozen machine, and with them this issue. You can then safely restart, and login (as well as fonts) should function normally again.

Special Thanks: We were reminded of this problem (and this succinct solution) by Aaron Robinson, systems administrator at Seattle’s fine Hornall Anderson Design Works.

Recommended Reading: For more information on corrupt font caches (and some products to clear them without the command line), you can check out the CreativeTechs QuickTips blog.

It’s easy to only see the security implications and administrative issues in this scenario, but take a step back and you’ll also understand the frustration Macintosh users have on a network designed without their experience in mind.

Binding workstations to Active Directory allows your existing Windows accounts to be used on Mac OS X. It eases maintenance by enabling the use of network administrative accounts, and improves security by allowing you to enforce password policy. Just as importantly, it empowers the people who use your Macintosh systems, by eliminating multiple passwords and allowing interaction directly with the Windows infrastructure.

To begin, check the “Network” pane in System Preferences, and be sure that your Windows domain is listed in the “Search Domains” for each interface. Then open the Directory Utility application in the Utilities folder, click the “Show Advanced Settings” button, and select “Services” from the toolbar that appears above.

Check “Active Directory” from the available list of services, then hit the pencil symbol at the bottom to edit the binding criteria. Leave the directory forest set to “Automatic” and enter the name of your Active Directory domain and the computer name you wish to bind your machine as. Resist the shiny, pulsing “Bind…” button and instead click the “Show Advanced Options” arrow at the very left hand side. The window will expand, revealing the full range of configuration choices.

Beginning with the “User Experience” pane, check “Create mobile account at login”. Without this selected, Mac OS X won’t cache account credentials, leaving users locked out of their machine when the Active Directory server can’t be reached. This would prevent access not only during network failures, but also for any laptop user unable to connect with VPN (like those commuting by train, on airplanes, or in log cabins).

Next you’ll see “Force local home directory” selected automatically. This will store user account data on the individual workstation rather than utilizing the home folder in the user’s Active Directory profile. While it is possible to use a Windows server to store Macintosh home directories, the process can be inconsistent and poorly supported (and can lead to significant confusion if the same account is used for both OS X and Windows). To this end, you’ll want to uncheck “Use UNC path from Active Directory to derive network home location” as well.

Now select the “Administrative” pane, and begin by unchecking “Allow authentication from any domain in the forest” at the bottom of the window. This will force OS X to locate user accounts only within the domain you’ve specified. You can then check “Allow administration by”, allowing (at a minimum) domain and enterprise administrators to also administer the local machine. You can also add groups from your Active Directory set up, or even specific user accounts (as in the example above) who may not normally have administrative rights on Windows systems.

Having configured your options, click “Bind…”, and enter the name and password of a domain administrator when prompted. If there’s a pre-existing local account on the bound machine, you’ll want to log in with the user’s Windows name and password first to dynamically create a new home directory. Then, switch to an administrative account to migrate over the user data from their old home directory in /Users, making sure to match the permissions to the new Active Directory-based account.

When it’s all finished, you’ll now have the kind of account controls you’re so used to on your Windows systems. Happily, your Macintosh users will, too.

Recommended Reading: Active Directory binding is important enough in corporate settings that we’ve written about it twice, once early on for Tiger and again in this updated Leopard version. It’s also important enough that Apple has a resource page dedicated to it, Integrating Mac OS X and Active Directory, at their IT Pro site.

Unix operating systems (including Mac OS X) can only have one “default route” at a time, the path of last resort for data headed outside your local network. Mac OS X uses whatever you’ve configured on “Ethernet 1″ in the “Network” pane of System Preferences as the default route. That’s usually the internal IP on your firewall, proxy server, or router. If you later configure an external IP as “Ethernet 2″, your data won’t be routed properly and the machine won’t respond on the outside interface.

The trick to getting your Mac routing both networks is to set up “Ethernet 1″ as your external (or WAN) interface, using the information provided to you by your internet service provider. Mac OS X will then set the router setting from this connection as the default route for the machine. If, for some reason, you have to use your internal interface as “Ethernet 1″, remove the IP from the “Router” field. This will force the machine to use the router information from “Ethernet 2″ as the default.

Special Thanks: This tip came in a crunch from our colleague Jared Reimer, founder of Cascadeo Corporation, an excellent Seattle-based network consultancy.

First, select a group from your Open Directory domain in the “Accounts” pane of Workgroup Manager. Then click the “Group Folders” button, and select a share point under which you’d like the group folders to appear. By default, Mac OS X uses /Groups, which comes pre-configured as a share on a new installation. Next, you’ll need to choose an owner for your new folder. Your directory administrator account makes the most sense here, as you’ll be using the group (not owner) attribute to determine access permissions. With these options configured, hit “Save”.

For whatever reason, you can’t actually use Workgroup Manager to create the folder you’ve just configured (as you can with user’s home directories). Instead, you’ll need to open the Terminal and type:

sudo CreateGroupFolder

This will build a folder for every group assigned a share point, not just the most recent, so if you’re deploying multiple group folders it makes sense to run this command after they’ve all been set up in Workgroup Manager. This also sets the permissions for each group folder as read-only to the group itself, and only read-write to the individual user defined as it’s owner. To remedy this in the Terminal, type the following, replacing PATH-TO-FOLDER with the full Unix path to each group folder:

cd PATH-TO-FOLDER
sudo chmod 770 Documents/ Library/

This will allow access by workgroups to their own group folders with a simple permissions scheme. For more complex sharing setups, you may wish to add an access control list as well, in the sharing pane of Server Admin.

Finally, if you’re utilizing managed preferences in an Open Directory environment, you can set group folders to automatically mount when a member of that group logs in to their workstation. Moving to the “Preferences” pane of Workgroup Manager, click the “Login” icon, then the Items button on the far right. Check “Mount share point with user’s name and password” and “Add group share point”, then click “Apply Now”.

Not only can each workgroup have their own private file share, but users will connect to those shares automatically when logging in to their Open Directory account.

It’s for these enterprise-wide deployments that Apple provided the iPhone Configuration Utility, an OS X native application to create and distribute settings for corporate iPhones. Install the program on any Macintosh (or use the web-based version for Windows) and you can create .mobileconfig files that set passcode policy, wireless networks, VPN, POP/IMAP or Exchange email, and more.

First, open the iPhone Configuration Utility, select “Configuration Profiles” and click “New” in the toolbar above. Moving through each of the application’s tabs, fill in the appropriate access and account information for your network. Individual account names and passwords need to be input on each device by the user, but security certificates can be pre-loaded by your administration team. You can create as many configurations as are reasonable for your environment, offering different setups for different classes (or departments) of employee.

Once your policy and access information is in place, you can distribute each configuration by clicking “Export” to save the file to disk then upload it to any web server. This method (preferred over email distribution for large deployments and new devices) requires that your web server transmit .mobileconfig files uncompressed and with a MIME type of application/x-apple-aspen-config. Mac OS X Server 10.5.3 and above are pre-configured this way, while Windows users can set this in the server Properties page of IIS Manager. Those running earlier versions of OS X can add this information using the MIME Types pane of the Web settings in Server Admin.

By simply browsing to the appropriate URL, each iPhone will automatically begin the installation. While this process will prompt the user for their domain authentication criteria before configuring the device, it’s still advisable to limit access to the URL by only serving the .mobileconfig file to your intranet. Also, while adding a signed profile in the “General” pane (using a certificate issued by one of Apple’s pre-installed trusted root authorities) isn’t required, it’s simpler to get a new security certificate issued for this purpose than try explaining to users why it’s OK to install an unverified profile that lacks the attractive green “Trusted” icon.

With very little work up-front, this process offers not just a way to minimize initial deployment times company-wide, but also allows a method to distribute network access changes across your entire enterprise down the line.

Recommended Reading: For further information on customizing iPhone configuration, download Apple’s iPhone Enterprise Deployment Guide [PDF - 728KB].

That’s where Suspicious Package comes in, a Quick Look plugin that lets you view exactly what and how will get installed by any package-format installer.

Just select a .pkg file in the Finder, hit the space key, and you’re greeted with an interactive Quick Look window. The folder structure of the installer can be browsed using the unfolding arrows to the left of the file names, and the installation scripts can be read with the expansion button to the left of the script icon. Suspicious Package even lets you know if an installer requires an administrative password to run, or that your machine be restarted after installation.

Designed to do just one thing, and do it very well, Suspicious Package is an incredibly clever (and incredibly useful) little utility. It’s also an enormous time saver, and a fantastic extension of Apple’s Quick Look framework.

Suspicious Package is available for free from Mothers Ruin Software.

The ARP (Address Resolution Protocol) DNS (Domain Name System) caches are very different, but they server very similar purposes. ARP tables hold the information mapping ethernet MAC addresses (0a:1f:b5:c0:8e:4a) to network IPs (192.168.0.75), while DNS servers translate fully qualified domain names (like router.makemacwork.com) into IP addresses. Both types of information are cached to make subsequent lookups faster, but when changes take place on your network it’s hard to predict when that information will get updated.

Fortunately, it’s trivial to flush these caches on the Macintosh command line, and those commands can be sent to hundreds or even thousands of machines at once using Apple Remote Desktop’s “Send Unix Command…” function.

On individual machines, you can clear the ARP cache in the Terminal and typing:

sudo arp -d -a

The DNS cache (along with all Directory Services caches) can be reset by typing:

sudo dscacheutil -flushcache

If you’re sending the commands out with Apple Remote Desktop, leave out sudo and instead be sure to set the “Run command as” user to “root”.

That’s all it takes to force your Macs to fetch new routing and domain information, without ever having to interrupt the people working on them.

Sharing Portable Home Directory Files:

In order to make your server-based home directories available to other machines, you’ll need to share them out to your network (preferably via AFP). In Leopard, the “File Sharing” settings reside in the Server Admin application. Open it, then select your server name, and choose the gear-shaped “Settings” button from the toolbar. You’ll see a collection of potential server features to enable (such as allowing SSH and ARD access) including a listing for “Server Side File Tracking”. Checking the box and clicking “Save” will allow Mac OS X server to cache file changes prior to synchronizing home directories, which offers a significant performance boost over Tiger’s system of scanning and comparing home directory contents.

Next, select “File Sharing” from the Server Admin toolbar (or the equivalent settings in Tiger’s Workgroup Manager). If your server has fast redundant disk space available to hold your portable home directories, there’s not a compelling reason to not just share out /Users. If you have a large number of users (or a small boot disk), you’ll want to create a separate share on external storage. In either case, select the “Volumes” and “Browse” buttons below the toolbar and select the folder you’ll be using for your Portable Home Directories, then click the “Share” button right above the file browser and “Save” at the window’s bottom-right.

Once you share the directory, a new “Share Point” button will appear at the center of the “Sharing” pane. Select it, then check “Enable Automount”. You’ll then be asked to enter an administrative user name and password for your Open Directory domain. Keep the default setting of mounting user home folders over AFP by clicking “OK”, then move on to the “Protocol Options” button below it.

When Portable Home Directory deployments go wrong, it’s usually at this stage. In the AFP “Protocol Options”, be sure that “Allow AFP guest access” is checked (you’ll also want to uncheck the options to share via SMB, FTP, or NFS). If you have other AFP shares active (which you most likely do), be sure guest access is turned off on the rest of them. Then select “AFP” from the service list on the left of the Server Admin window, choose the “Access” pane, and check “Enable Guest access” there as well.

This may seem counterintuitive, as guest (or unauthenticated) access to the home directory share may sound like a terrible idea. In most cases you wouldn’t want any data shared out to network guests, and Apple even forces you to confirm the setting in two separate places. In the case of Portable Home Directories, however, the shared volume gets automounted prior to any user logging in. The data inside each home directory stays private, but the root of the share needs to be accessible to any machine bound to the Open Directory domain. Guest access is the mechanism through which this is achieved, and without it the remainder of your deployment process won’t get anywhere.

Assigning Portable Home Directories To User Accounts:

Now that your mobility preferences are set and your AFP share is set to automount, the final step is assign home directories to your existing users. Open Workgroup Manager and select “Accounts” from the toolbar, then highlight a test user from the left column and choose the “Home” pane. By default, two options are offered as home directory locations, /Users and None. Instead, click the “plus” button at the bottom of the list to add an additional option.

In the dialog sheet that appears, use the first field to enter the AFP address of the home directory share in URL format (such as afp://server.example.com/Users). In the second field, fill in just the name of the user’s home directory, which should be the same as their account “short name”. In the third field, enter the full path of the automounted home share as it will appear on client machines. This begins with /Network/Servers/, then the address from the first field minus the afp:// prefix, and finally the user’s short name. When all three fields are filled properly, click “OK”, then assign the user a disk quota (somewhere between 20-40GB is reasonable for most user environments) and hit “Save”.

With this first account done, you can now highlight all the users who’ll be getting mobile accounts, select your pre-configured share point, assign a quota, and save those settings to the entire list at once. If these are new accounts, you can even use the “Create Home Now” button to populate your AFP share with custom home directories. If you’ll be syncing existing home directories on client machines, you don’t have to create a home folder at all, instead allowing the data to copy to the server on their next network-based login.

Recommended Reading: For the full story on Portable Home Directory setup, try the essential Leopard User Management Guide [PDF - 2.5MB] at Apple.com.

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.

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.