| bgcolor="orange" | [[Image:Attention.png]] - This article describes the steps to move a ZCS server to a new physical or virtual server. Technically, this is not 100% supported as it is not a method that the developers or QA teams test against. But because of customer demands and needs, this method is often preferred compared to [[Network_Edition_Disaster_Recovery]].

| bgcolor="orange" | [[Image:Attention.png]] - This article describes the steps to move a ZCS server to a new physical or virtual server. Technically, this is not 100% supported as it is not a method that the developers or QA teams test against. But because of customer demands and needs, this method is often preferred compared to [[Network_Edition_Disaster_Recovery]].

Line 9:

Line 15:

'''Discussion on this document is located here:

'''Discussion on this document is located here:

−

* "Ajcody-Notes-Server-Move Needed Updates / Discussion"

−

** http://bugzilla.zimbra.com/show_bug.cgi?id=84561

* "Ajcody-Notes-Server-Move 32 to 64 Updates"

* "Ajcody-Notes-Server-Move 32 to 64 Updates"

** http://bugzilla.zimbra.com/show_bug.cgi?id=84560

** http://bugzilla.zimbra.com/show_bug.cgi?id=84560

−

{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}|{{ZCS 6.0}}||}}

+

==Actual Server Move From 32 To 64 Home Page==

−

−

−

==Server Move Notes==

−

−

===Actual Server Move 32 To 64 Home Page===

−

Please see: [[:Ajcody-Notes-Server-Move-32-To-64]]

Please see: [[:Ajcody-Notes-Server-Move-32-To-64]]

−

===Server Move To Same Platform (32/64bit) And OS Type & Version===

+

===Prior Information That Should Be Reviewed===

−

----

+

