Scripts Provided as an EXAMPLE only

Be sure to carefully read/review/modify these scripts as necessary for your situation

What these scripts were used Originally used for

ZCS 6.0.4NE - ZCS 6.0.7NE Migration from one provider to another
A global admin account WAS available for the remote server (old provider)
The (new server) was provisioned and 100% under our control.
This *should* work for just about any zimbra version, from one server to another (between seperate LDAP's)
none of this is necessary if you can do a NE backup and restore.. but if you are (say) moving from a dedicated Zimbra server in someone's office, to a NE cluster (with other domains on it) you couldn't do that, or if you are moving a domain from a cluster with others, to a dedicated server... these scripts might help (although, if you control both LDAP servers 100%, you may be able to use other scripts to also export and import the user passwords through raw ldap, to reduce customer impact)

Scripts/Files used

00_README.txt

These scripts assume you have a global admin on the remote server (at least I did for this example)
They *may* work for a single domain with a domain admin, or at least some of them will
If/when I have to do a migration with only a domain admin privlidge, I will adjust the scripts appropriately to solve the issue, and update this page (or feel free to add some comments to this page)
**Your mileage may vary, use at your own risk
**these scripts are provided for concept, and may need to be customized for your particular situation
It is NOT recommended to use /tmp as your migration folder
Be sure your migration folder is properly secured, and owned by zimbra.zimbra, scripts are chmod 700 to zimbra so they can be executed.

config.sh

#!/bin/bash
oldhost="youroldhostnameorIPhere"
oldadmin="globaladminaccount@oldhost.com"
oldadminpass="globaladminpassword"
newTmpPass="123DomainTemporary@pass321"
migrationfolder=/tmp
newcosID="60668d2f-5200-5c56-828a-201378e53a90" ## THIS IS THE GUID OF YOUR NEW COS TO PUT USERS IN

Process / What to do

Planning

Ensured I was able to get all the data I would need for the migration (Ran 01_getolddetails.sh)

Pre-Setup

Once the local Zimbra was installed, I manually created the LDAP, security, settings, and COS/domains that I wanted

Then I ran the 02_MakeMigrationScripts.sh and got my setup scripts read

Run the appropriate scripts (zmprov.*) scripts, I ran them in this order

zmprov.createusers

zmprov.createaliases

zmprov.createcalres

zmprov.createdistlists

zmprov.createdistlistaliasesonly

zmprov.createsigs

zmprov.recreatesievescript (I actually re-ran this at the end too, so it would hopefully link up to the right folders, after they exist- i.e. post import)

zmprov.zzz_forcepasswordchange is optional, if you were not provided passwords, however, it is highly suggested - it sets all accounts to be forced to change password on first login

Post-Setup testing

yes, you should test for mail flow, firewall access, etc, to be sure the server works, setup antispam, etc, etc.. once everything looks good, you should be ready.

Prep for Go-Live

Make sure you control DNS for this domain

Change TTL to say 5 minutes, to prepare for this migration

Be sure all users know when it is going to happen, and that right after it happens, they will NOT see any of their old data in their accounts immediately, but that it will slowly start re-appearing after a few hours. New email will not get lost.

Migration Day

At the point of "go-live", change the MX records, give it about 10 mins to ensure new mail is flowing to new server

Then Start running the migrationscripts/* scripts using screen (see link to screen page at end) (you can probably run a number of them at one time, depending on the size of the source mailboxes. Restoring will take 3x longer than downloading, so calculate entire time appropriately. (obviously, run the getdata_** scripts, before the restorelocally_** scripts.. I ran the getdata_** scripts in seperate screens, then as each one finished, I started the restorelocally_** script for that "batch" and recorded the times as I went, so I knew my entire process timeframe.

Watch the process.

watch the logs the entire time too for errors

Process

In a nutshell, you just change the MX records, after they have moved, start migrating old data, and start watching logs for anything odd.. after migration, take a long nap.

Don't Forget

More Info may be coming...
The "$migrationfolder" obviously will get big, as it has a copy of everyone's old mailbox, so just keep it around as long as you need it.
Or: delete the "migrationmailboxes" subfolder to save space (wait at least a day or two if possible), and keep the rest of the data for a few weeks (or longer), in case some detail was missed, and you need to see how it was on the old server in the config files that were saved.

Things that do not migrate (or do not migrate well or automatically anyway)

User Grants (folders that were shared with other users)

locked accounts (you have to run a script to unlock them remotely, then migrate, then re-local locally, if you need them - see script generated named zmprov.movelockedaccounts

Not 100% sure if calendar resources are going to properly be connected, I have not had a scenario where I could test this.. yet

ZCO users will NEED to uninstall and re-install, due to the internal configurations of the ZDB

Global Signatures

Custom (or additional) zimlets

Domain customizations (we downloaded all configs, so if we missed something we could easily find it in the configs)

Conclusion

Not much to say here.. Good luck!
I hope they help others
Created and run originally by user:Richardteachout