Clean install OSX+S 10.9 then migrate data from 10.6 Server?

The task ahead of you is a potentially daunting one. From your message, you listed the following active services:

Mail

Wiki

Home Folders

File Services

Web

DNS

Open Directory

I am a strong supporter of the "nuke and pave" option. However, you are running a number of on demand services that will be missed during an upgrade/migration (read Mail and home folders). I would recommend the purchase or use of a spare device to test the migration before you actually do it. This way, you can continue to run your production device while you build the new system in parallel. Move over one service at a time. This way, you produce as little impact to the environment as possible. Use DNS to assist you and limit client side modification.

Perform a backup before you start! This is often overlooked. Don't skip that part. Repeat the backup before each major step. This allows you to fallback should something fail.

Also, when you are about to do mail, shut down your firewall rules. Block external access to the mail server. Trust me, the last thing you want to sort out is the mail that was delivered during an attempted upgrade that failed, forcing your to revert to a backup. Messy. Some messages in an updated mail store, but not in the backup. Yuck.

Migrating Wiki data. Read this http://support.apple.com/kb/HT5585 I've done enough of these to know that it usually works. However, there are a few areas of concern. The first is GUID values. If you have users in 10.6.8, they all have GUIDs based on when the account was created. If you rebuild a new system and create all accounts from scratch, you will have new GUIDs. These will not match up to the GUIDs recorded in the wiki data. I've manually modified small wikis and I've used sed to find old GUIDs and replace them with new ones on the raw export data. This is definitely doable but there are some areas that may bite. Oh, and if you have attachments, you may need to edit the page and then save the page (without doing any actual change) and then the attachment will work again.

As for users, you can use Workgroup Manager to export users and groups. This will give you standard record format files containing GUID values. You might be able to import this cleanly. However, you will not have passwords so they will need to be reset. I've had mixed results when importing accounts with GUID values. Mavericks has been better but I still get nervous.

Best recommendation is to find about $1200 USD and buy a new server. Then slowly moved one service at a time. If this is not possible, then find a spare device, clone your server to it, and then attempt the update on the clone. See what breaks and what works. These methods ensure that you do not rush into an upgrade on the production system without planning and testing. Trust, but verify.

R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Service" :: Exclusively available in the Apple iBooks Store

I'm not a fan of upgrades either... pave and nuke (nice term Strontium90) is the way to go.

This is a but oversimplified.. I'm not laying out all the steps..

Old server

- clone the original system to an external

- take that external to another computer and do all of the upgrades

- archive OD

- along the way, I would make clones of the system so you can roll-back if (for example) the 10.7 to 10.8 upgrade fails.

On the new server, do a clean 10.9 install.

- Install server app

- import OD

- setup services from scratch

again.. way oversimplified and this path may not be best for you...

Good job on performing the first round on the clone! See, now you can start over without blowing up a production system.

So, general order of upgrade would be:

1: Clone your drive back to the test machine

2: Boot back into 10.6.x in isolation confirming that services work on the clone

-- this may require tweaking DNS to ensure that the server is happy with its identity

-- tweak DNS on the clone, not production

-- what do I mean by this? The production server is server.ashley.com at address 10.0.0.2. When you clone, the clone will be server.ashley.com at address 10.0.0.2. If you boot it on the same network, you will have an IP conflict. So, you must change the IP of the clone. But you also must update the DNS record on the clone to match the IP address change. On a production system upgrade, you would not need to do this. But say you move the clone to 10.0.0.4. Edit DNS BEFORE upgrading to reflect the server.ashley.com is at address 10.0.0.4 on the cloned box. Since the cloned box is likely hitting itself first for dns, then it will be happy with the reply.

3: Shut off all services other than DNS and Open Directory

4: Install Maverics (client OS)

5: On reboot, login as local admin and run all software updates

6: On next reboot, purchase/download Server.app 3.x for Mavericks

7: Run Server.app and allow it to perform the upgrade.

8: Test and fix what breaks.

Hello,

We're attempting to do a similar upgrade. We have a Mac Pro that currently has a HDD running OS X Server 10.6.8 with the following services running: AFP, Mail, Open Directory, SMB, Software Update, and Web. We have installed a SSD with OS X 10.9.1 Server and would like to migrate the current network users, mail, and network accessible and shared data from the old HDD to the new SSD. We're looking at a good guide and/or suggestions for this process.

Out of your services (AFP/SMB, Mail, OD, SWU, and web), the one with the most potential for disaster and headache is clearly mail. If you are using the same host device, cutting services over in pieces will not be possible. However, here are some suggestions and potential points of concern.

AFP/SMB file services are cake. The only thing you need to consider is the potential time to copy the data if you are moving it to new disks. The other issue will be user's GUID values and the associated ACLs. Let's take the following scenario based on what you've detailed.

• You have data on /HDD/Shares/ and you are planning on moving them to the SSD. Is the SSD drive large enough to accept this data?

• If you had a share /HDD/Shares/Data and this contained an ACL allowing the design group to have access, the design group from the 10.6.8 OD may have a different GUID than the one you create on the 10.9.1 system. If this is the case, you can purge all ACLs with a sudo chmod -R -N /path/to/data. (Server.app should remove and then add but older versions resulted in merged messes so I go nuclear on the old settings) Then you can apply your new ACLs and allow the permissions to propagate.

