With many people looking at their bottom lines this year looking to trim the fat from their budgets, it should come as no surprise that many eyes are on .Mac, a nominally good service without significant applications for many Mac users. The problem is that it’s more expensive than many of its counterparts in the webhosting space, and that’s something that’s been discussed here in the past.

What about using the WebDAV capabilities in Tiger Server, to broadcast your calendar?

Now, this makes a few assumptions: You have a Tiger Server handy or know a kind sysadmin who wouldn’t mind prodding around under the hood. You understand some of the basics of WebDAV and calendaring. I realize this solution isn’t for everyone, but every small business that’s trying to do calendaring well ought to use this free alternative to expensive syncing services to make their own calendars. Here’s how…

There are a few things that you have to do on the server side before we even get started and most of those take place in Workgroup Manager and Server Admin. First you need to setup a section of your server for doing this sort of stuff. If you want to do this on your main site, you can, but I would recommend a subdomain specifically for your calendar files. It’s easy enough to set this up in the OS X Server Admin’s section for Web Services and DNS. Add an A Record in your DNS for the new subdomain, and then add the new site in the Web Services. Set up the Web folder to reflect your new calendaring folder.

Now for the important stuff: WebDAV. WebDAV is Web-based Distributed Authoring and Versioning, which means “I serve documents over port 80, allow the emplacement of documents over port 80 and are generally a pain in the rear when things get fairly complicated or broken.” WebDAV requires that you have a Realm, which is a group of users who can use this specific folder to Do Stuff. Creating a Realm is fairly simple, you need to give it a Name, an authentication scheme and a folder to protect. In this case, our Realm is Calendars, our authentication is Basic (because we don’t have Kerberos running), and the Folder is the root folder of the domain that I’m interested in protecting.

Once you have a Realm created, you need to decide who can do stuff to things in the realm. This is like setting the locks on the door. Some realms require no locks, others need a few padlocks once in a while and keys distributed to your best friends. That’s just how things go from time to time, you get to decide who sees your stuff. Generally, though, I don’t want that viewable by everyone, so I turned off access for Everyone, and limited it down to a specific subgroup of users that I created in Workgroup Manager.

Now it’s time to do the cool stuff with PHP iCalendar. Download the zip file and drop the uncompressed folder into the domain’s root directory. This sets up all the PHP scripts that will generate your web view of the calendar. Rename your PHP iCalendar folder to a shorter, easier to type name like “phpical” or “calendar” or something that doesn’t need dashes or dots in the middle of the filename. It’s a URL you’re going to have to give out, or use yourself, so make it easy on yourself. Inside your phpical folder there’s a folder marked calendars, which is where your calendar is going to go, which takes us to the matter of syncing your calendar.

Pick a calendar and Publish it, but instead of sending it to .Mac, pick Private and then fill out the form like so:

Calendar Syncing

Once your calendar is published, you’ll end up with something like this:

Dialog

That’s your new subscription URL good for all your calendar subscribers who might’ve used .Mac before.

Now, to view your calendars, or to subscribe to them, your clients are going to need an account and membership in the group that you set up. Your calendar is now secure behind a password, and if you’re paranoid, SSL and Kerberos can make that absolutely secure for you. It’s all built into the services that you’ve already enabled.

Is this a full replacement for .Mac? No, this is just a calendaring replacement, designed to help you around one major hurdle. There’s more to explore here, and I think this community will have much more to say in the future about the subject. Your $100 for an annual .Mac subscription, along with ten of your friends buys you a Mac Mini and a copy of OS X Server. Pooling resources will allow you to easily replace one service with a service that you own and control, and isn’t that always worth some peace of mind?