Configuring Exchange Email in Snow Leopard:

If you’ve only been using Entourage for Exchange integration, there’s a chance your users have never even launched Apple’s native Mail client, and opening the application for the first time will launch Mail’s setup assistant. If you simply need to add an Exchange account to an existing Mail setup, the same assistant can be reached by selecting “Preferences…” from the “Mail” menu and adding a new account in the “Accounts” section.

In the first pane of the assistant you can simply type the user’s name, their email address, and their Exchange password.

In the second pane you’ll have to select “Exchange 2007″, as Snow Leopard connects via the new Exchange Web Services and doesn’t support earlier versions of Exchange Server. You’ll also have to give the configuration a name. If your Exchange server is on the local network and runs the Autodiscover service, Mail should automatically populate the remaining fields. If not, you’ll need to fill in the fully qualified hostname of the Exchange server, the user’s login name, and their password. You’ll also want to check the “Address Book contacts” and “iCal Calendars” boxes, allowing users access to the company’s Global Address List and employee schedules.

The third pane simply confirms the information you’ve already entered before taking the new configuration online. In a perfect world you can click “Create”, and you’re all set.

Troubleshooting Exchange Email in Snow Leopard:

Unfortunately, things don’t always go perfectly. While Snow Leopard does a pretty good job of configuring Exchange accounts on its own, it frequently needs a helping hand from a friendly IT representative.

The most common configuration issue is that Mail tracks both an internal and external Exchange server, but only configures the internal server by default. If your users connect to Exchange over the internet and without VPN, you’ll need to populate that second field. If the hostname of your Exchange server resolves differently internally and externally, you’ll need to configure that as well. These settings are found by selecting “Preferences…” from the “Mail” menu, and navigating to the “Account Information” pane of the “Accounts” section.

Similarly, Mail stores separate EWS paths and ports for the internal and external server addresses in the “Advanced” pane of the same section. Chances are you’ll want the same path and port for both, but Mail will only configure the “Internal” options by default. These two options are obvious once you realize they’re there, but their absence from the initial configuration screens can cause a lot of confusion.

Once you’ve corrected those settings, you should be able to sync a user’s Exchange account with their local machine immediately.

A Complex Explanation of Unix Permissions:

In cross-platform deployments, permissions may most often be Windows-style ACLs (access control lists), allowing a wide variety of context-sensitive settings but requiring a degree of administrative overhead to set up and maintain. On native Mac OS X systems, you’ll most likely be dealing with POSIX-style permissions (also known as Unix permissions) which define file access as granted to the owner, the group, and others. This information is available for every file and folder in the Finder by highlighting an item and choosing “Get Info” in the “File” menu, then selecting “Ownership and Permissions” in the window that appears.

The underlying Unix operating system keeps track of those file permissions as numeric values, where 4 represents read, 2 represents write, and 1 represents execute (which the Finder doesn’t report). These values are additive, so that a file which allows read and write access to it’s owner and read-only access to it’s group and others is denoted as 644, with the 6 being the sum of 4 for read and 2 for write. For a directory these read and write permissions are denoted as 755 (without execute permissions a user is unable to interact with or even list directory contents, so an additional 1 is added to each position). It’s these numeric values that are used by Unix commands like chown and chmod, which change ownership and permissions mode respectively.

When you create a new file the default permissions are defined by a value called the umask. This value is subtracted from 666 for regular files (and 777 for directories) to determine their access privileges. So when creating a new folder, a umask of 022 would yield permissions of 755, allowing the owner to both read and write enclosed files while the group and others are able to read them. Unfortunately, these are the settings used by the Finder in a new OS X installation.

A Simple Way to Improve Finder Security:

By default, the Finder creates folders with permissions that allow read access to anyone who can log in to your machine. This isn’t a problem if users only save files in the pre-existing folders in their home directory (like Documents), as their permissions already prevent access by anyone but the user.