• If you are leaving the data were it is, you will simply need to reset permissions. However, note that if you are exporting and then importing users (via an OD backup or via standard record format) then you are maintaining GUID and should not need to touch any permissions.

Regarding SWU, I would suggest looking into Caching server. If you are moving the entire environment to 10.9 and iOS 7, SWU is no longer needed. Caching server is easy as pie, requires no client configuration, and is more economical on your internet connection and server storage requirements.

Web is pretty easy also. But, this is dependant on what you are doing with web. If html/php/perl then you pretty much just move your site folders and you are up and running. If you were using MySQL, note that Apple replaced it with Postgres. You can either perform a conversion from MySQL to Postgres or you can just install MySQL again manually. The choice is yours. If you are not doing database backed sites, the migration should be cake.

OD is one of those technologies that I always prefer to start clean. In really large environments, this can be very tough due to passwords. You can export an OD backup from 10.6 and attempt a restore in 10.9.1. If you have a lot of MCX in 10.6.8, you may run into some trouble as Apple has deprecated MCX in 10.8 and above. However, this ensures that you have everything, from password to GUID. Test, test, and test some more if you go this route. An alternate option, especially if you are embracing the move away from MCX and to Profiles, is to do a user and group export for 10.6's Workgroup Manager. This will not provide passwords but it will provide editable text files of your account data. You can strip out the MXC and other legacy values and then use the resulting file to import users into a clean 10.9.1 OD master. Once again, you will not get passwords unless you add them to the import file. You need to figure out how many accounts and how sensitive users are to password resets.

The final piece is mail. This is the one area I have very little experience. I've been burned by Apple's mails solutions from way back in the AppleShare IP days and now make it policy to use anything else but Apple's mail solution. In a perfect world, moving the mail data store to the new OS and triggering Server.app should be enough. But Apple + mail never seem to enter the realm of a perfect world.

And finally, make sure DNS is correct before you do anything. Since you are dealing with mail, you should also shut firewall port forwards to prevent new mail from coming into the server while you work on the migration. Nothing worse than stitching mail together after a blown migration attempt.

R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in the Apple iBooks Store

Strontium90,

Thanks for all the great info here!

We're also experiencing that the biggest issues are with migrating the mail. We tested copying the mail store of a service account from 10.6.8 to 10.9.1 and have so far been unable to get that to work. Mail doesn't even seem to recognize the content that was migrated. Persmissions might just be what is giving us grief. Reading I've done suggest that the mail data in 10.9.1 has to be owned by the _dovecot service account, whereas the mail data in 10.6.8 was owned by the user account associated to that mail data.

Most of the other services aren't a huge headache. The shares will be backed up to a 2TB blank drive, so that the current HDD can be wiped and repurposed to a data drive. The SDD wil be used for the OS and apps. The Web is being used for a simple intranet site. We don't anticipate any issues moving that either. OD won't archive. I have attempted to archive the 10.6.8 OD in several locations using several files names. The process appears to complete, but no file is created. I was able to export the WM users and groups, so we'll likely use those to keep GUID and other info the same. We're not overly concerned with password issues. This is a small company (~50) and 90% of the users all have the original password that was setup for them.

Thanks again for your input. If you have any additional insight or suggestions on the mail migration, please let me know!

Regards,

Gerald

Mailboxes are surprisingly easy to retain

From 10.6+, the mailbox format is the same, only the permissions and default location of the mailstore has changed.

Assuming you setup your new server.. put the mailboxes (GUID folders) where they should be and

Change this to your mailstore lcoation

sudo chown -R _dovecot:mail /Library/Server/Mail/Data/mail/

Regarding manually moving the mail data, here's what worked for us on a service account used for testing:

1. Verify the test account has unread and read messages in the Inbox, as well as read messages in Sent and Trash in Mail on OS X Server 10.6.8.
2. Copy the GUID info for the test account from an export of the user account entry in Workgroup Manager.
3. Copy the test account mail data folder from /volume/private/var/spool/imap/dovecot/mail. The folder will have a name that is the test account GUID.
4. Paste the above copy into a folder on the SSD.
5. Restart the server into Mavericks.
6. Create a new local network user account with the same name as the test account.
7. Create a mail account for the newly created user account.
8. Copy the GUID from /volume/library/server/mail/data/mail. There should only be one folder with a GUID as the name. Alternatively, the GUID can be copied from the Directory Manager in the Server App.
9. Delete the mail account and the supporting data in the location mentioned above.
10. Paste the mail data from the 10.6.8 test account mail account to the Mavericks Server mail location mentioned above.
11. Change the folder name to the new GUID.
12. Open terminal and type this command:
13. sudo chown -R _dovecot /Volumes/*SDD name*/Library/Server/Mail/Data/mail/*GUID named folder*
14. Authenticate the command.
15. Verify the permissions of the folder were changed to make _dovecot the owner.
16. Recreate the mail account.

Following these steps, we were able to get the test account created and the mail for the test account showed the items that were verified existant in Mail on 10.6.8.

Regards,

Gerald

HA! You posted that command as I was making my write up.

Thanks UptimeJeff!