- 1 Migration Issues
- 1.1 Actual Migration Notes Homepage
- 1.2 Server Migrations
- 1.2.1 RFE/Bug's For Migration Tools
- 1.2.2 Staged Migration of Non-Zimbra or ZCS Server to New ZCS Server
- 1.2.3 Staged Migration Of Complete Zimbra Server To New Zimbra Server
- 1.2.4 Staged Migration of Zimbra Server Domains To Zimbra Server With Existing Domains
- 220.127.116.11 One Possibility Untested or QA'd - NOT FINISHED - DON'T USE
- 18.104.22.168 Second Possibility Untested or QA'd - NOT FINISHED - DON'T USE
- 22.214.171.124.1 Situation
- 126.96.36.199.2 Split-Domain Setup
- 188.8.131.52.3 Break Up User Migration
- 184.108.40.206.4 Set Accounts To Maintenance
- 220.127.116.11.5 Backup
- 18.104.22.168.6 Problem With Backup
- 22.214.171.124.7 Set Company Domain Onto Hosting Server
- 126.96.36.199.8 Restore Account Onto Hosting Server
- 188.8.131.52.9 Move Restored Accounts Into Split-Domain
- 184.108.40.206.10 Forward Accounts That Were Moved
- 220.127.116.11 Third Possibility Untested or QA'd - NOT FINISHED - DON'T USE
- 1.3 Some Zimbra Users From DomainA to DomainB On Same Zimbra Server
Actual Migration Notes Homepage
Please see Ajcody-Migration-Notes
Staged means that the migration will take place in steps over time where users mailboxes will be moved to a different server. This process might involve a Split-Domain configuration or the use of LDAP replica's that would intergrate a new ZCS mailstore.
RFE/Bug's For Migration Tools
I'll try to keep track of items here when I find them.
- Migration Tool zimbra to zimbra
Staged Migration of Non-Zimbra or ZCS Server to New ZCS Server
Review the following articles:
- Split Domains
- Most likely will need the Split DNS information as well
- You might want to review the following if you have an Exchange server and MS DNS servers
- Things you might need to deviate from the Split Domain instructions
- Specifically "Domain Masquerading"
- MS Exchange instructions about mail-relaying
- Other MS Exchange information that might prove useful:
- "Managing Accepted Domains"
- "How to Create Accepted Domains"
- "How to Configure Exchange 2007 to Route Messages for a Shared Address Space"
- This FAQ page is devoted to Mailflow/Transport-configuration related questions
Staged Migration Of Complete Zimbra Server To New Zimbra Server
If your moving users to a new mailstore, please see King0770-Notes#Preferred_Method_Moving_Users_To_New_Machine for a possible solution. This process implements a new LDAP replica's with the new ZCS mailstore. Over time you migrate the account to new ZCS with zmmailboxmove. Once the accounts have all been moved, you prompt the LDAP Replica configuration on the new ZCS server to be the LDAP master. Adjust for the MTA configuration and then retire the old box.
The rsync method, described in Ajcody-Notes#Server_Move_To_Same_Platform_64bit_And_OS_Type_Version would require downtime.
Staged Migration of Zimbra Server Domains To Zimbra Server With Existing Domains
One Possibility Untested or QA'd - NOT FINISHED - DON'T USE
The process would involve migrating the LDAP data for the domain from the old zimbra server into the other existing Zimbra system (using slapcat or ldapsearch). You'll need to get the server entries, any customer COS entries, the domain entry, and all users under that domain. You would then load the information (ldif) into the existing Zimbra server with slapadd. You could then reconfigured the old server to become an ldap slave to the existing Zimbra box and to server simply as a mailstore for that domain data (users). One could also proceed with zmmailboxmove if you needed to migrate the user data onto the other box as well now.
Adjustments would also need to be done in regards to auth keys and server certs.
Second Possibility Untested or QA'd - NOT FINISHED - DON'T USE
Let's say you own a hosting company and a new customer says they are running Zimbra Network edition (same version as yours) and wants you to host them. They only have one domain and want to minimize downtime. Their server is in another country or state. They have 50 users.
Realistically, during the migration time frame, those accounts that will be using the temporary sub-domain until the switch is complete should only use the zimbra web client. Phones, thick clients, and so forth will introduce issues about synchronization and so forth that would be better to simply avoid.
Setup a split domain that you can use through the migration time frame.
They are company.com
You'll be migrate.company.com
See Ajcody-Notes#Staged_Migration_of_Non-Zimbra_or_ZCS_Server_to_New_ZCS_Server about Split-Domains and Domain Masquerading. Other adjustments might need to be applied.
The situation will be this:
- All emails maintain their company.com domain and email comes and goes through customers ZCS server.
- Customers ZCS will be using forward/alias for account to goto @migrate.company.com
- User Forward/Alias
- Need to figure out the right way to do this for this situation still.
- Relaying/Domain Forwarding
- md example.com zimbraMailCatchAllAddress @migrate.company.com
- md example.com zimbraMailCatchAllForwardingAddress @migrate.company.com
- md example.com zimbraMailTransport smtp:mta.HOSTING-COMPANY.com
- User Forward/Alias
- Accounts migrated to Hosting company server will have rewrite rules. So migrated accounts will not be exposed to "outside" world.
- zmprov md migrate.company.com zimbraMailCatchAllAddress @migrate.company.com zimbraMailCatchAllCanonicalAddress @company.com
- Need instructions to configure for this particular domain mta rules do basically do the below WITHOUT effecting the other domains with the hosting companies ZCS infrastructure.
- $ zmprov mcf zimbraMtaRelayHost mta.COMPANY.com
- $ zmprov mcf zimbraMtaDnsLookupsEnabled FALSE
Break Up User Migration
Determine group of users that make sense to migrate based upon their functions and mailbox sizes. Some items might not work 100% as expect while in transition - i.e. Calendars, Resources, Wiki, etc..
Set Accounts To Maintenance
Set the targeted accounts to Maintenance status. They should stay this way after the backup is completed and will stay like that until the migration to the new server is complete and the split-domain is setup.
On the customers ZCS server, do a backup of the selected users. Be careful of where you direct the backup to and that you'll have space.
mkdir /tmp/backup-accounts zmbackup -f -a userA@company.com userB@company.com userC@company.com -t /tmp/backup-accounts
Problem With Backup
Ideally, we would then do something like this:
zmbackup -i -a userA@company.com userB@company.com userC@company.com -t /tmp/backup-accounts
But this will fail, with:
Error occurred: system failure: Customer backup target is not allowed for incremental backup
And if you don't use the customer target it seems like the incremental picks up all the accounts. The point of wanting this would be to send a full via mail if needed and to allow the incrementals to be small enough to transfer over the network between the customer site and the hosting company.
Set Company Domain Onto Hosting Server
You'll need to setup the companies domain on your server before the zmrestore will work. You might as well configure the COS to make what the customer is using.
If your using a non-default COS.
- zmprov cc companyCOS
- adjust in web admin console if needed
- zmprov gc companyCOS | grep zimbraId
- zimbraId: 420447db-ea43-4d92-b62d-0164767f516d
- zmprov cd company.com
- adjust in web admin console if needed
- zmprov md company.com zimbraDomainDefaultCOSId 420447db-ea43-4d92-b62d-0164767f516d
Set this domain to Maintenance mode.
Restore Account Onto Hosting Server
zmrestore -a userA@company.com userB@company.com userC@company.com -t /tmp/backup-accounts
Move Restored Accounts Into Split-Domain
If split domain is already setup:
zmprov ra userA@company.com userA@migrate.company.com
If not, your could do a domainrename:
zmprov -l rd company.com migrate.company.com
Forward Accounts That Were Moved
On the customers server, you'll now setup those accounts to forward to the split-domain.
Email for userA@company.com forwards to userA@migrate.company.com
Here's another problem though. We need to find a way to switch to a forward/alias on the companies ZCS so that emails don't get bounced with "no such account". You can't setup an alias as long as the account exists on the box.
Third Possibility Untested or QA'd - NOT FINISHED - DON'T USE
Summary Of Idea
I'm sure there's a way you could have both servers hosting the company.com domain at the same time with separate users. Where you had all mail going to a shared non-zimbra MTA host that would direct delivery to either the Hosting or Client ZCS server depending on where the user was at. Of course, you would need to have DNS setup to handle this type of setup (both internal and external). Could your Postini, MailProtector, or other such device do this? Then you would need to figure out a way to handle internal domain delivery between the two systems. The defaults, would have lmtp rejecting the delivery thinking the account doesn't exists because it believes it's authoritative for the domain. Maybe the use of subdomains for aliases/forwarding work be the work around for this.
Diagram Of Flow
ALL Company.com emails to and from MTA HEAD lookups username to determine server to deliver to either/or userA@company.com is userB@company.com is userA@hosting.company.com userB@client.company.com (above is done on MTA device) hosting server has: client server has: hosting.company.com has a client.company.com has a domain alias pointing to company.com domain alias pointing to company.com * see http://wiki.zimbra.com/index.php?title=ManagingDomains#Creating_a_Domain_Alias * hosting server knows (MX record) client server knows (MX record) Eternity server for delivery of hosting server for delivery of eternity.company.com accounts (alias) volaria.company.com accounts (alias) * also see http://wiki.zimbra.com/index.php?title=ManagingDomains#Relaying.2FDomain_Forwarding * Summary of hosting.company.com ZCS server Has a domain called company.com Has a domain alias called hosting.company.com that points to company.com All users are setup within company.com Migrate user(s) via zmrestore command into the domain (company.com) Non-migrated users will have alias setup to forward to email@example.com Will have mail-relaying/forwarding setup for client.company.com Summary of client.company.com ZCS server Has a domain called company.com Has a domain alias called client.company.com that points to company.com All users all ready exist within company.com Non-migrated user(s) will remain untouched Migrate user(s) via zmbackup with individual or list of users as flag Migrated users will have alias setup to forward to firstname.lastname@example.org Will have mail-relaying/forwarding setup for client.company.com
I've only just started to think this one possible solution through, maybe you can pick up what I have and go with it. To see if it might or might not work. Of course there's going to be a performance overhead on this in regards to mail delivery - because of the MTA Head being needed for routing issues. And there's also any security (spam as well) issues to think through.
Some Zimbra Users From DomainA to DomainB On Same Zimbra Server
All Accounts From DomainA to DomainB
You would use [renameDomain]:
zmprov -l rd domainA.com domainB.com
Please review domainrename though, there's some outstanding issues with this depending on your ZCS version.
Account From DomainA to DomainB
You want to use [renameAccount]:
zmprov ra userA@domainA.com userA@domainB.com
This is same command to rename account within the same domain:
zmprov ra userA@domainA.com userB@domainA.com
Non-Zimbra IMAP Accounts To Zimbra
IMAPSYNC with admin login
imapsync --buffersize 8192000 --nosyncacls --subscribe --syncinternaldates \ --host1 server1.test.org --user1 yourAccount --password1 yourPassword \ --host2 zimbra.test.org --user2 yourZimbraAccount --authuser2 admin \ --password2 adminZimbraPassword --authmech2 LOGIN
You can also try --authmech2 PLAIN
I found this description in one of the imapsync files:
"You may authenticate as one user (typically an admin user), but be authorized as someone else, which means you don't need to know every user's personal password. Specify --authuser1 "adminuser" to enable this on host1. In this case, --authmech1 PLAIN will be used, but otherwise, --authmech1 CRAM-MD5 is the default. Same behavior with the --authuser2 option."
Performance Issues With IMAPSYNC
- Running imapsync in parallel:
- Disable ALL attachment indexing:
- Disable ALL indexing (lucense)? I can't find anything yet about if this is or isn't an option. -Ajcody
- No option found as of yet.
- Disable redolog on non-production machine [be very careful with this and make sure your paying attention of what is where]: