Resize Macintosh Partitions

In the past, changing the size of a Macintosh volume has been a significant undertaking, requiring third-party tools, offline reformatting, or both. This tended to complicate storage management, and made it difficult to handle unexpected demand.

Fortunately, all that changes in Leopard. In the newest version of OS X, you can grow or shrink any HFS+ partition, whether it's a local hard drive or a mounted network array. The resizing is done live, while the disk is online, and can even be performed on a mounted boot volume (though you'd want a good backup before trying it).

Open Disk Utility and select the storage device you're resizing in the left column, clicking the "Partition" button on the pane to the right. What you'll get is a graphical representation of the entire storage space, with the portion currently being used in purple and the available space left on that partition in white.

To grow a volume to fill the whole disk or array, grab the diagonal markings on the active partition and pull down until it reaches the size you need. To shrink a volume to repurpose unused space, simply drag upward on the same boundary. If you need to add or subtract empty partitions, you can do so with the "plus" and "minus" buttons. Once you've made your adjustments, just click "Apply" and your Macintosh partitions can finally be resized instantly.

Recommended Reading: Back when it was an undocumented feature available only on the command line, Kirk McElhearn wrote about how to resize partitions on the fly with OS X 10.4.6 (and a whole lot of luck) for MacWorld magazine.

Don’t Install Office 2008 (Yet)

The most frustrating part of IT work is that you can't fix every problem you find. That's certainly the case with the retail version of Office 2008 that shipped last Tuesday. The installer is fraught with serious permissions issues, and currently the best solution is to wait for a fix from Microsoft before deployment.

The good news is, the Office 2008 installer utilizes Apple's .pkg format, allowing for customization and deployment through Remote Desktop. The bad news is that the packages carry the wrong UID for installation, the UNIX identifier that determines ownership of files. In this case, that UID is 502, a user that may or may not be an administrator in business environments and likely doesn't exist on single-user systems. This presents a significant management issue, allowing an unprivileged account to accidentally delete Office 2008 on multi-user systems.

Worse still, the Office 2008 files are all set as executable, meaning that they can be run as scripts. This isn't just the applications, but the support files as well, such as templates, graphics, and documentation. The combination of these two errors could allow a malicious user to get around existing security policies.

There's no guarantee that the same issues will be present in the corporate edition of Office shipping February 1st, and it's more than likely that Microsoft will release a new installer or an update that remedies the problems. So if at all possible, the best approach is not to install the newest version of Office until these issues are resolved.

Update: On January 25th, Microsoft published some of these details in their "Office For Mac" weblog. On March 14th, they followed suit with the Office 2008 12.0.1 Update, addressing this and other bugs in the initial release.

Recommended Reading: This issue was first confirmed by Joel Bruner in his blog posts "Office 2008, 502, and you" and "Office 2008 for the executive", and publicized by John Gruber at Daring Fireball. The Microsoft Business Unit published its response in their blog entry "Security issue in Mac Office 2008 Installer".

Mail Won’t Search Messages

You're looking for an email you sent months ago. You're not sure which member of your team it went to, and you can't remember the subject line you used. You know what it was about, though, so you type that in Mail's "Search" field. When the results appear, however, the option to search through each "Entire Message" is suddenly grayed out and unavailable.

Leopard brought a number of improvements to Apple's Mail, such as integrated to-do lists, RSS feed subscriptions, and Address Book data detection. It also added the ability to perform system-wide email searches with Spotlight, the OS X file indexing engine. While this feature has proven to be the most powerful, it's also been the most troublesome, as issues that would previously effect only Spotlight can now disable the ability to search the content of email messages.

When Spotlight attempts to scan a corrupt file, it can stall or crash, failing to properly index your disks and (as a result) your Mail archives. To figure out what Spotlight's choking on, you'll first need it to stop indexing entirely. Make sure you've quit out of Mail, the open the Terminal and type:

sudo mdutil -i off /Volumes/*

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 Mail woes. Make sure these 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 remove your existing Spotlight indexes and restart the process. On the command line, substitute the name of each of your mounted volumes for DISKNAME, and type:

sudo rm -r /Volumes/DISKNAME/.Spotlight-V100
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 Mail, and the ability to search entire messages should be restored.

Firefox Can’t Reach The Internet

With great standards-compliance and cross-platform support, Firefox is becoming the browser of choice not just for end-users but for internet and intranet developers as well. Once it's deployed on corporate networks, however, the Macintosh edition often can't see past the firewall.

Firefox may be an excellent internet citizen, it turns out, but it doesn't follow Macintosh standards too closely. Among the conventions it ignores are the Proxy settings in the Network pane of System Preferences. Instead, Firefox keeps it's own proxy settings hidden, three levels down in its own preferences and uncearly labeled. This is the most common reason Firefox can't seem to load web sites when Safari can.

To solve the problem, go to the Firefox menu and select "Preferences...", choosing the "Advanced" button at the top of the resulting window. Then from the row of tabs, select "Network" and click "Settings..." to bring up the proxy configuration panel. From there it's easy to fill in your proxy addresses, and your Firefox users will be back online.

Office Won’t Save To Server

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:

There has been a network or file permission error.
Save not completed. File rename failed.

No matter what you do, you can't seem to get Word or Excel to save to your network shares. You've gone over the machines repeatedly, and everything is set up properly. Worse still, the problem's intermittent. Your users swear it happens when they're busiest, but sometimes it doesn't happen for days.

There is an explanation. What they're suffering from is an unfortunate side-effect of how Microsoft Office handles temporary files, and the more users that are on the server at one time the more likely this is to bring work to a screaming halt.

Why Office for Macintosh breaks some offices:

Most modern applications utilize temporary files, to guard against data loss or free up working memory. Traditionally, Unix operating systems have saved these files in /tmp (though Mac OS X utilizes /private/tmp), and have included random numbers in their names to prevent accidental duplication. Adobe Creative Suite uses a similar method, saving temporary files in the same directory as the open file being edited, but again using a pseudo-random string like ~file~ve_kv.idlk.

Microsoft Office, on the other hand, saves temporary files at the root of the server volume you're working on, in a folder named .TemporaryItems/folders.UID (where UID is the user's account number on their local client machine). This is client-side behavior on the application's part, and can happen when saving to AFP (Macintosh) or SMB (Windows) volumes.

The problem is that users often all have the same UID on their client machine, because Macintosh computers in an unmanaged environment assign a default UID of 501 to the first account created. That means every Microsoft Office user is trying to read and write to the same temporary folder. That works fine until the original user logs out of their system, at which point they automatically and unintentionally delete that folder, and the remaining users can no longer save their documents to that volume. The problem exists in Office 2004 and the newer 2008.

There are two approaches to eliminate this problem, one utilizing directory services on the server side, the other using the Terminal on each individual client machine.

Office for Macintosh in enterprise settings:

In a server setting, Apple expects user accounts to utilize a directory service like Microsoft's Active Directory or their own Open Directory system. Most Mac users expect that they can set up their office machines in the same easy way they've set up their home machines for years. It's these conflicting expectations, wrapped up in Microsoft's predictable file-naming scheme, that create this problem Office users have been left trying to work around for years.

The best solution is to leverage Open Directory on your OS X server and migrate your client machines to a unified, managed login scheme. This not only solves this Office problem but brings a wide range of additional features with it. It's the management structure that allows control of System Preferences and Software Updates for every Macintosh in the organization, enables a company-wide address book for contact management and collaboration, and provides the highest level of security for network resources. In this situation, each user has a unique account not just on their own machine but across the entire network, sidestepping the Office UID conflict entirely.

In environments without a Macintosh server the same principle still applies. Open Directory can integrate seamlessly into an Active Directory domain, allowing Windows administrators a greater level of management control through group policy setup. Instead of using local accounts on each client machine, you can also avoid potential UID conflicts by binding the Macintosh clients to the AD domain and having users log in with their Active Directory domain accounts.

Changing individual UIDs manually:

If you're not quite ready to take that leap, it's relatively simple to change the UIDs on each client machine to match those on the server. It can also potentially destroy a system, so you'll want a recent backup handy and some comfort with the Unix command line. Remember that you'll need to perform these steps for every user on every machine that accesses your server.

Log in as a local administrative user (and not the user whose UID you're changing), and from the Terminal type:

id -u USERNAME

Here USERNAME is the short name of the user to whom you're assigning a new account number. This will give you their current UID. To change that UID on Mac OS X 10.4 type:

sudo niutil -createprop . /users/USERNAME uid NEWUID

On version 10.5, niutil has been deprecated, and instead you'll need to input:

sudo dscl . -change /users/USERNAME UniqueID OLDUID NEWUID

Above, OLDUID is the current account number that the previous command provided, most likely 501 or 502. NEWUID is the new and unique account number you're assigning. Finally, type:

sudo find / -user OLDUID -exec chown NEWUID {} \;

This last command will locate and assign ownership of all the user's files to their new account number. It can take quite a while, depending on how much data belongs to each user. If you use external hard disks or USB drives you'll have to repeat this step for them as well, replacing / with /Volumes/DEVICE (where DEVICE is the name of the external volume).

Once you're done, your users will finally be able to save Office documents dependably.