'''Discussion on this document is located here:

+

* "Ajcody-Notes-Server-Move 32 to 64 Updates"

+

** http://bugzilla.zimbra.com/show_bug.cgi?id=84560

−

=====OS Changes Also Happening=====

+

====OS Changes Also Happening====

Please see these wiki article:

Please see these wiki article:

Line 59:

Line 59:

**** I also included the -l option for the zmprov ms examples since the NEWHOST most likely will only be able to start the ldap service until you have these variables changed.

**** I also included the -l option for the zmprov ms examples since the NEWHOST most likely will only be able to start the ldap service until you have these variables changed.

** Since there are many possible variable that might include a specific ip reference, it would be best to do something like the following on the OLDPROD and review the possible variables you might have set that are using an explicit ip address.

** Since there are many possible variable that might include a specific ip reference, it would be best to do something like the following on the OLDPROD and review the possible variables you might have set that are using an explicit ip address.

:<pre>

:<pre>

Line 80:

Line 80:

:</pre>

:</pre>

* 4. '''SAME AMOUNT OF MEMORY'''

* 4. '''SAME AMOUNT OF MEMORY'''

−

** If your moving from 32bit to 32bit and the new system has more than 4GB of memory and the older one didn't you will most likely need to adjust mailboxd_java_heap_memory_percent . This problem will show up as the mailbox stop starting and /opt/zimbra/log/zmmailboxd.out logging errors about JVM memory heap. Try the following:

+

** If your moving from 32bit to a 64bit system and the new system has more than 4GB of memory and the older one didn't, you will most likely need to adjust mailboxd_java_heap_memory_percent . This problem will show up as the mailbox stop starting and /opt/zimbra/log/zmmailboxd.out logging errors about JVM memory heap. Try the following:

:<pre>

:<pre>

:: su - zimbra

:: su - zimbra

Line 117:

Line 117:

Final word of advise, please consider installing bind or some other DNS service on your NEWHOST so you can handle resolution locally on that server to resolve to the different ip address the NEWHOST is using. Consult [[Ajcody-Hostname-DNS]] and [[Split_DNS]] for more details.

Final word of advise, please consider installing bind or some other DNS service on your NEWHOST so you can handle resolution locally on that server to resolve to the different ip address the NEWHOST is using. Consult [[Ajcody-Hostname-DNS]] and [[Split_DNS]] for more details.

−

====The Actual Steps====

+

==The Actual Steps==

−

−

----

−

−

=====Preparing NEWHOST Server=====

+

===Preparing NEWHOST Server===

----

----

Line 130:

Line 127:

:::: You should always run the rsync command manually. If you fail to do so, and then complete the migration without removing the cron job that did the sync's, and you leave the old server running, you will lose data. The sync will then kick off again when cron runs and overwrite your production data! This will very likely corrupt your installation and leave you with an unstable system!

:::: You should always run the rsync command manually. If you fail to do so, and then complete the migration without removing the cron job that did the sync's, and you leave the old server running, you will lose data. The sync will then kick off again when cron runs and overwrite your production data! This will very likely corrupt your installation and leave you with an unstable system!

+

====Preparation And Install OS====

−

# Install Newer (supported) Operating System that matches OLDPROD

+

# Install on the NEWHOST a supported operating system for the current ZCS version running on the OLDPROD. Consult the ZCS download pages below to determine which OS version you can use.

#** If dns resolution of the zmhostname on the NEWHOST resolves to the OLDPROD's ip address - this will most likely cause a production outage on OLDPROD since all zm commands ran on NEWHOST will actually be sent to OLDPROD. You will most likely need to do a DR recovery on OLDPROD if you don't confirm the ip resolution is correct on the NEWHOST.

+

#* Configure BIND locally on NEWHOST to handle resolution issues (A, MX, etc.) . This will allow the two machines to talk to each other without causing production issues.

## On NEWHOST confirm /etc/hosts , /etc/resolv.conf

## On NEWHOST confirm /etc/hosts , /etc/resolv.conf

−

# Download the EXACT version that your OLDPROD is using.

+

# '''It is very important''' that you confirm that both machines can reach other and use ssh/rsync by ip address and that from each one, if one try to use the hostname for resolution that they only return their local ip adress.

#** OLDPROD has /etc/hosts and /etc/resolve.conf using the production DNS servers returns an address of 192.168.0.1 when doing a lookups for zimbramail.domain.com [nslookup zimbramail.domain.com].

+

#* NEWHOST's hostname is also, for example - zimbramail.domain.com BUT uses an ip address of 192.168.0.35

+

#** NEWHOST's has /etc/hosts and /etc/resolve.conf using a '''NON-PRODUCTION DNS server''' returns an address of 192.168.0.35 and '''NOT 192.168.0.1''' when doing a lookups for zimbramail.domain.com [nslookup zimbramail.domain.com].

+

#*** Setting up a '''NON-PRODUCTION DNS server''' easily can be done by setting up and installing BIND on the NEWHOST. This would be disabled once the move is completely done and you would then adjust the /etc/hosts and /etc/resolv.conf was set as it was on OLDPROD.

+

# '''Special Note''' - If your hostname on OLDPROD does not also match/equal the return of zmhostname, [su - zimbra ; zmhostname] then you'll also have to account for that name in regards to the discussion above about /etc/hosts and what DNS is or is not returning.

+

+

=====''Download Needed ZCS Version''=====

+

+

# Download the EXACT version of ZCS that your OLDPROD is using for the OS that was installed on the NEWHOST.

#* '''Network Edition'''

#* '''Network Edition'''

#* http://www.zimbra.com/products/downloads.html

#* http://www.zimbra.com/products/downloads.html

Line 142:

Line 155:

#* http://www.zimbra.com/community/downloads.html

#* http://www.zimbra.com/community/downloads.html

#* http://www.zimbra.com/community/downloads_previous.html

#* http://www.zimbra.com/community/downloads_previous.html

−

# ZIMBRA User And UID Match

+

−

#:* On OLDPROD as ZIMBRA: <pre>zmlocalconfig zimbra_uid</pre>

+

====Configure Zimbra UID and GID To Match On NEWHOST As On OLDPROD====

−

#:* On OLDPROD, note the zimbra entry in /etc/passwd and /etc/group.

+

−

#:* On NEWHOST configure the /etc/passwd to be the same UID for zimbra as the OLDPROD had.

+

# On OLDPROD as ZIMBRA: <pre>zmlocalconfig zimbra_uid</pre>

−

#:* On NEWHOST configure the entry for zimbra in the OLDPROD's /etc/group to match for zimbra as well.

+

# On OLDPROD, note the zimbra entry in /etc/passwd and /etc/group.

−

# ﻿On NEWHOST as ROOT: Run the installer with the -s option:

+

# On NEWHOST configure the /etc/passwd to be the same UID for zimbra as the OLDPROD had.

−

#: <pre>./install.sh -s</pre>

+

# On NEWHOST configure the entry for zimbra in the OLDPROD's /etc/group to match for zimbra as well.

−

#:* This tells the installer to only install the software, and not to configure the installation.

+

−

#:* To see what is installed and enabled on the PROD server, do the following on the PROD server:

+

====Initial ZCS Install On NEWHOST====

−

#:* <pre>zmprov gs `zmhostname` | grep zimbraService</pre>

+

−

#:* Save this list, you'll need it also when you rerun the installer later on the NEWHOST to confirm the "upgrade" does the right package upgrades/installs.

+

=====Know What ZCS Packages To Install On NEWHOST=====

−

# ﻿On NEWHOST as Root: Remove the dummy install:

+

+

# On OLDPROD , do the following as the ZIMBRA user. You will want to save this list in your notes incase you need to consult it later in this process.

+

#: <pre>zmprov gs `zmhostname` | grep zimbraService</pre>

+

+

=====''Initial ZCS Install On NEWHOST Steps''=====

+

# On NEWHOST as ROOT , run the installer with the -s option:

+

#:<pre>./install.sh -s</pre>

+

#* This tells the installer to only install the software, and not to configure the installation.

+

# To see what is installed and enabled on the PROD server, do the following on the PROD server as ZIMBRA:

+

#:<pre>zmprov gs `zmhostname` | grep zimbraService</pre>

+

#* Save this list, you'll need it also when you rerun the installer later on the NEWHOST to confirm the "upgrade" does the right package upgrades/installs.

#* '''IMPORTANT''' - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

====Rsync's To Do After Initial One Until Schedule Move Transition====

+

# Sync daily until schedule downtime is available

# Sync daily until schedule downtime is available

+

#* '''IMPORTANT''' - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

#** One could also use a more aggressive nice value to start a job after hours but then include a renice command via cron prior to your normal business hours the next day. You would need to script this out though since it would need the process # of the command you wanted to renice.

#** One could also use a more aggressive nice value to start a job after hours but then include a renice command via cron prior to your normal business hours the next day. You would need to script this out though since it would need the process # of the command you wanted to renice.

#* Are you prepared for the impact this server move has for your commercial certificate? This document doesn't address that.

−

# Block client access to the old server's IP address with firewall rules

−

#* If your remote, make sure to keep your access port open. We are just trying to prevent any changes to the machines while they are being reconfigured.

−

# Shut down Zimbra on OLDPROD

−

#* On OLDPROD as ZIMBRA

−

#*: <pre>su - zimbra</pre>

−

#*: <pre>zmcontrol stop</pre>

−

# [[Image:Attention.png]] '''Please Note - Prior To Final Rsync'''

−

#*:: '''YOU MUST PERFORM THIS STEP WITH ZIMBRA DOWN!'''

−

#*:: Please ensure that you have the Zimbra server STOPPED before performing the final rsync. If you're using this method to test your server move, you must schedule downtime to stop the server before performing the final sync. This is required, and failure to do so will result in corruption of your mysql/ldap databases on the test server.

# Get LDAP in a good state prior to the final rsync [as recommend by our LDAP developer - 12/1/2012]

# Get LDAP in a good state prior to the final rsync [as recommend by our LDAP developer - 12/1/2012]

## For Versions Prior to ZCS8 , use db_recover - see the following reference for your version:

## For Versions Prior to ZCS8 , use db_recover - see the following reference for your version:

## For ZCS8 , db_recover isn't needed. '''You must include the -S option though for rsync.'''

## For ZCS8 , db_recover isn't needed. '''You must include the -S option though for rsync.'''

−

# Last rsync of OLDPROD to NEWHOST

+

−

#* On Prod as ROOT

+

====Final Rsync of OLDPROD to NEWHOST====

+

+

: [[Image:Attention.png]] '''Please Note - YOU MUST PERFORM THIS STEP WITH ZIMBRA DOWN!'''

+

+

* Please ensure that you have the Zimbra server STOPPED on BOTH OLDPROD and NEWHOST before performing the final rsync. If you're using this method to test your server move, you must schedule downtime to stop the server before performing the final sync. This is required, and failure to do so will result in corruption of your mysql/ldap databases on the test server.

+

+

+

# Final Rsync,

+

#* '''IMPORTANT''' - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

#*: '''UPDATE : I've added the -S option to the rsync command to handle sparse files. With ZCS8's ldap setup, this is necessary. See [[OpenLDAP_Performance_Tuning_8.0#Notes_on_MDB]] for details. 12/1/2012'''

#*: '''UPDATE : I've added the -S option to the rsync command to handle sparse files. With ZCS8's ldap setup, this is necessary. See [[OpenLDAP_Performance_Tuning_8.0#Notes_on_MDB]] for details. 12/1/2012'''

#*:* Do the same with other paths you might have - i.e. secondary volumes.

#*:* Do the same with other paths you might have - i.e. secondary volumes.

#** Reconfigure network interfaces so if someone turns on OLDPROD later, it will not use the ip addresses that will now be used on NEWHOST.

+

−

#** Reconfigure any mounts (san, nfs, iscsi, etc.) so it will not mount anything that should only be mounted on our NEWHOST. Again, in case the machine is powered on accidentally later.

+

====Bring over the LDAP Data from OLDPROD To the NEWHOST====

−

#* Reconfigure NEWHOST to take over ip addresses of OLDPROD.

+

−

#** Make any firewall or other network changes that are necessary.

+

: '''For 6.0.x and later LDAP data:'''

−

#*** Remember about arp tables.

+

−

#* Reconfigure for any mounts that were on OLDPROD that will be needed for NEWHOST.

+

# Restore the LDAP data to the NEWHOST. On NEWHOST as ZIMBRA, type

−

# Install of Zimbra on NEWHOST

+

#: <pre>rm -rf /opt/zimbra/data/ldap/config/*</pre>

−

#* If you have a Split DNS install or use private LAN addresses on the server with a firewall front-ending the public addresses, you'll want to verify logical hostname resolution and hostname resolution

+

#: <pre>rm -rf /opt/zimbra/data/ldap/hdb/*</pre>

−

#** In some cases, you can move Zimbra to another server with a different hostname but keep the logical hostname the same. The logical hostname is what users know this server as, and it doesn't necessarily have to match the actual hostname.

# Copy the file /opt/zimbra/data/ldap/hdb/db/DB_CONFIG from the OLDPROD to /opt/zimbra/data/ldap/hdb/db on the NEWHOST.

−

#*** <pre>nslookup `hostname`</pre>

+

#* Note: If this file does not exist, or is empty, creating it may improve ldap performance; see the [[Performance_Tuning_Guidelines_for_Large_Deployments|Performance Tuning Guide]] for more information.

−

#*** <pre>nslookup (logical hostname)</pre>

+

# Set permissions on the ldap directory. On NEWHOST as ZIMBRA, type: [If you can't as ZIMBRA, use ROOT]

−

#*** <pre>nslookup (old hostname)</pre>

+

#: <pre>chown -R zimbra:zimbra /opt/zimbra/data/ldap</pre>

−

#*** <pre>nslookup (old hostname)</pre>

+

# Copy from the OLDPROD to the NEWHOST the /opt/ldap-backup/ldap-config.bak and /opt/ldap-backup/ldap.bak files to NEWHOST:/opt/ldap-backup/

−

#** You want all these to look the same. You can follow instructions at [[Split_dns]]. Essentially what that does is have a local copy of bind (named) running that resolves just those names and forwards all other lookups to your normal DNS servers.

+

# Restoring the LDAP data onto NEWHOST.

−

#* On NEWHOST as ROOT, rerun the installer without the -s option

+

#* Adjust the directory path of /opt/ldap-backup/ in the commands below if you have the ldap-config.bak & ldap.bak in a different location.

−

#*: <pre>./install.sh</pre>

+

## On NEWHOST as ZIMBRA, type

−

#** It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.

If you have a Split DNS install or use private LAN addresses on the server with a firewall front-ending the public addresses, you'll want to verify logical hostname resolution and hostname resolution. In some cases, you can move Zimbra to another server with a different hostname but keep the logical hostname the same. The logical hostname is what users know this server as, and it doesn't necessarily have to match the actual hostname. For example, you might have "mail.mydomain.com" as the DNS name for the server, but the hostname is "web11233"

+

+

+

* You need to have the server itself resolve the logical hostname, the old hostname and the new hostname as the internal private LAN address.

+

*: <pre>host `hostname`</pre>

+

*: <pre>host (logical hostname)</pre>

+

*: <pre>nslookup `hostname`</pre>

+

*: <pre>nslookup (logical hostname)</pre>

+

*: <pre>nslookup (old hostname)</pre>

+

*: <pre>nslookup (old hostname)</pre>

+

* You want all these to look the same. You can follow instructions at [[Split_dns]]. Essentially what that does is have a local copy of bind (named) running that resolves just those names and forwards all other lookups to your normal DNS servers.

+

+

====Install of Zimbra on NEWHOST====

+

+

+

# On NEWHOST as ROOT, rerun the installer without the -s option

+

#:: <pre>./install.sh</pre>

+

# It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.

+

## You can confirm the package installation/upgrade selection by comparing the output from the OLDPROD host by running this on the OLDPROD host

+

##: <pre>zmprov gs `zmhostname` | grep zimbraService</pre>

+

## [[Image:Attention.png]] '''Note''' - If in the configuration screen it looks like it doesn't have your old values, then the localconfig.xml in /opt/zimbra/conf must of been altered. To fix:

+

##* Stop/cancel the install - you'll see an option for it from the list of options.

##* If that failed to fixed the install configuration screen situation, redo the above but also remove /opt/zimbra/.saveconfig from NEWHOST and copy that directory from OLDPROD.

+

# Within the installation script, you might want to choose the option that tells Zimbra to NOT automatically start upon completion of upgrade/install.

+

+

====Post-Install on NEWHOST====

+

#* This document assumes you were going to get the same hostname and ip address once the final move was done. In case this isn't true, below are some follow up issues you might want to check. '''''You might of done some of these already.'''''

#* This document assumes you were going to get the same hostname and ip address once the final move was done. In case this isn't true, below are some follow up issues you might want to check. '''''You might of done some of these already.'''''

#** Do you need to make adjustments for commercial certificates?

#** Do you need to make adjustments for commercial certificates?

Line 279:

Line 371:

#*** If ip address is going to be the same, remember your network will take awhile to see change as the new MAC address gets updated to other devices arp table.

#*** If ip address is going to be the same, remember your network will take awhile to see change as the new MAC address gets updated to other devices arp table.

#**** If you can, you can speed this along with changes on your switches.

#**** If you can, you can speed this along with changes on your switches.

- This is certified documentation and is protected for editing by Zimbra Employees & Moderators only.

- This article is a Work in Progress, and may be unfinished or missing sections.

- This article describes the steps to move a ZCS server to a new physical or virtual server. Technically, this is not 100% supported as it is not a method that the developers or QA teams test against. But because of customer demands and needs, this method is often preferred compared to Network_Edition_Disaster_Recovery.

THIS IS THE ONLY OTHER DOCUMENTED METHOD BESIDES THE Network_Edition_Disaster_Recovery WIKI FOR A ZCS SERVER MOVE PROCESS THAT ZIMBRA WILL SUPPORT AND ACCEPT SUPPORT CASES FOR.

Support cases should reference this wiki page and include a copy of all the steps and output of them as you work through this how-to. Then noting the issue and step in the how-to your stuck at.

Assumptions

Basic Assumptions

1. OS Type & Version

This article makes the assumption your moving to the same OS type & version. For example, your OLDPROD machine is running RHEL4-64bit. So your new machine would be running the same and brought to the same patch level as well.

2. Same HOSTNAME

New server is setup with the same HOSTNAME information as OLDPROD but it will use a different IP until OLDPROD can be shutoff/reconfigured (if needed)

3. Different IP Issues - Either For Testing Or As A Permanent Change

Problems that are caused by different ip's being in use related to zcs variables will usually show up on the NEWHOST where services [usually mailboxd] can't successfully start.

Note about command examples below.

I used `zmhostname` rather than typing out an explicit hostname.

I also included the -l option for the zmprov ms examples since the NEWHOST most likely will only be able to start the ldap service until you have these variables changed.

One example variable to look for:

zmprov gs `zmhostname` zimbraLmtpBindAddress

To modify on NEWHOST - as zimbra

zmprov -l ms `zmhostname` zimbraLmtpBindAddress "XXX.XXX.XXX.XXX"

replace XXX.XXX.XXX.XXX with the ip address on the NEWHOST

Another example variable to look for - this would be an issue if the NEWHOST is on a different subnet than OLDPROD :

Since there are many possible variable that might include a specific ip reference, it would be best to do something like the following on the OLDPROD and review the possible variables you might have set that are using an explicit ip address.

su - zimbra

ip addr

ifconfig -a

[ NOTE THE IP's BEING USED - You'll grep for the first octet below ]

[ For example, my server's eth0 is using 192.168.0.71 ]

zmlocalconfig | grep 192

[192 is based upon my example]

zmprov gacf | grep 192

zmprov gs `zmhostname` | grep 192

4. SAME AMOUNT OF MEMORY

If your moving from 32bit to a 64bit system and the new system has more than 4GB of memory and the older one didn't, you will most likely need to adjust mailboxd_java_heap_memory_percent . This problem will show up as the mailbox stop starting and /opt/zimbra/log/zmmailboxd.out logging errors about JVM memory heap. Try the following:

su - zimbra

zmlocalconfig -e mailboxd_java_heap_memory_percent=25

zmmailboxdctl restart

Important Advise About Testing Or Practicing This How-To

We strongly encourage customers to 'test' this how-to prior to scheduling

your final downtime for the production server to be moved.

If you plan accordingly, you'll only need two downtime windows on the production server to include this testing. These downtime windows will be much shorter using rsync versus other means to do your server move.

To allow for this recommend testing, please adjust the how-to steps below with the following information. Since at some point you'll have to shutdown zimbra on the production server to get your final rsync, you should preserve the rsync'd data on the NEWHOST if you have the available disk space.

Alternation to the rsync targets:

rsync OLDPROD:/opt/zimbra data to NEWHOST:/opt/zimbra-BACKUP rather than NEWHOST:/opt/zimbra .

Leaving the NEWHOST:/opt/zimbra-BACKUP intact for later reuse for testing and etc..

For retesting purposes, you have two possible methods.

First - jut rsync over the NEWHOST:/opt/zimbra directory

You would use the rsync command that includes the --delete option, since we want NEWHOST:/opt/zimbra to be exactly the same as NEWHOST:/opt/zimbra-BACKUP .

Second - remove NEWHOST:/opt/zimbra and then rsync NEWHOST:/opt/zimbra-BACKUP [copying anything over again into a new and empty NEWHOST:/opt/zimbra ]

run the uninstall option via the zimbra installation script - install.sh -u - on the NEWHOST.

[NEWHOST] rm -rf /opt/zimbra . We want to confirm all files are gone.

Remove any 'zimbra' files in /tmp

And now restart the how-to with a clean zcs installation followed by another rsync of NEWHOST:/opt/zimbra-BACKUP to NEWHOST:/opt/zimbra .

Note - I just used /opt/zimbra above, you'll need to include other data/zmvolume paths as well if you have them.

Final word of advise, please consider installing bind or some other DNS service on your NEWHOST so you can handle resolution locally on that server to resolve to the different ip address the NEWHOST is using. Consult Ajcody-Hostname-DNS and Split_DNS for more details.

The Actual Steps

Preparing NEWHOST Server

Please Note - DO NOT USE CRON WHEN SYNCING YOUR SERVER!

You should always run the rsync command manually. If you fail to do so, and then complete the migration without removing the cron job that did the sync's, and you leave the old server running, you will lose data. The sync will then kick off again when cron runs and overwrite your production data! This will very likely corrupt your installation and leave you with an unstable system!

Preparation And Install OS

Install on the NEWHOST a supported operating system for the current ZCS version running on the OLDPROD. Consult the ZCS download pages below to determine which OS version you can use.

Configure Hostname And DNS Resolution

﻿Set up NEWHOST ZCS Server’s Hostname as it was on the older server

Please Note - The NEWHOST MUST RESOLVE THE ZMHOSTNAME TO IT'S OWN IP ADDRESS!

If dns resolution of the zmhostname on the NEWHOST resolves to the OLDPROD's ip address - this will most likely cause a production outage on OLDPROD since all zm commands ran on NEWHOST will actually be sent to OLDPROD. You will most likely need to do a DR recovery on OLDPROD if you don't confirm the ip resolution is correct on the NEWHOST.

Configure BIND locally on NEWHOST to handle resolution issues (A, MX, etc.) . This will allow the two machines to talk to each other without causing production issues.

On NEWHOST confirm /etc/hosts , /etc/resolv.conf

It is very important that you confirm that both machines can reach other and use ssh/rsync by ip address and that from each one, if one try to use the hostname for resolution that they only return their local ip adress.

OLDPROD has /etc/hosts and /etc/resolve.conf using the production DNS servers returns an address of 192.168.0.1 when doing a lookups for zimbramail.domain.com [nslookup zimbramail.domain.com].

NEWHOST's hostname is also, for example - zimbramail.domain.com BUT uses an ip address of 192.168.0.35

NEWHOST's has /etc/hosts and /etc/resolve.conf using a NON-PRODUCTION DNS server returns an address of 192.168.0.35 and NOT 192.168.0.1 when doing a lookups for zimbramail.domain.com [nslookup zimbramail.domain.com].

Setting up a NON-PRODUCTION DNS server easily can be done by setting up and installing BIND on the NEWHOST. This would be disabled once the move is completely done and you would then adjust the /etc/hosts and /etc/resolv.conf was set as it was on OLDPROD.

Special Note - If your hostname on OLDPROD does not also match/equal the return of zmhostname, [su - zimbra ; zmhostname] then you'll also have to account for that name in regards to the discussion above about /etc/hosts and what DNS is or is not returning.

Download Needed ZCS Version

Download the EXACT version of ZCS that your OLDPROD is using for the OS that was installed on the NEWHOST.

Configure Zimbra UID and GID To Match On NEWHOST As On OLDPROD

On NEWHOST configure the /etc/passwd to be the same UID for zimbra as the OLDPROD had.

On NEWHOST configure the entry for zimbra in the OLDPROD's /etc/group to match for zimbra as well.

Initial ZCS Install On NEWHOST

Know What ZCS Packages To Install On NEWHOST

On OLDPROD , do the following as the ZIMBRA user. You will want to save this list in your notes incase you need to consult it later in this process.

zmprov gs `zmhostname` | grep zimbraService

Initial ZCS Install On NEWHOST Steps

On NEWHOST as ROOT , run the installer with the -s option:

./install.sh -s

This tells the installer to only install the software, and not to configure the installation.

To see what is installed and enabled on the PROD server, do the following on the PROD server as ZIMBRA:

zmprov gs `zmhostname` | grep zimbraService

Save this list, you'll need it also when you rerun the installer later on the NEWHOST to confirm the "upgrade" does the right package upgrades/installs.

Preserving The 64bit zimbramon Directory'

﻿On NEWHOST as ROOT: Move the zimbramon directory [if it exists] to /opt/zimbramon

mv /opt/zimbra/zimbramon /opt/zimbramon-64

Remove The /opt/zimbra Dummy Install

﻿On NEWHOST as ROOT: Remove the dummy install:

rm -rf /opt/zimbra ; mkdir /opt/zimbra

Create Directory Paths For Any Necessary Mounts Points For Later

On NEWHOST, make any other mounts or directories you'll need as to match the OLDPROD server.

Secondary mailstores, alternative backup directory paths, etc.

On OLDPROD, double check for these additional mounts by doing:

reviewing /etc/fstab and output of the df command.

run, as ZIMBRA, the following: zmvolume -l and review the output and directory paths.

Sync OLDPROD Data While OLDPROD Is Still In Production Use

Please Note - DO NOT USE CRON WHEN SYNCING YOUR SERVER!

You should always run the rsync command manually. If you fail to do so, and then complete the migration without removing the cron job that did the sync's, and you leave the old server running, you will lose data. The sync will then kick off again when cron runs and overwrite your production data! This will very likely corrupt your installation and leave you with an unstable system!

Preliminary Comments About RSYNC

Rsync options used below.

I've added the -H option to the rsync command to preserve hard links.

-H, --hard-links , preserves hard links

-a, --archive . This is equivalent to -rlptgoD .

From man page:

It is a quick way of saying you want recursion and want to preserve almost everything (with -H being a notable omission). The only exception to the above equivalence is when --files-from is specified, in which case -r is not implied. Note that -a does not preserve hardlinks, because finding multiply-linked files is expensive. You must separately specify -H.

-z, --compress

From man page:

With this option, rsync compresses the file data as it is sent to the destination machine, which reduces the amount of data being transmitted -- something that is useful over a slow connection.

You should upgrade rsync on both servers to version 3+. It addresses some performance issues. Please see the following for more details.

Initial Rsync Of OLDPROD To NEWHOST

First initial sync of OLDPROD to NEWHOST

IMPORTANT - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

on OLDPROD as ROOT do the following [Note, some distro's might require "nice +19 rsync vs. nice -n +19 rsync"]

Rsync's To Do After Initial One Until Schedule Move Transition

Sync daily until schedule downtime is available

IMPORTANT - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

One could also use a more aggressive nice value to start a job after hours but then include a renice command via cron prior to your normal business hours the next day. You would need to script this out though since it would need the process # of the command you wanted to renice.

The Big Day - OLDPROD Downtime For Switch

Block Client Access To OLDPROD's IP Address With Firewall - IPTables

If your remote, make sure to keep your access port open. We are just trying to prevent any changes to the machines while they are being reconfigured.

Do Backup of LDAP DATA on OLDPROD

Note - this wiki page only applies to ZCS 6 and later

Create an LDAP dump directory. As root, type

mkdir /opt/ldap-backup ; chown zimbra:zimbra /opt/ldap-backup

Stop ZCS on OLDPROD, as zimbra type

su - zimbra ; zmcontrol stop

Backup the LDAP config database, as zimbra, type

/opt/zimbra/libexec/zmslapcat -c /opt/ldap-backup

Backup the LDAP data, as zimbra, type

/opt/zimbra/libexec/zmslapcat /opt/ldap-backup

Confirm LDAP In Good State

Get LDAP in a good state prior to the final rsync [as recommend by our LDAP developer - 12/1/2012]

For Versions Prior to ZCS8 , use db_recover - see the following reference for your version:

For ZCS8 , db_recover isn't needed. You must include the -S option though for rsync.

Final Rsync of OLDPROD to NEWHOST

Please Note - YOU MUST PERFORM THIS STEP WITH ZIMBRA DOWN!

Please ensure that you have the Zimbra server STOPPED on BOTH OLDPROD and NEWHOST before performing the final rsync. If you're using this method to test your server move, you must schedule downtime to stop the server before performing the final sync. This is required, and failure to do so will result in corruption of your mysql/ldap databases on the test server.

Final Rsync,

IMPORTANT - The example below is using only /opt/zimbra , if you have other directory paths in use for Zimbra data [zmvolume -l and/or different path for your zimbra backups] you must then adjust your rsync command for those other paths.

Fix permissions on NEWHOST

Turn off OLDPROD and reconfigure NEWHOST

Reconfigure network interfaces so if someone turns on OLDPROD later, it will not use the ip addresses that will now be used on NEWHOST.

Reconfigure any mounts (san, nfs, iscsi, etc.) so it will not mount anything that should only be mounted on our NEWHOST. Again, in case the machine is powered on accidentally later.

Reconfigure NEWHOST to take over ip addresses of OLDPROD.

Make any firewall or other network changes that are necessary.

Remember about arp tables.

Reconfigure for any mounts that were on OLDPROD that will be needed for NEWHOST.

Special Check For DNS, IP Address, And Hostname Configurations

If you have a Split DNS install or use private LAN addresses on the server with a firewall front-ending the public addresses, you'll want to verify logical hostname resolution and hostname resolution. In some cases, you can move Zimbra to another server with a different hostname but keep the logical hostname the same. The logical hostname is what users know this server as, and it doesn't necessarily have to match the actual hostname. For example, you might have "mail.mydomain.com" as the DNS name for the server, but the hostname is "web11233"

You need to have the server itself resolve the logical hostname, the old hostname and the new hostname as the internal private LAN address.

host `hostname`

host (logical hostname)

nslookup `hostname`

nslookup (logical hostname)

nslookup (old hostname)

nslookup (old hostname)

You want all these to look the same. You can follow instructions at Split_dns. Essentially what that does is have a local copy of bind (named) running that resolves just those names and forwards all other lookups to your normal DNS servers.

Install of Zimbra on NEWHOST

On NEWHOST as ROOT, rerun the installer without the -s option

./install.sh

It will detect ZCS already installed, and ask if you want to upgrade. Select Yes.

You can confirm the package installation/upgrade selection by comparing the output from the OLDPROD host by running this on the OLDPROD host

zmprov gs `zmhostname` | grep zimbraService

Note - If in the configuration screen it looks like it doesn't have your old values, then the localconfig.xml in /opt/zimbra/conf must of been altered. To fix:

Stop/cancel the install - you'll see an option for it from the list of options.

If that failed to fixed the install configuration screen situation, redo the above but also remove /opt/zimbra/.saveconfig from NEWHOST and copy that directory from OLDPROD.

Within the installation script, you might want to choose the option that tells Zimbra to NOT automatically start upon completion of upgrade/install.

Post-Install on NEWHOST

This document assumes you were going to get the same hostname and ip address once the final move was done. In case this isn't true, below are some follow up issues you might want to check. You might of done some of these already.

Do you need to make adjustments for commercial certificates?

Reconfigure any network interface/ip information that you need because of hardware move.

Make necessary adjustments you might need because of hostname changes. ( see ZmSetServerName )

Adjust any firewall settings

If ip address is going to be different, make sure you know the settings you'll need to adjust within Zimbra (if any).

If ip address is going to be the same, remember your network will take awhile to see change as the new MAC address gets updated to other devices arp table.

If you can, you can speed this along with changes on your switches.

Bringing Up Zimbra On NEWHOST For Production Use

Start zimbra once you think everything is ready.

Do some client access tests within your LAN.

If testing looks good, the remove any firewall rules you might of done to block access from outside. Then confirm outside access and functionality.

Remember to check those mobile devices, certificates, and other access software/devices besides just the Zimbra webclient.