Beginning in OS X 10.5 (Leopard), Apple built in the ability to run validity checks on any font file. Those checks can be done when the fonts are loaded into Font Book, but they’re also run beforehand when your disks are indexed by Spotlight. By using mdfind, one of the command line tools that works behind the Spotlight interface, it’s easy to find all the indexed files that may contain bad font data. Open the Terminal and type:

mdfind "com_apple_ats_font_invalid == 1"

This short and simple trick will return a list of all the suspect font files stored on any machine, whether they’re loaded in one of your user’s font folders or just stored on a spare external drive. Push the command out with Apple Remote Desktop, and you’ve got a list of every questionable font on every machine at your whole company. Once you’ve located these potential problems, it should be easy to round them up and remove them before they cause additional frustration.

Leopard brought a number of improvements to Spotlight, the OS X search mechanism, including system-wide integration with the Finder and native applications. This is accomplished with an indexing process, mdworker, that runs in the background at all times organizing file metadata. While this feature has proven to be quite powerful, it’s also proved quite troublesome, as issues that would previously effect only Spotlight can now disable the ability to search the content of email messages and calendars as well.

When Spotlight attempts to scan a corrupt file, it can stall or crash, failing to properly index your disks and (as a result) disabling the search functionality in other Apple applications. To figure out what Spotlight’s choking on, you’ll first need it to stop indexing entirely. Make sure you’ve quit out of all your effected applications, then open the Terminal and type:

