Clear System Font Caches

Anyone who supports graphic designers learns to hate fonts. As tiny pieces of software loaded directly into the operating system, they're responsible for more than their fair share of system issues. So it goes with users whose systems freeze up on login, displaying nothing but their desktop background and a lonely spotlight icon in the upper left corner of the screen. The issue is so common, there are a myriad of third-party tools to address it. And like so many common problems, this one comes down to fonts again.

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). The issue is especially common in later versions of Tiger, but it plagues Leopard systems as well. One way to correct the problem is to boot into single-user mode and clear out the system's font caches entirely.

Reboot the machine while holding down the "Command" and "S" keys. If the frozen workstation runs Tiger, type:

rm -r /Library/Caches/com.apple.ATS/*

If the frozen workstation runs Leopard, instead type:

atsutil databases -remove

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 these commands will remove the Apple Type Server caches from the frozen machine, and with them this issue. If you can login as an administrative user, these commands can also be run from the Terminal by preceding them with "sudo". You can then safely restart, and login (as well as fonts) should function normally again.

Special Thanks: We were reminded of this problem (and its Tiger-specific 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.

Bind To Active Directory

When the Macintosh computers on your network don't have a Macintosh server to control them, the result can be chaotic. Some users wind up with multiple passwords to keep track of while others give up by keeping their account passwords blank. Passwords to Windows resources can expire without warning because users have no PC to reset them with, and machines can be reconfigured with passwords that aren't even documented.

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.

Set Default Network Route

Most servers sit behind your company firewall, reachable only through NAT and port forwarding or protected from the outside world entirely. If you've got a machine that needs full access to both the internet and your local network, however, getting both interfaces up and running can seem like a crapshoot. New servers will usually work fine, while those configured on a second network later on will often fail. XServes and Mac Pros come with two ethernet ports, so you'd figure setting them up on two separate networks wouldn't be much of a challenge. And it isn't, if you know the trick.

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.