When users create additional directories, however, the documents stored inside them can be accessed by other users on that computer (or in the case of servers and when file-sharing is enabled, by anyone on the network). This is seldom the behavior that users expect, and in many settings it can present a serious security problem.

There are lots of ways to adjust the umask system-wide, depending on the OS version you’re using (such as the GlobalPreferences.plist and the NSUmask property). Unfortunately, setting the umask for the entire system is also a really good way to break things unexpectedly.

The easy way to solve this issue is to adjust the Finder’s umask settings by creating a new preferences file on the command line. So long as the files your applications save are inside folders the Finder created, you’ll have the security you need to prevent casual snooping. While logged in as an administrative user, open the Terminal and type:

defaults write /Library/Preferences/com.apple.finder \
umask -int 077

On their next login, users who create new folders in the Finder will have their permissions set automatically to 700 — allowing them to read and write the contents but preventing access by any other users entirely.

Recommended Reading: Is there anything that Wikipedia can’t explain? I’m not sure, but for more information on this topic, take a look at their excellent file system permissions entry.

Like a stripped-down version of Server Admin, you configure the servers you’d like to monitor and switch between them. For each machine, you can observer the processor, network, and disk activity, as well as monitoring the individual services you’re running. Server Admin Remote also allows you to read your server’s log files, and connect via the command line for quick administrative tasks (if you’ve already got an SSH client on your iPhone). All you need is access to each machine via either VPN or forwarding of port 311, and a quick check of an important system is just a single touch away from anywhere.

Server Admin Remote isn’t perfect. The interface can be disorganized, unintuitive, and even buggy in places. Once you’ve learned its idiosyncrasies, though, there’s no better way to keep an eye on your servers during your commute, in meetings, or even just on an extra-long lunch break. It’s a solid application that can reduce your response times and increase your piece of mind.

Server Admin Remote sells for $7.99 retail via iTunes.

While these restrictions can be determined on a user-by-user basis, this approach can quickly become hard to manage. The more scalable option is to utilize groups, either from existing directory services or created specifically for this purpose on the local machine.

With your access model planned, open Server Admin as an administrative user and highlight your server name in the left column. Then choose the Access button from the strip along the top right, and you’ll see a list of the services available to regulate.

Simply uncheck “Use same access for all services” then choose a service on the left, adding users and groups to the list on the right with the plus button. When you’ve configured the services to your satisfaction, hit “Save” to enforce your policy.

The procedure is deceptively straightforward. Login Window can easily be configured to lock all users out of the machine, for instance, so it’s best to have a strategy for each service individually.

There’s also one service Server Admin doesn’t control access to at all. Just like individual client machines, the ability to remotely control your server is regulated in the System Preferences under the Sharing pane. Select “Apple Remote Desktop” from the list presented, then click “Access Privileges…” for the full complement of options.

With this approach, you can get some granular control over which services are available to which individuals, improving your security while diminishing your workload.

In a stock Mac OS X installation, the first account created during the installation process always has administrative privileges. That first account is also always assigned the UniqueID (the number by which the operating system identifies users) of 501. Since there’s a built-in preference setting that will hide accounts with a UID below 500, changing that number with the dscl command is a good place to start.

It’s advisable to do this from the root account (where you won’t need to use sudo for the following commands), or from another administrative account created for this purpose. Open the Terminal, and type:

sudo dscl . -change /Users/ADMIN UniqueID 501 NEWUID

Change ADMIN to the name of your actual administrative user, and NEWUID to the new UniqueID number you’d like to use. While many numbers below 500 are used by the operating system, 490-499 are left unused by default.

Because we’ve changed the UID, which is used to determine ownership of files, we’ll need to make sure that any files owned by that user (especially their home directory) have their ownership changed to the new UID as well. This can be accomplished by searching for those files with the Unix find command, then changing their ownership with chown to the new UID:

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

With file ownership now matching the new administrative UID, the last task is to tell the system not to display the administrative user at login or in the Fast User Switching menu. This is accomplished by editing the LoginWindow preferences file, by typing:

