With Mac OS X Server 10.5 and below, Software Update Server only had one catalog of updates -- thus, you could run a command like this one, and have it point Software Update to your server:

defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "http://Server.local:8088/"

With Mac OS X Server 10.6, Apple has divided the catalog file into three separate catalogs: one for 10.4, one for 10.5, and one for 10.6. Each is a separate URL, and if you set the wrong catalog for the OS, you'll get the (incorrect) message that your software is already up-to-date. Having three separate scripts is a hassle, though, and is prone to error.

On the Hints Forums, users tw and Hal Itosis were instrumental in crafting this AppleScript. It checks the OS that you're currently running, and sets the appropriate Software Update Server URL. Change Server.local to your server's address.

I had the need to update a server that was acting as a Software Update Server. I knew that the machine had the update on it, but was unsure of how to get it to see the locally-hosted update. If you open Terminal and issue this command...

open /usr/share/swupd/html/index.sucatalog

...then Software Update will launch, looking at the localhost -- no need to re-download the update from Apple.

Snow Leopard's iCal Server changed the location of the Wiki-based calendars, so that this previous hint no longer works. Intead of using the path of /principals/groups/groupname, the URL for wiki-based calendars has changed to one of the following:

https://ical.domain.com:8443/principals/wikis/groupname/
http://ical.domain.com:8008/principals/wikis/groupname/

When you add this in as a URL for an additional account, you can then access this shared calendar, with your changes reflected on the wiki page. You could alternatively create a specific user in workgroup manager to be used as the 'silent' owner of a group calendar, create your calendars, assign delegation to all the real users. But if done in that way, you don't get to see the calendar in the wiki, online.

Hopefully Apple develops the web-based version further, and allows you to show calendars you have delegate access to in your 'My Page,' in additional to your personal server-based calendars (nice that that is there now, though!).

Mac OS X lacks a good command line tool for following a Services Access Control List (SACL) tree of users and groups. If you don't want to, or just can't, use the GUI to list users in service ACLs of your Mac OS X server (or managed client), you need to parse the groups/nested groups/users tree one group at a time, using dscl. It's really painful. As an alternative, I've created a script to handle this for sys admins.

I won't promise you a killer command line tool with foolproof error and recursion handling, but I still believe I've designed a usable piece of shell script -- even if it looks like it's the worst code I've ever written (which is not true; I've made things way uglier). The source code is too long and messy to be just copy-pasted here; just download the getsacls.sh script (4KB) directly from my machine.

How to install getsacls.sh:
Simply copy it to your Mac OS X 10.5 server (or managed client); anywhere in your $PATH should be fine. Then chmod +x the script, so that it can be executed.

How to configure getsacls.sh:
Defaults values should be OK, but if you really want to change something, open the script in your favorite editor, and find the FEW USER TUNABLE MISCS section. Edit at your own risks.

I have recently discovered a solution to a long-time annoyance of mine with 10.5 server and managed preferences for 10.5/10.4 clients: How to force the Applications and Downloads folders into the Dock.

I 'took apart' and examined the com.apple.dock.plist file and found the options for the Applications folder and the Downloads folders. If you simply place these folders into the Workgroup Manager (WGM) area for dock preferences, you end up with a broken downloads folder and an Applications folder that won't show its contents. Instead, when you click on Applications in 10.5, you just get a new window instead of the list of its contents.

The secret is to take a com.apple.dock.plist file and take out everything but the entries for Applications and Downloads. Use this file in the Details tab of preferences plists that you can force out -- don't forget to make it 'always' for enforcement. After that, go back to the Dock preference area in WGM and finish your settings, including the Documents folder and any apps you want to see on the dock.

[robg adds: I haven't tested this one.]

This is more observational than hint-like, but it's interesting. This morning we had a customer order a new 2009 Mac mini, and they asked to have it upgraded to Leopard Server.

When we put the DVD into the Mac mini slot, we were getting ready to boot from DVD to do the upgrade. However, with this new mini, it no longer requires a reboot. You can install the Leopard Server Install Package without booting from the DVD.

I am jumping on board the DeployStudio train, and with multiple sites to support, I ran into the issue of how to use one master Deploy Studio server, but host the images at each of the sites (especially the WAN locations).

The solution I came up with was simple. When Deploy Studio wants to mount the images volume (via AFP), I just have a preflight script that mounts the volume based on which location (based on subnet) the computer is being imaged at. For instance, our Deploy Studio is on our fiber network, but our satellite site is on cable. When the computer netboots and DeployStudio Runtime is launched, it connects up to the Deploy Studio server (again, hosted on the fiber network).

A preflight script will mount the correct AFP mount prior to imaging the computer. We are basing this on our subnets, but your mileage may vary. Hope this helps those other network administrators going through the same struggles. I have other thoughts on using one image name (with multiple images), but I'll save that for another hint.

To the best I'm able to determine, Mac OS X Server's cron does not recognize crontabs of users who exist in LDAP, nor the flat files (e.g., /etc/passwd). This is because cron starts prior to LDAP, and thus sees the crontabs of such users as "orphans." If you log in and re-establish the crontab, all is well ... but a simple reboot shouldn't cause crontabs to become disabled.

The system cron is a launchd service, and so it's quite difficult to control the order in which it launches. One can make the argument that it's cron's fault that it doesn't check for LDAP when it starts, but I think that the blame is really Apple's to bear. I spent hours today trying to figure out a graceful way to delay cron's launch without installing a new cron or hacking things up too badly, all in vain.

I gave up and just installed the hackery below; the script waits for LDAP to respond, then kills cron, which automatically restarts.

I am a system administrator on a small network of five servers with around 80 to 90 clients. Recently I wanted to image a group of 25 MacBooks to get them ready for staff to use. Searching the web, I found a lot of information about using SIU (System Image Utility). Based on my searching and my experiences, I'd like to offer up this "How to use SIU" how-to. Please note that this process is best done when the load on the server (from the users) is at it lowest. If done when you have users accessing the server, you will have complaints about things going slowly.

I recently had an instance in which a client company was insisting that all email communications between our servers being encrypted with TLS. We're using Leopard Server 10.5.5 (which includes Postfix 4.3.1), but it took some extra tweaking to make it work, so I thought I'd pass it on in case anyone else here ever needs it.

This hint assumes that you have a Leopard Server running Mail Service which needs to be able to receive email from servers out on the Internet, and a security certificate for your mail server. (In Server Admin GUI for Mail Service, that would translate to having SSL set to Use (not Require) for SMTP with the correct certificate selected.) You will need a certificate for this to work, and preferably one issued by a certificate authority.

When we're done, you'll be using Opportunistic TLS (offers TLS but doesn't require it, since most ISP email servers don't use it) for the internet at large and Mandatory TLS just for your specified host(s). Launch Terminal and here we go...