View source for Ajcody-Notes-Server-Move

{{BC|Certified}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=Ajcody Notes Server Move=
{{KB|{{ZC}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}

{|  width="75%" border="0" 
|  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]]. 

'''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.
|}

'''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"
** http://bugzilla.zimbra.com/show_bug.cgi?id=84560

==Server Move Notes==

===Actual Server Move Home Page===

Please see: [[:Ajcody-Notes-Server-Move]]

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

----

====References====

Please review the main reference for this page. It will have additional information you should be aware of before following these steps.

* http://www.zimbrablog.com/blog/archives/2007/10/moving-zcs-to-another-server.html
* Another server move wiki page that exists as well:
** [[Moving_ZCS_to_New_Server]]

To do a server move via zmrestoreoffline, see:

* [[Network_Edition_Disaster_Recovery]]

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

Please see these wiki article:
* http://wiki.zimbra.com/wiki/Ajcody-Notes-OS-Upgrade-And-ZCS-Options
** Very detailed to handle some of the OS requirements for ZCS8+
* http://wiki.zimbra.com/wiki/OS_Specific_Platform_Upgrades

====Related RFE's====

The following, if and when done, should also address directly changes in the OS or architecture of the "new" server as compared to the old production server you were moving from.

* "QA & Document OS upgrades & platform changes with major release"
** http://bugzilla.zimbra.com/show_bug.cgi?id=43358

====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.
** '''Note''' This wiki has been used many times to successfully move to a new server that was running a different OS than the OLDPROD. The one condition that does stay true though is the ZCS version must be the same between the two serves. Any ZCS "upgrades" should occur after the migration has been successfully done to the new server using the same ZCS version as the old one. Experience has shown it's generally a non-issue, but I would advise doing a 'test' move first to confirm this prior to attempting a real production server switch over. I can't address all the various issues/tweaks that might or might not need to be addressed with an OS change in this article though - hence, my strong recommendation of a proper "test" before you schedule your production server switch over. ---Ajc , Jan 27, 2015
* 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)
*** See [[Ajcody-Hostname-DNS]] and [[Split_DNS]] about setting up a local BIND/DNS instance on the NEWHOST temporarily. 
* 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:
**** <pre>zmprov gs `zmhostname` zimbraLmtpBindAddress</pre>
**** To modify on NEWHOST - as zimbra 
***** <pre>zmprov -l ms `zmhostname` zimbraLmtpBindAddress "XXX.XXX.XXX.XXX"</pre>
****** 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 :
**** <pre>zmprov gs `zmhostname` zimbraMtaMyNetworks</pre>
**** An examaple to modify on the NEWHOST - as zimbra
***** <pre>zmprov -l ms `zmhostname` zimbraMtaMyNetworks '127.0.0.0/8 10.10.130.0/24'</pre>
** 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>
:: 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
:</pre>
* 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:
:<pre>
:: su - zimbra
:: zmlocalconfig -e mailboxd_java_heap_memory_percent=25
:: zmmailboxdctl restart
:</pre>

=====If You're Attempting A Switch From 32 to 64=====

----

'''Update - 02/01/2014 - I created https://wiki.zimbra.com/wiki/Ajcody-Notes-Server-Move-32-To-64 so it's less confusing to do the steps on this page when you have a 32>64 transition. - Adam Cody'''

: '''Note''' - If you skipped this section for whatever reason and run into the problem later as 
: your attempting to start/install on the new box you can still fix it. Use rpm2cpio to extra the 
: needed data for the zimbramon/ directory. Move the existing one at /opt/zimbra/ to a tmp 
: location and then copy/move the one from your rpm2cpio extraction.
: Get the path to the zimbra-core package within the extracted tarball you have for the zimbra installation : 
:: ex: /root/zcs-NETWORK-6.0.6_GA_2324.RHEL5_64.20100406133038/packages
: Change directory to a temporary location that you'll extract the data to :
:: ex: rpm2cpio /root/zcs-NETWORK-6.0.6_GA_2324.RHEL5_64.20100406133038/packages/zimbracore-6.0.6_GA_2324.RHEL5_64-20100406133038.x86_64.rpm | cpio -idmv
: You'll be able to find the zimbramon directory under there now to copy over to the /opt/zimbra path.


The details of this document assume that both servers are of the same chip type - 32bit or 64bit. Below are notes to "tweak" this how-to to handle a switch as well from 32 to 64.

The two exceptions to this how-to's instructions would be handling the zimbramon direcotry and the inclusion of the 32>64 ldap export/import steps listed in [[Network_Edition:_Moving_from_32-bit_to_64-bit_Server]] :

# On the "new server" , install the 64-bit version of ZCS that is the same version that your old server is running. The only difference would be it's 64 rather than 32-bit tar ball of ZCS.
# Copy /opt/zimbra/zimbramon of the 64bit installed stuff to a tmp dir
#* <pre>[as root] cp -rp /opt/zimbra/zimbramon /opt/zimbramon-64bit</pre>
# On the "old server" do the zmldapcat steps listed in [[Network_Edition:_Moving_from_32-bit_to_64-bit_Server]]
# Proceed with the steps listed in the main body of this how-to
## When you start step 7 in [[Ajcody-Notes-Server-Move#The_Big_Day_-_PROD_Downtime_For_Switch]] section stop.
# Copy the zimbramon-tmp over the /opt/zimbra/zimbramon dir
#* <pre>[as root] cp -rp /opt/zimbramon-64bit/* /opt/zimbra/zimbramon </pre>
#** This is to bypass an reported error, below, during the ./install.sh part . Reports so far have been against Ubuntu.
#***:<pre>Can't load '/opt/zimbra/zimbramon/lib/i486-linux-gnu-thread-multi/auto/IO/IO.so' for module IO: 
#***:/opt/zimbra/zimbramon/lib/i486-linux-gnu-thread-multi/auto/IO/IO.so: wrong ELF class: 
#***:ELFCLASS32 at /usr/lib/perl/5.8/XSLoader.pm line 70.
#***:at /opt/zimbra/zimbramon/lib/i486-linux-gnu-thread-multi/IO.pm line 11</pre>
# Save a copy of your .saveconfig directory and /opt/zimbra/conf/localconfig.xml in case you need to fall back on it. It seems the ./install.sh -s removes the files in .saveconfig and alter's localconfig.xml , which means when you goto do the ./install.sh later it will not see your configuration variable for your server.
#* <pre>[as root] cp -rp /opt/zimbra/.saveconfig /opt/saveconfig-bak</pre>
#* <pre>[as root] cp -p /opt/zimbra/conf/localconfig.xml /opt/localconfig.xml </pre>
# Do a ./install.sh -s from the zimbra installation extract directory as root and then copy back your files from the saveconfig-bak directory.
#* <pre>[as root] cp -rp  /opt/saveconfig-bak/* /opt/zimbra/.saveconfig/</pre>
#* <pre>[as root] cp -p /opt/localconfig.xml /opt/zimbra/conf/ </pre>
# Then follow the steps listed in the 32>64 bit wiki page about restoring the ldap data
#*  Either the 5.x or 6.x section entitled:
#** '''''"5.0.x or previous LDAP setup: 1. Restore the LDAP data to the 64-bit server. As zimbra, type"'''''
#** '''''"6.0.x and later LDAP setup: 1. Restore the LDAP data to the 64-bit server. As zimbra, type"'''''
#* Stop at the point you just finished doing the 
#** '''''"/opt/zimbra/openldap/sbin/slapadd -q -b "" -F /opt/zimbra/data/ldap/config -cv -l /backup/ldap.bak"'''''
# Now proceed with the step 7 section of the server move wiki, which is the full install/upgrade --  ./install.sh  .

=====Moving To A New VMware Image Using Different OS=====

----

A short overview I wrote:

* [[Ajcody-Server-Move-VM-Different-Image-OS]]

====Optional Uses ====

----

=====For DR Prior To Upgrades=====

You could also use this method for a "copy" of your old version prior to doing an upgrade.

=====For Local Disk Partition Changes Rather Than A Server Move=====

Let's say your going to add addition storage and you want to move /opt/zimbra which was on the root partition of / . You could use the rsync steps listed here to make that move and decrease the downtime window versus shutting down zimbra to do a move or copy operation to the new partition. Remember to adjust your /etc/fstab after this otherwise zimbra might not come up after your next server restart.

Typical example of this situation is customer also wanting to change the underlying OS/distro , need to move the zimbra directory off of the / partition onto a new partition they now have available, etc..

Note - if you switch the OS type/version, you'll need to include the steps below about getting the right version of the ZCS binaries on the system and so forth since your 'rsync' copy would have the older version. For the re-install to work, you need the correct binaries - mostly so ldap can run during the installation/upgrade.

====Other Sync Method Processes ====

----

=====BackupPC=====

Some customers have been using BackupPC for server moves and roll backs from ZCS upgrades.

Please see:
* http://backuppc.sourceforge.net/

====Important Advise About Testing Or Practicing This How-To====

----

: [[Image:Attention.png]] '''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 .
# Then rsync or cp [with appropriate option flags] to 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=====


----


:[[Image:Attention.png]] '''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!


# Install Newer (supported) Operating System that matches OLDPROD
# Set up newer ZCS Server’s Hostname as it was on the older server
# Configure BIND locally on NEWHOST to handle resolution issues (A, MX, etc.)
#* [[Image:Attention.png]] '''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.
#*** References:
#**** [[Ajcody-Hostname-DNS]]
#**** [[Split_DNS]]
#* On NEWHOST confirm /etc/hosts , /etc/resolv.conf is set correctly to resolve to NEWHOSTs ip address and NOT the OLDPROD's ip address.
# Download the EXACT version of ZCS that your OLDPROD is using - meaning the ZCS release number [ex. 8.0.7]; for some, it might be a different distro OS release of 8.0.7 [ex ZCS version]. 
#* '''Network Edition'''
#* http://www.zimbra.com/products/downloads.html
#* http://www.zimbra.com/products/downloads_previous.html
#* '''Open Source Edition'''
#* http://www.zimbra.com/community/downloads.html
#* http://www.zimbra.com/community/downloads_previous.html
# ZIMBRA User And UID Match
#:* On OLDPROD as ZIMBRA: <pre>zmlocalconfig zimbra_uid</pre>
#:* 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 NEWHOST configure the entry for zimbra in the OLDPROD's /etc/group to match for zimbra as well.
# 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:
#:* <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.
# On NEWHOST as Root: Remove the dummy install: 
#: <pre>rm -rf /opt/zimbra ; mkdir /opt/zimbra</pre>
# 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=====

----


:[[Image:Attention.png]] '''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''' 
:: 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.
::: http://www.samba.org/rsync/FAQ.html#4 
::Nice and the numeric ranger, from RHEL5 nice man page:
::: Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable).
::: -n, --adjustment=N  add integer N to the niceness (default 10)


