Migrate Snow Leopard Server to Lion or Mountain Lion

December 28, 2012

I have a Snow Leopard server running, obviously, 10.6.8.  It does too many things.  It serves AFP, OD, iCal, AddressBook, Wiki, RADIUS, Software Updates, and a few other things.  That is just too much stuff on one server that goes down every time I do a little maintenance. What I wanted to do is setup a new Mac Mini server on Mountain Lion and migrate the collaboration services (iCal, AddressBook and Wiki) from the old server to the new one. Easier said than done. It seems all the public documentation is for how to migrate the entire server, not piecemeal.

I did some digging and found some useful scripts in the Server.app.  Fire up Terminal and take a look in the /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras folder. There are various Python, Perl and Ruby scripts to migrate various service information.  A few of the ones you might be interested in:

  1. FTP
  2. VPN
  3. Web Config
  4. Wiki
  5. Mail
  6. Calendar (also does Address Book/Contacts)
  7. RADIUS

I will give an example of what I did. I found simple instructions on Apple’s website for how to migrate the Wiki information from 10.6 to 10.7/10.8. I also needed to migrate the Calendar/Contacts information.  I did this as a dry run to test and make sure these steps would work so I can test the new server and then I will setup the server clean again and do the final process and go live.

First I mounted the time machine volume for the old Snow Leopard server.  From the command line I ran the following:

  • cd /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras
  • sudo ./70_calendarmigrator.py –sourceRoot /Volumes/Time\ Machine\ Backups/Backups.backupdb/augustine/Latest/Augustine\ HD/ –sourceVersion “10.6.8”
  • sudo chmod -R -a# 0 /Library/Server/Calendar\ and\ Contacts/Data

This ran for about 5 minutes before it finished. You should probably make sure your Calendar and Contacts services are not running, I realized Calendar was running half way through and turned it off. Luckily everything still seemed to work. When the process finished it starts up the Calendar and Contacts services. There were a few things more I had to do to get everything working properly. So I will give an overview of the whole process.

  1. Use the 70_calendarmigrator.py script to migrate the settings and data.
  2. Use the Server app to select the appropriate Certificate for the Calendar service (it was set to none which caused proxy errors).
  3. Use the Server app to give users (or groups) permissions to use the Calendar and Contacts services (by default nobody has access even though they already have calendars).
  4. Restart the entire server. Technically you can just restart all the various services, but after a migration like this I would just restart the server to make sure all is well.
  5. Update DNS to point to the new server. (For testing I edited the /etc/hosts file of a client to simulate the DNS update and everything just worked)

Finally, a few caveats I ran into trying to get things to work:

  1. I ran into an issue with an “CalDAVAccountRefreshQueueableOperation error 500” in iCal client and “Data Corruption Detected” in the caldav error.log. Once I checked the error.log I found that there was a Geo-location based reminder on my calendar (actually 4) that was causing issues for some reason. I’m not sure why. I had to use the psql command line tool to log into the PostgreSQL database and delete the offending entries from calendar_object table.
  2. My user works fine in iCal but has an issue in the WebCal interface. I have 2 calendars, but the WebCal interface shows duplicates on the sidebar, though it does not duplicate the actual calendar data. Furthermore, when I try to edit the calendar it says I don’t have permission. This may be related to the issue I ran into above or it may not. Because this was a test server I believe I had already logged into the WebCal client before I imported the data so I may have really fouled things up on my own username. I checked a few other users and none of them have any problems. I was able to delete one of the “ghost” calendars, and I can create events on the real calendar of that pair, but the other 2 calendars (one real, one ghost) neither one shows that I can delete and I’m a little. I tried a full server restart but that did not fix. Again, I think this is just because I used a previously used system before instead of a clean system.

Overall the process was super easy and only took me about 2 hours to figure out and, transfer the data, fix a few issues and be back up on running on the sandbox server. The key to the whole process was finding those migration scripts so I could migrate individual service data.

Update 1/2/2013

Here are some tips for getting things fixed if you run into similar Calendar issues. Just for the record, only my personal user account had issues with the Geo-location TODO items. Other users have Geo-location TODO items and they seem to work fine; what the difference is I don’t know. Anyway some tips on how to get into PostgreSQL to fix this.  First, to actually login to PostgreSQL run this command:

psql -h /Library/Server/PostgreSQL\ For\ Server\ Services/Socket -U _postgres -d caldav

To find the offending records (in my case, they all had the street name of “Jenkins” so I was able to search on that):

select resource_id from calendar_object where icalendar_text like ‘%Jenkins%’;

You should see it spit back a handful of records. If you see a large number of rows returned, you may want to try and fine-tune your query a bit. Once you have the query down, change the “select resource_id” to “delete” like this to delete those same rows:

delete from calendar_object where icalendar_text like ‘%Jenkins%’;

Once this is done I recommend restarting the Calendar service just to be safe.