Migrate Snow Leopard Server to Lion or Mountain Lion

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:

  • FTP
  • VPN
  • Web Config
  • Wiki
  • Mail
  • Calendar (also does Address Book/Contacts)

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.

3 comments for “Migrate Snow Leopard Server to Lion or Mountain Lion

  1. Frank B
    June 29, 2013 at 9:20 am

    Were you migrating to a server with the same eventual hostname, or was it a brand new server setup that was running alongside the original server?

    I’d like to do similar, but will be bringing to a server with a different hostname, DNS entry, and SSL cert.

    Any advice is appreciated. This seems to be one of the few indexed searchable articles on the topic.

  2. June 29, 2013 at 10:13 am

    I moved to a new server running alongside the original. Basically the original server (augustine) is running 10.6 and is running ALL our network services (OD, DHCP, Web, iCal, AB, Wiki, etc.). I have started separating those out so that it is easier to perform upgrades.

    iCal, AB and Wiki got pulled off of augustine and put onto a brand new server running a new IP and name (aquinas). I ended up using the same SSL cert because we have a wildcard domain certificate.

    My only advice is do lots of testing. 🙂 I did the migration about 3 or 4 times before I finally found all the right things to do to make it work. After the final migration and going live I found one more issue to deal with (noted in the update). Using the TM backup from the production server allowed me to test without shutting down the old server.

  3. July 8, 2013 at 7:02 pm

    Help me, Daniel! 🙂

    I tried the above approach and while the records seem to be in place, no one can authenticate to caldavd at all. It looks as if Calendar server slipped out of alignment with Apache or something…

    I posted all the detailed on https://discussions.apple.com/thread/5157456

Leave a Reply

Your email address will not be published. Required fields are marked *