# First initial sync of OLDPROD to NEWHOST
#* on OLDPROD as Root
#*: <pre>nice -n +19 rsync -avzH -e ssh --progress /opt/zimbra/ root@NEWHOSTIP:/opt/zimbra</pre>
#*:* '''For ZCS8+ , YOU HAVE TO EXCLUDE THE LDAP DB DIRECTORY [default path is /opt/zimbra/data/ldap ] in your RSYNC command.'''
#*:* On my test box, Ubuntu 12.10 , the syntax for rsync to exclude the default ldap path would be :
#*:** <pre>nice -n +19 rsync -avzH --exclude='data/ldap/*' -e ssh --progress /opt/zimbra/ root@NEWHOSTIP:/opt/zimbra</pre>
#*:** The reason is because of the file size allocation [virtual] that happens with the ldap db now, see the following:
#*:*** http://www.zimbra.com/forums/administrators/59592-ldap-database-went-97meg-86gig-4.html
#*:* Do the same with other paths you might have - i.e. secondary volumes.
#*:** [as zimbra] zmvolume -l
#*:* Some distro's, might want this format for nice :  <pre>nice +19 rsync ....</pre>
# Sync daily until schedule downtime is available
#* On OLDPROD as Root
#*: <pre>nice -n +19 rsync -avzH -e ssh --progress /opt/zimbra/ root@NEWHOSTIP:/opt/zimbra</pre>
#*:* '''For ZCS8+ , YOU HAVE TO EXCLUDE THE LDAP DB DIRECTORY [default path is /opt/zimbra/data/ldap ] in your RSYNC command.'''
#*:* On my test box, Ubuntu 12.10 , the syntax for rsync to exclude the default ldap path would be :
#*:** <pre>nice -n +19 rsync -avzH --exclude='data/ldap/*' -e ssh --progress /opt/zimbra/ root@NEWHOSTIP:/opt/zimbra</pre>
#*:* Do the same with other paths you might have - i.e. secondary volumes.
#*:* Some distro's, might want this format for nice :  <pre>nice +19 rsync ....</pre>
#* Extra Point Comment
#** 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.
#* Copy your crontab over to new system - should be able to use scp or rsync.  /var/spool/cron/zimbra
#** You can then compare the 'old' one to the new one that will be created with the dummy install. You might have customization's that aren't in the new one provided by the basic install - ie, backup schedule, hsm runs, etc.

