An uninterruptible power supply is the only way to make sure your servers receive clean, sufficient, and consistent power. You'd never set up a rack without one, but protecting a new XServe is often overlooked when it's added later on. In the past, configuring a UPS for Macintosh required tedious fiddling with dubious third-party software. Now the functionality is built directly into the operating system, and the most challenging part of the process is finding exactly where Apple put the controls.
In the System Preferences, behind the insufficiently named Energy Saver pane, lies an innocuous pull-down menu. Select "UPS" from the available choices, and a bevy of previously concealed settings appear for communicating with an uninterruptible power supply. At the top is the current battery charge, along the model information for the attached device. Below that, you can choose to configure three shutdown options based on minutes you've been on battery power, minutes left on battery power, or the percentage of charge left in the battery (generally the most accurate of the three).
These options only become visible when your Macintosh is connected directly to a compatible UPS via USB, meaning they can be near-impossible to find. It also means that organizations with network-based power management may require a more complex integration solution that utilizes existing ethernet controls. Unless that describes your environment, APC offers a wide range of models which can accommodate Macintosh workstations and servers automatically through USB and still provide protection for the occasional XServe RAID via serial cable as well.
Posted on 25 July 2007 by Ellis Jordan Bojar
Disk mirroring, where data is written to two disks simultaneously, is a great low cost method to protect against single-disk failure and improve read-intensive performance. Apple's Disk Utility provides an easy way to set two disks up as a RAID mirror at installation, but once the operating system has been installed OS X Tiger can't mirror an existing drive without reformatting and reinstalling. Fortunately, the command line offers an easy method to build a mirrored RAID array from an existing volume.
Like most command line operations run as an administrator, this process has the potential to destroy all the data on your machine, so make a backup of the drive you're going to mirror and confirm the backup is both restorable and bootable. Next, if you're mirroring your existing startup disk, you'll need to boot off an installation DVD or external drive. When you're ready to proceed, type the following into the Terminal:
diskutil list
This will produce a listing of the attached disks, along with their types, names, sizes, and identifiers, like so:
/dev/disk1
#: type name size identifier
0: Apple_partition_scheme *465.8 GB disk1
1: Apple_partition_map 31.5 KB disk1s1
2: Apple_HFS Server Disk 465.6 GB disk1s2
Use the name of the volume you wish to mirror to find it's identifier. If your machine only has one internal hard drive, for instance, the identifier of your boot volume will most likely be disk1s2, the second slice (after the partition scheme and map) of disk 1. Once you've determined which disk you're working with, type the following, replacing IDENTIFIER appropriately:
sudo diskutil enableRAID mirror IDENTIFIER
If all goes well, the disk will unmount, reappearing in the Finder a moment later along with "The disk has been converted into a RAID" reported in the Terminal. At this point you can add the additional disk you wish to use in the mirrored RAID array (taking care that it's the same size as the original), then reboot the machine off the original drive.
Now when when you run diskutil list from the Terminal you should see two new listings, one for the new virtual RAID array (the one without slice information) and the other for the additional physical disk you installed.
/dev/disk2
#: type name size identifier
0: Apple_HFS Server Disk *465.6 GB disk2
/dev/disk3
#: type name size identifier
0: GUID_partition_scheme *465.6 GB disk3
1: EFI 200.0 MB disk3s1
2: Apple_HFS New Disk 465.4 GB disk3s2
Now with the necessary identifier information, you can assign the physical disk to the mirrored RAID array, replacing RAIDARRAY with the RAID volume (in our example disk2) and NEWDISK with the hard drive being added (here disk3):
sudo diskutil repairMirror RAIDARRAY NEWDISK &
How long the RAID mirror takes to build depends on how much data is on the original volume, but the ampersand at the end of the command tells it to run in the background. When the process is completed you'll have two fully mirrored and redundant disks, built from your existing installation without ever having to erase the original volume.
Posted on 18 July 2007 by Ellis Jordan Bojar
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.
Posted on 11 July 2007 by Ellis Jordan Bojar