sudo mdutil -i off /Volumes/*

Once the Spotlight process is disabled, remove the old index files Spotlight built of your existing file system, replacing DISKNAME for the name of each mounted volume:

sudo rm -r /Volumes/DISKNAME/.Spotlight-V100

Next, open the Console application in the Utilities folder. View “All Messages” in the left hand column, and use the “Filter” field in the top right to search for “mdworker” (the behind-the-scenes process that indexes data for Spotlight). If the remaining errors end in file names, you’ve found a likely source for your Spotlight woes.

Make sure these corrupt files are safe to move (and not within Application bundles or required by the OS), then relocate them to a removable drive or erase them entirely. With your suspect files out of the way, you can restart Spotlight indexing:

sudo mdutil -E -i on /Volumes/*

Once the indexing is complete, check the Console logs again to make sure the errors haven’t repeated. You can now reopen your applications, and the ability to search messages and appointments should be restored.

At the root of the problem is the /etc/authorization file, which outlines unique situations where users are granted escalated privileges, and which should be altered as part of the 10.5.7 update process. It appears, however, that the file is updated only on Intel-based machines, leaving managed users on the PPC architecture unable to login on their workstations or laptops.

The solution is to copy the file to a PPC machine booted into target mode from an updated Intel installation, taking care that the ownership and permissions remain the same as on the Intel version. Alternately, if you have multiple PowerPC machines updated and booted, the same idea can be applied en masse by pushing an updated Intel file out via Apple Remote Desktop, JAMF Casper Suite, LANrev, or your preferred third-party distribution tool.

Once the corrected file is in place, reboot the afflicted machines, and login should be restored.

Licensing for this product has stopped working.
You cannot use the product at this time.

There’s a variety of reasons that the CS4 licensing components might give up the ghost, including low system resources, a damaged licensing sub-system, or corruption of the licensing data itself. The message goes on to suggest reinstalling the component in question, but it’s a solution that seldom, if ever, succeeds. Instead, find the error code that the bottom of the window, and take a look at this handy, exhaustive, and embarrassing entry in Adobe’s own Knowledge Base: Error “Licensing for this product has stopped working” when you launch Adobe Creative Suite 4 products.

In that article (far too lengthy to even summarize), Adobe helpfully explains the nine different ways your legally purchased and properly installed Creative Suite products might have licensing failures, and the variety of ways it can be addressed on a machine-by-machine basis. One of these procedures will undoubtedly fix your individual CS4 installation, if not the much larger issue that even corporate editions of Adobe’s flagship product can be hobbled by an overly zealous, overly complicated DRM system.

Special Thanks: My intrepid colleague Jasson Lewellen discovered many of these issues firsthand, as well as a number of their solutions, and pointed me at Adobe’s Knowledge Base documentation of them for this article.

So imagine the surprise when you’ve configured and started the service, but your client machines simply won’t connect. In fact, they complain there’s a username or password error, when the username and password work fine for other services. Check the logs in Server Admin, and all you’ll find is an ominous message:

The selected logfile does not exist.

In some Leopard Server installations, the iCal Server logfiles aren’t ever created properly. The result is that the server process starts, but doesn’t do anything because it has no place to log its actions. It’s the sort of problem you’d usually figure out by digging through log files, but because they don’t exist, iCal Server just sits there dumbly, unable to provide any clues.

The easy way to stop this serpent from eating its own tail is to create and properly permission the files, then restart the iCal service. Open the Terminal, and type:

cd /var/log/caldavd/
sudo touch access.log error.log
sudo chmod 640 access.log
sudo chmod 644 error.log

The touch command creates the required logs, while chmod is used to set their permissions. With the log files now in their expected place, client machines should have no trouble connecting to iCal Server.

There are a variety of reasons your network Time Machine setup might start excluding certain machines. Rather than address them each individually, the following is a general troubleshooting approach for the full gamut of issues. Follow these guidelines, and your Time Machine setup should be working again in no time.

First, turn off Time Machine on the misbehaving client machine. With the large, decorative switch now in the “off” position, remove the preferences file at Library/Preferences/com.apple.TimeMachine.plist. If you’re dealing with a corrupt preference file, that should resolve the issue immediately.

Next, remove the Time Machine “cookie” from your network share. These invisible files are named with a period, followed by the MAC address (also called the ethernet id) of the “Ethernet 1″ interface on each client machine (not necessarily the network interface you’re actually using). If the machine has a primary MAC address of a1:b2:c3:d4:e5:f6, then you’re looking for a file called .a1b2c3d4e5f6 at the root of the share. Get rid of it, and any identification issues with your Time Machine client should disappear.

Finally, you’ll need to reintroduce your client machine to the Time Machine server. In order to access your share every hour, Time Machine stores authentication data in a keychain when it’s first configured. Delete all references to your Time Machine server from the “System” keychain (most simply with Keychain Access in the Utility folder). Once no memory of the name or IP of the server remains, you can reconfigure Time Machine to back up to your server again.

These steps won’t solve every Time Machine server problem, but this quick checklist can often get your users backing up again, and get you back to working on larger problems.

Recommended Reading: For more information about common backup problems, take a look at Apple’s own Knowledge Base on troubleshooting Time Machine issues.

This issue occurs most frequently right after Software Update has run on Leopard. It’s most often caused by a corrupt dynamic loader cache, a feature which replaced “application prebinding” in OS X 10.5 and tells the system where to find available shared libraries. Without a roadmap to these libraries, the computer can’t boot properly.

If the affected system is running 10.5.6, you can remedy this problem by booting with the “Shift” key held, triggering a Safe Boot sequence and deleting the damaged cache files. If you’re running an earlier version of Leopard, Safe Boot won’t remove the caches, so you’ll have to boot the machine from a DVD or external drive and remove the files manually from /var/db/dyld/ instead.

Once the cache files have been removed, the machine should restart normally.

Suddenly, stable installations of Suitcase Fusion wouldn’t launch at all, with no obvious error or explanation as to why. The answer lies inexplicably in Extensis’ handling of a computer’s Bonjour name, the publicly-seen machine name set in the “Sharing” pane of OS X’s System Preferences. If a Bonjour name exceeds 20 characters, or features non-alphanumeric characters, Suitcase Fusion is apparently too distracted to let your users get their work done. Extensis hasn’t provided any public information on why computer names might be an obstacle to font management.

Unless you feel like renaming all your workstations, the sane response is to hold back the 10.5.6 update until Extensis addresses the issue with a Suitcase update or Apple changes something back in 10.5.7. When the situation changes, we’ll update this article with more information.

Update: About a month after 10.5.6 shipped, Extensis followed with Suitcase Fusion 13.0.2, released specifically to solve this issue.

The issues inherit in a Leopard Server upgrade can be addressed quickly and easily if you know what to look for. With a little advance preparation, and this article as a checklist, you can make sure the process is safe and successful for most OS X installations.

You’ll want to have checked in advance that any third-party applications you need run on Leopard, and you’ll definitely need a known-good backup in case something goes awry. Now let’s get started.

Document Server Settings:

The big problem with the Leopard upgrade isn’t that it loses data. In fact, it’s the opposite, with the newly upgraded volume turning on new services, adding duplicate users, or even sharing out random (and sometimes private) directories. The most important part of the process, then, is to document all your Server Admin settings prior to upgrade. You’ll want to have notes (or screenshots) detailing all your DNS zones, web sites, firewall configuration, etc. If your team doesn’t already document all their server settings in a change log, now’s the time to catch up on the paperwork.

Archive Open Directory:

The next step you’ll want to take is to export all your Open Directory settings. This includes not just your users and groups, their passwords, their managed preferences, but also all your Kerberos and Password Server data. After you’ve upgraded your server, you’ll restore this information to insure nothing’s been corrupted in the upgrade process.

You can do this easily by using the “Archive” pane in the “Open Directory” options of Server Admin. Simply click the “Choose…” button to set the location the collected data should be saved to, then click the “Archive…” button to set the name and password for the disk image that’s created. Type very carefully, and since the password isn’t verified before the image is created, test that you can open it before you proceed.

Install Leopard Server:

With your preparations made, you can run the Leopard Server install normally. You’ll be asked to enter your new Leopard serial number, but otherwise the process shouldn’t require any configuration. The upgrade takes about a half hour on the current generation of XServe, and you can fill the time by downloading any recent updates you plan on installing. When your server reboots, it’ll likely have a host of services you don’t want turned on, so it’s best to restart it with the network cable unplugged.

Reconfigure Services:

If all went well (or at least as expected), you should now have a fully functional Leopard Server. Maybe a little too functional, even. Leopard tends to turn on a bunch of undesired services during the upgrade process. Was your XServe an email or NFS server previously? There’s a good chance it might be now.

Open Server Admin, and select the your local machine from the left column. Now take a good, hard look at the services listed below it. Turn off the services you weren’t running prior to upgrade, then check your remaining service settings to make sure nothing unexpected has been added or changed. If you don’t need Apache 1.3, it’s a good time to upgrade to version 2.2 in the Web options as well. Now it’s time to plug back in the network cable and wrap up the job.

Restore Open Directory:

Now that the rest of the damage has been undone, you’ll want to clean up your account information. If your server remained an OD master through this process, you’re in luck. Otherwise, you’ll need to promote it in the “Settings” pane of the Open Directory options, then return to the “Archive” pane.

Choose the archive disk image you made earlier, and click “Restore…” to return your Open Directory domain to it’s pre-upgrade state. Once you’ve confirmed Open Directory accounts work locally, test each of the services you’re offering over the network as well, making sure that everything functions as it did prior to the upgrade process.

And voila! While not exactly fast or automatic, you should now have a newly upgraded and properly functioning Leopard Server. Now you can go find out what’s going to break when you upgrade your client machines…

Recommended Reading: While it may contradict some real-world experience, Apple nonetheless publishes an excellent guide on Upgrading and Migrating 10.5, essential reading for anyone planning a complex upgrade to Leopard Server.

iTunes cannot sync information with the iPhone “3G” because
syncing has been disabled on this computer.

The dialog even offers you the opportunity to enable syncing again, but the option doesn’t actually result in anything. Once this error appears, you can’t synchronize any of the data in the iTunes “Info” tab (including contacts, calendars, bookmarks, and mail accounts), though music, picture, and video syncs work normally. Home users might not notice for months, but if an iPhone is meant for business this issue renders it basically useless.

The problem is corrupt SyncServices data, the system that keeps track of information between Macintosh systems and applications. The solution is to delete the the files in ~/Library/SyncServices and ~/Library/Application Support/SyncServices, log the user out and back in, then reset the sync preferences in iTunes. This forces OS X to rebuild the SyncServices database, resolving the issue.