=====The Big Day - OLDPROD Downtime For Switch=====

----


# Commercial Certificates
#* 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]
## For Versions Prior to ZCS8 , use db_recover - see the following reference for your version:
### http://wiki.zimbra.com/wiki/Ajcody-LDAP-Topics#Attempt_To_Cover_Versions_Higher_Than_ZCS5_-_I.27ve_yet_to_confirm_the_below
## 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
#*: <pre>nice -n -20 rsync -avzHS -e ssh --delete --progress /opt/zimbra/ root@NEWHOSTIP:/opt/zimbra </pre>
#*: '''UPDATE : I've added the -H option to the rsync command to preserve hard links.'''
#*: '''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.
#*:* Some distro's, might want this format for nice :  <pre>nice -20 rsync ....</pre>
# Fix permissions on NEWHOST
#* On NEWHOST as ROOT run
#*: <pre>/opt/zimbra/libexec/zmfixperms --verbose --extended</pre>
# Turn off OLDPROD and reconfigure NEWHOST
#* This is a good time to turn off OLDPROD.
#** Reconfigure the 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.
#** Reconfigure the following now to use the production ip address etc:
#*** The network interface configuration files per your distro
#*** /etc/hosts
#*** /etc/resolve.conf to use your production DNS servers 
#**** disabled BIND on this server if you set it up temporary until you could use the production DNS servers
#** 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.
# Install of Zimbra on NEWHOST
#* 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.
#* On NEWHOST as ROOT, rerun the installer without the -s option. '''Again, this is using the EXACT version of ZCS that your OLDPROD is using - meaning the ZCS release number [ex. 8.0.7]; for some, it might be a different distro OS release of 8.0.7 [ex ZCS version]. Any attempt to upgrade to a newer version of ZCS must be done AFTER you've completed this wiki page in full.'''
#*: <pre>./install.sh --skip-activation-check   #OR This If your version doesn't support the skip activation option#  ./install.sh</pre>
#*** '''Note''' For certain version of 8.x and higher, you'll be required to do a manual activation to start the installer and be including the "-a activation.xml" flag for ./install.sh , once you have the activation.xml .
#**** See:
#***** license server error during installation
#***** https://bugzilla.zimbra.com/show_bug.cgi?id=96371 ""Software only" option should skip activation checks"
#***** https://bugzilla.zimbra.com/show_bug.cgi?id=80043
#***** http://wiki.zimbra.com/wiki/Manual_activation
#** 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.
#*** Copy from your OLDPROD's /opt/zimbra/conf/ directory the localconfig.xml file to the NEWHOST's /opt/zimbra/conf/ directory.
#*** Restart the the installation again with ./install.sh --skip-activation-check or ./install.sh , depending on your version
#*** 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.
#** Confirm your license is valid and activated:
#***: <pre> zmlicense -c ; zmlicense -p | grep -A4 Activation</pre>
# 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.
# 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.

===Things To Check Before Going Production Again===

See the post checks from the DR page:

* http://wiki.zimbra.com/wiki/Network_Edition_Disaster_Recovery#Post_Restore_And_Confirmation_Steps

===Additional Topics===

----

====Zimbra Domains Into An Existing Zimbra Server====

See [[Ajcody-Migration-Notes]] . There's a couple of possibilities being worked out there.

{{Article_Footer|unknown|7/23/2008}} 

----

[[Category: Community Sandbox]]
[[Category:Server Move]]
[[Category:Disaster Recovery]]
[[Category: Author:Ajcody]]