sudo defaults write /Library/Preferences/com.apple.loginwindow \
Hide500Users -bool TRUE

With this command, the initial administrative account will be hidden entirely, but it’s home directory will still be visible in the /Users directory. This is fine for most environments, but if you want that home directory hidden, you can move it to a hidden location and tell the OS to look there with the dscl command.

OS X keeps the root home directory in the hidden /var directory. That’s unusual for Unix, but it sets a precedent you might as well follow. To hide your administrative account’s home directory in the same manner, move it by typing:

sudo mv /Users/ADMIN /var/ADMIN

With the directory now hidden from the Finder, set its new location with:

sudo dscl . -change /Users/ADMIN NFSHomeDirectory \
/Users/ADMIN /var/ADMIN

In both these cases, change ADMIN to the name of your actual administrative user account. With this method, your administrative account should be entirely hidden from view, allowing you to keep both it’s name and it’s existence a secret from typical users.

Now this process has the potential to destroy all the data on your machine, so make sure you have a current backup of the drive you’re going to mirror and confirm the backup is both restorable and bootable. Also, if you’re mirroring your existing startup disk, you’ll need to boot off an installation DVD or external drive for the first part of the operation. But if you have a system disk that isn’t already mirrored, this procedure can save you a lot of time and frustration.

First, from the Terminal, type:

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 insert the additional disk you wish to use in the mirrored RAID array (assuming it’s not installed already), 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 addToRAID member NEWDISK RAIDARRAY &

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.

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.

Listening For Syslog Data:

Like all Unix systems, Mac OS X logs it’s system activity through syslogd, the system logging daemon. This facility keeps track of all the system activity specified in /etc/syslog.conf, which details the kind of information to log (based on its process of origin) and its level of priority (set by its parent process). This system is well documented by simply typing “man syslog” at the command line. What isn’t so easy to find is how to configure OS X clients to send this data to a central collection server for analysis.

The secret is hidden in /System/Library/LaunchDaemons/com.apple.syslogd.plist. The last item in the file is a key named NetworkListener, and by removing the comment characters around it you can tell your Mac server to listen for any and all logging information sent to it via UDP port 514. Once that’s done, you’ll need to restart the syslog mechanism by opening the Terminal and typing:

sudo launchctl unload \
/System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load \
/System/Library/LaunchDaemons/com.apple.syslogd.plist

With syslogd restarted, your server can now receive and store remote logging data from Macintosh clients, networking devices, and other Unix-compatible systems.

Sending Remote Syslog Data:

Now you’ve got a brand new syslog server. It’s listening, but nothing’s talking to it yet. For that, we’ll need to edit /etc/syslog.conf on your client machines, telling them what (and where) to report.

Open the file in any text editor, and you’ll see the following format on the very first line:

auth.info;authpriv.*;remoteauth.crit /var/log/secure.log

On the left side are a series of “selectors”, each separated by a semi-colon. Each selector is made up of a “facility” (before the period), which indicates the category being logged to, and a “level” (after the period), which indicates the level of importance that a message from that category needs to reach before it’s logged. An asterisk acts as a wildcard, including any possible facility or level.

On the right side is an “action”, preformed when syslogd receives a message matching the specified selector. This is most often expressed as a local log file, but can also be another machine listening for syslog data.

So if you wanted to log every possible message to the syslog server, you could simply add the following line (replacing server.example.com with the name of your local server):

*.* @server.example.com

That would send all that messages from any facility at any level of priority to your new syslog server. That configuration’s fine for testing a single machine, but unless your goal is to completely flood your local network with logging traffic, you’ll need to narrow down your selectors significantly before you push your revised file out to all your client machines.

Once you determine what information is important to your organization, you can build a custom syslog.conf file to install across your whole network, and begin collecting system log information for all your machines.

Recommended Reading: For in-depth information on configuring remote logging, check the manpages for syslogd, syslog, syslog.conf, and logger.

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.