Zimbra Collaboration 9.0.0 Upgrade Steps

Before you upgrade

Please review the following information to decide if Zimbra Collaboration 9.0.0 is suitable for you.

Zimbra Touch Client, Zimbra Mobile Client, and Zimbra HTML (Standard) Client are no longer a part of Zimbra starting from Version 9.0.0.

Zimbra Connect replaces Zimbra Talk during the upgrade process. You must choose to install zimbra-connect when prompted as zimbra-talk is removed later during the upgrade process.
If you are currently on Zimbra V8.8.15 Patch 7, update all NG modules before upgrading to Zimbra 9.0.0.
Zimbra 9.0.0 introduces two versions of Zimbra Web Client — Modern and Classic.
A Zimbra Network Edition license is required to use the Modern Web App.
It is recommended that the Modern Web App is set as the default web client. Even after selecting a default, the Modern Web App and the Classic Web App can be used simultaneously by users as per their choice.
To know more about highlights of the Modern Web App, please refer to Introducing the Modern Web Application.
The Classic Web App offers the same functionality as the Advanced Web Client in Zimbra version 8.8.15.
The Modern Web App is actively under development, with some features not yet available. Refer to Email Features (e.g., Personas, System Distribution Lists, and Dumpster.
Briefcase cannot be used with Modern Web App. Though users may continue to use Briefcase with Classic Web App, it is recommended that existing users of Briefcase migrate to Zimbra Drive.
Existing customized themes, logo branding changes, and crontab changes are incompatible with, and hence do not reflect in the Modern Web App. Branding needs to be re-configured to work with the Modern Web App. The Modern Web App does not currently support themes. Please refer to the Customizing Modern Web App section of Admin Guide for more information related to configuration.
Currently supported languages in the application UI for the Modern Web App are - Chinese (China), English (US), French (France), German, Hindi, Indonesian, Italian, Japanese, Portuguese (Portugal), Spanish and Thai.
Zimlets are supported on both the Web Clients.
- Zimlets that work with Zimbra 8.8 will work with the Classic Web App; however, they are incompatible with the Modern Web App. Due to technology changes, there is no way to migrate the Zimlets from the Classic Web App to the Modern Web App or vice-versa.
- The Zimlets for Zimbra Drive, Zimbra Connect and Zimbra Docs are available for both web applications.

Be sure to read the release notes information before upgrading.

Database Integrity Checking

Some customers have had corrupted databases prior to upgrade, and the upgrade has in some of those cases exacerbated the problem. In order to detect any corrupted databases as early as possible, we have added an optional step to check the MariaDB database with zmdbintegrityreport prior to making any system changes. You are prompted to decide if you would like to run the zmdbintegrityreport.

zmdbintegrityreport can take minutes to an hour to run, depending on your system size and disk bandwidth.

zmdbintegrityreport is run on a weekly basis from cron on all zimbra-store nodes. Large sites can opt to disable this by setting zmlocalconfig -e zmdbintegrityreport_disabled=TRUE. If you choose to disable this, it is recommended that the integrity reports be run by hand during your normal maintenance windows and prior to running any Zimbra 9 upgrades.

Preparing your operating system

Before you upgrade, Zimbra recommends that the operating system is updated with the latest patches that have been tested with Zimbra Collaboration.

Ubuntu OS

Ubuntu 18.04 LTS Server Edition (64-bit)
Ubuntu 16.04 LTS Server Edition (64-bit)

Ubuntu 14.04 LTS Server Edition (64-bit)

If the original install was done with Ubuntu 12.04.2 or earlier, manual intervention is required to switch to the saucy (3.11) or later kernel series. See https://wiki.ubuntu.com/Kernel/LTSEnablementStack for further information.

You can find your current kernel version by running:

uname -a

For example:

build@zre-ubuntu12-64:~$ uname -a
Linux zre-ubuntu12-64 3.11.0-17-generic #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux/CentOS Linux

If running the RHEL linux distribution, you must have a current valid license from RedHat.
The server must have a valid yum or apt-get configuration so that it can reach the Zimbra package servers.

RedHat® Enterprise Linux® 7, AS/ES (64-bit)
CentOS Linux® 7 (64-bit)
Red Hat Enterprise Linux 6, AS/ES (64-bit), patch level 4 or later is required
CentOS Linux 6 (64-bit), patch level 4 or later is required

License Activation

At the beginning of an upgrade installation, the existing license is validated as being current and qualifies for the upgrade. If your license is expired, an error message displays and the upgrade cannot be performed. Contact Zimbra Sales for a license renewal to continue your upgrade.
An upgrade installation will not proceed without automatic activation or a manually activated license file. License activations are limited to five activations per license file. If you have previously used all activations prior to upgrading your production system, you must contact Zimbra Sales to enable additional license activations.

All Zimbra Collaboration 9.0.0 installations require a valid license and license activation. New installs will have a 10 day grace period from the license issue date before requiring activation.

License activation is automatic during the install with systems that have external access to the Zimbra license servers. A means of creating manual activations will be provided for systems that do not have external access to the Zimbra license servers. See the Zimbra Collaboration Administration Guide for more information.

When upgrading, the way in which ZCO and archiving licensing is enforced might have changed on the server if you are using an older version of Zimbra Collaboration. Older licenses might have MAPIConnectorAccountsLimit set to 0 or ArchivingAccountsLimit missing in the license. Contact Zimbra sales for an updated license file prior to upgrading if you have licensed either of these features and your current license does not properly reflect the correct number.

Upgrading LDAP Replica Servers or Multi-Master Server

These instructions apply to Zimbra Collaboration 8.0.0 and later.

If you have replica servers or are in multi-master mode, you have to install the Zimbra 9 LDAP schema specific to the release you are upgrading to onto the replica servers or onto the multi-master server before you upgrade to Zimbra Collaboration 8.0.4 and later. See Bug 81048.

On the master LDAP server, perform a software installation only of Zimbra Collaboration 8.0.4 and later.
```
./install.sh -s
```
On each replica or additional master LDAP server in MMR mode, as the zimbra user:
1. Stop the server via one of the following commands:
  1. ldap stop
  2. zmcontrol stop
2. Move the zimbra schema out of the way.
  cd /opt/zimbra/data/ldap/config/cn=config/cn=schema mv cn={4}zimbra.ldif /opt/zimbra/data/ldap/cn={4}zimbra.ldif.dead
3. Copy the schema from the master LDAP server.
  scp root@<master>:/opt/zimbra/common/etc/openldap/zimbra/schema/zimbra.ldif cn={4}zimbra.ldif
4. Edit cn={4}zimbra.ldif to change the following two lines:
  dn: cn=zimbra,cn=schema,cn=config -------> dn: cn={4}zimbra cn: zimbra -------> cn: {4}zimbra
5. Start the server via one of the following commands:
  1. ldap start
  2. zmcontrol start
On the master LDAP server run:
```
/opt/zimbra/libexec/zmsetup.pl
```
On each replica server run:
```
 ./install.sh
```
To continue the upgrade, see Multi-Server Environment Upgrade Steps.

Disable SSLv3 Support

If upgrading to Zimbra Collaboration 8.7.0 and above, you need to completely disable SSLv3 support after the upgrade. Disabling SSLv3 is recommended as a result of the SSLv3 vulnerability described in Alert (TA14-290A).

SSLv3 support has been deprecated by default in 8.6.0, although when upgrading from previous versions of Zimbra Collaboration, some protocols might still be enabled.

New keys created in Zimbra Collaboration 8.7.0 (or later) have SSLv3 disabled by default.
Pre-existing keys from earlier versions of Zimbra 9 will still have SSLv3 enabled.

Follow the steps in the Zimbra wiki article How to Disable SSLv3 to disable SSLv3 after upgrading to Zimbra Collaboration 8.7.0.

Update Default Proxy SSL Ciphers Attribute

Whenever upgrading, it is recommended that you check the values of the following attributes (zmprov gcf <attr>) and compare them with the current default values (zmprov desc -a <attr>).

zimbraReverseProxySSLCiphers
zimbraReverseProxySSLProtocols
zimbraSSLExcludeCipherSuites
zimbraMailboxdSSLProtocols

If you have not performed any recent hardening of your settings, your config should already match the Zimbra 9 default; and no action would be required.

In addition, it is recommended to make the following changes:

Remove the following from zimbraReverseProxySSLCiphers:
```
ECDHE-RSA-RC4-SHA
ECDHE-ECDSA-RC4-SHA
RC4-SHA
```
Add the following to zimbraReverseProxySSLCiphers:
```
!RC4
```
See https://wiki.zimbra.com/wiki/Cipher_suites for the most current information on cipher suite configuration.

Customizing ZCO Installations

Administrators who want to customize the ZCO installation MSI should use the unsigned version of the MSI (ZimbraConnectorOLK_n.n.n.nnnn_xnn-unsigned.msi), available in the Zimbra download directory. The modified MSI should then replace the standard signed MSI (ZimbraConnectorOLK_n.n.n.nnnn_xnn.msi) in order to be available to end users from /downloads/index.html and the ZCO auto-upgrade process. (Bug 85067).

Upgrade Instructions

Download the Software

Go to http://www.zimbra.com/downloads/zimbra-collaboration to access the downloads section.

Before you begin the upgrade, make sure you have a good backup for all users!
Database reloads are performed on 7.x to any 8.x upgrade.

When you run the install script and Zimbra 9 is already installed, a prompt appears asking if you want to upgrade. Follow the instructions in this release note to perform the upgrade. For additional information, refer to the installation guide.

Zimbra recommends that an install or upgrade session be run with a UNIX command such as screen to help prevent an install or upgrade session from terminating before it is completed. This is important when the upgrade includes restoring a configuration that has a large number of accounts.

Example command usage:

screen ./install.sh

Single Server Upgrade Steps

You do not need to stop the services before upgrading. The upgrade process automatically stops and starts the services as required for the upgrade.

Process

Log in as root to the Zimbra 9 server and cd to the directory where the Zimbra Collaboration 9.0.0 archive tar file is saved. For example, cd /var/tmp. Then type the following commands:
Unpack the file
tar xzvf zcs.tgz
Change to the correct directory.
cd <expanded-directory>
Begin the upgrade installation.
./install.sh
The upgrade script checks if proxy and memcached are present. If both are found, the upgrade will proceed. If either are missing then the upgrade will abort and alert.
From 8.7.0 onwards proxy and memcached are required.

See Enabling Zimbra Proxy and memcached
The Zimbra 9 software agreement appears in 2 parts. Read this software license agreement and type Y when prompted.
When Use Zimbra’s package repository [Y] appears, press Enter to continue. Your system will be configured to add the Zimbra packaging repository for yum or apt-get so it can install the Zimbra third party packages.
When Do you wish to upgrade? [Y] is displayed, press Enter to continue. The upgrade packages are unpacked.

Type Y when Install zimbra-connect [Y] appears.

zimbra-connect replaces zimbra-talk in Zimbra 9. However, to make this transition seamless it is important that you install zimbra-connect when prompted, as zimbra-talk is removed later during the installation.

The packages are listed. The installer also lists packages that are not installed. If you want to install the packages at this time, type Y; otherwise press Enter. The upgrade checks that there is enough space to perform the upgrade. If there is not enough space, the upgrade stops.
When The system will be modified. Continue? [N] is displayed, type Y and press Enter. The Zimbra 9 server is stopped, and the older packages are removed. The upgrade process verifies which version of Zimbra 9 is being run and proceeds to upgrade the services, restores the existing configuration files, and restarts the server. If you have a configuration with a large number of accounts created, this can take a while.
If you have not set the time zone, you will be asked to set it. This sets the time zone in the default COS. The time zone that should be entered is the time zone that the majority of users in the COS will be located in.
When the Configuration completes, press Enter.

Once all the MTA nodes are upgraded to Zimbra Collaboration 9.0.0, the following commands may be run to fix the default globalconfig values, if necessary.

zmprov mcf zimbraMtaCommandDirectory /opt/zimbra/common/sbin
zmprov mcf zimbraMtaDaemonDirectory /opt/zimbra/common/libexec
zmprov mcf zimbraMtaMailqPath /opt/zimbra/common/sbin/mailq
zmprov mcf zimbraMtaManpageDirectory /opt/zimbra/common/share/man
zmprov mcf zimbraMtaNewaliasesPath /opt/zimbra/common/sbin/newaliases
zmprov mcf zimbraMtaSendmailPath /opt/zimbra/common/sbin/sendmail

DSPAM is no longer shipped starting Zimbra Collaboration 8.7. Please enter the following commands to disable it.

zmprov ms `zmhostname` zimbraAmavisDSPAMEnabled FALSE
zmlocalconfig -e amavis_dspam_enabled=false
zmamavisdctl restart

It is recommended that you perform a full backup after a major upgrade, due to database schema changes.
For the next steps after the upgrade, refer to the section After the Upgrade is Complete.

Multi-Server Environment Upgrade Steps

Upgrade the servers in the following order. Update each server one at a time, following the instructions under Process below.

LDAP master server. The LDAP master servers must all be upgraded before proceeding, and they must be running as you upgrade the other servers.
LDAP replicas
MTA servers - see Using LMDB as the Supported Back-end for On-disk Database Maps.
Proxy servers
Mailstore servers

Process

Log in as root to the Zimbra 9 server and cd to the directory where the Zimbra Collaboration 9.0.0 archive tar file is saved. For example, cd /var/tmp. Then type the following commands:
Unpack the file
tar xzvf zcs.tgz
Change to the correct directory.
cd <expanded-directory>
Begin the upgrade installation.
./install.sh
The upgrade script checks if proxy and memcached are present. If both are found, the upgrade will proceed. If either are missing then the upgrade will abort and alert.
From 8.7.0 onwards proxy and memcached are required.

See Enabling Zimbra Proxy and memcached
The Zimbra 9 software agreement appears in 2 parts. Read this software license agreement and type Y when prompted.
When Use Zimbra’s package repository [Y] appears, press Enter to continue. Your system will be configured to add the Zimbra packaging repository for yum or apt-get so it can install the Zimbra third party packages.
When Do you wish to upgrade? [Y] is displayed, press Enter to continue. The upgrade packages are unpacked.

Type Y when Install zimbra-connect [Y] appears.

The packages are listed. The installer also lists packages that are not installed. If you want to install the packages at this time, type Y; otherwise press Enter. The upgrade checks that there is enough space to perform the upgrade. If there is not enough space, the upgrade stops.
When The system will be modified. Continue? [N] is displayed, type Y and press Enter. The Zimbra 9 server is stopped, and the older packages are removed. The upgrade process verifies which version of Zimbra 9 is being run and proceeds to upgrade the services, restores the existing configuration files, and restarts the server. If you have a configuration with a large number of accounts created, this can take a while.
If you have not set the time zone, you will be asked to set it. This sets the time zone in the default COS. The time zone that should be entered is the time zone that the majority of users in the COS will be located in.
When the Configuration completes, press Enter.

Once all the MTA nodes are upgraded to Zimbra Collaboration 9.0.0, the following commands may be run to fix the default globalconfig values, if necessary.

zmprov mcf zimbraMtaCommandDirectory /opt/zimbra/common/sbin
zmprov mcf zimbraMtaDaemonDirectory /opt/zimbra/common/libexec
zmprov mcf zimbraMtaMailqPath /opt/zimbra/common/sbin/mailq
zmprov mcf zimbraMtaManpageDirectory /opt/zimbra/common/share/man
zmprov mcf zimbraMtaNewaliasesPath /opt/zimbra/common/sbin/newaliases
zmprov mcf zimbraMtaSendmailPath /opt/zimbra/common/sbin/sendmail

DSPAM is no longer shipped starting Zimbra Collaboration 8.7. Please enter the following commands to disable it.

zmprov ms `zmhostname` zimbraAmavisDSPAMEnabled FALSE
zmlocalconfig -e amavis_dspam_enabled=false
zmamavisdctl restart

It is recommended that you perform a full backup after a major upgrade, due to database schema changes.
For the next steps after the upgrade, refer to the section After the Upgrade is Complete.

Using LMDB as the Supported Back-end for On-disk Database Maps

Starting with Zimbra Collaboration 8.5 and later, Postfix is linked to LMDB, the same back-end Zimbra 9 uses with OpenLDAP. Prior to Zimbra Collaboration 8.0, Postfix was linked to Berkeley DB.

Zimbra 9 has not officially supported using any Postfix on-disk database maps prior to Zimbra Collaboration 8.5. However, these have been used through custom non-preserved modifications to the postconf configuration. These modifications will be lost on upgrade.

To restore the modifications post-upgrade, the following steps need to be performed:

Run postmap against the database input file to generate an LMDB database.
It will be necessary to iterate through the postconf keys that have hash:/path/to/db values and update them in LDAP to use lmdb:/path/to/db values instead.

Many previously unsupported features that could be used with on-disk database maps are now fully supported by Zimbra 9. Check if your customizations are correctly carried forward when upgrading. See Bug 77586.

After the Upgrade is Complete

After you completed the upgrade, the following might need to be addressed.

Review How to disable SSLv3.
Review Cipher suites.
During the upgrade process, Zimbra 9 might make a binary backup of existing databases when there are major structural changes occurring to the database format for ease of downgrading. Administrators will want to clean these up once they have confirmed a successful upgrade. For LDAP servers, these backups are in /opt/zimbra/data/ldap, and in the form of <dbname>.prev.$$ where $$ is the process ID of the upgrade script. See Bug 81167.
You should run zmldapupgrade -b 66387 after upgrading. The zimbraAllowFromAddress attribute cannot be set for internal accounts or distribution lists. Running this script will change zimbraAllowFromAddress values to grants.
1. This step was not included into the installer-driven upgrade due to potentially long delay for sites that set zimbraAllowFromAddress on many accounts.
2. The migration command reports how many accounts had the zimbraAllowFromAddress attribute set and how many of them needed migration. One way to verify all accounts got migrated is to run the command again. The total won’t change, and the number migrated should be 0. See Bug 66387 for more information.
3. If your self-signed SSL certificates have expired, update them.
  To check for expired certificates, run the following command as the zimbra user:
  
  /opt/zimbra/libexec/zmcheckexpiredcerts -days 1 -verbose
  
  Zimbra Collaboration requires a valid self-signed or commercial SSL certificate for communication between some components. The self-signed certificates that are automatically created by the Zimbra 9 install have a default expiration.
  
  If you have a Zimbra Collaboration installation that is over one year old and are using self-signed certificates, your certificates will need to be updated either prior to the upgrade or immediately following the upgrade.
  
  After you upgrade, the following commands run as the zimbra user will regenerate the self-signed SSL certificates:
  
  sudo /opt/zimbra/bin/zmcertmgr createca -new sudo /opt/zimbra/bin/zmcertmgr deployca sudo /opt/zimbra/bin/zmcertmgr deploycrt self -new

If you were using zmlogger prior to Zimbra Collaboration 8.0.7, it is possible that numerous rdd files could be generated causing large amounts of disk space to be used. Zimbra Collaboration 8.0.7 and later contain a patch that prevents future additional growth of rdd files on the logger server. To clean up existing rdd files, use the following script. See Bug 85222.

sudo su - zimbra
zmloggerctl stop
cd /opt/zimbra/logger/db/data

for nhostid in $(sqlite3 /opt/zimbra/logger/db/data/logger.sqlitedb 'select id from hosts');do for ID in $(sqlite3 logger.sqlitedb "select rrd_file, col_name_19 from rrds Where csv_file == 'imap.csv' and host_id == ${nhostid}" | egrep "__[0-9]+$" | cut -d'|' -f1 | sort -n | uniq); do mv rrds/${nhostid}-$ID.rrd /opt/zimbra/logger/db/data/wrong_rrds/; done ; done

for mon in {1..12}; do MON=$(LANG=en_US; date +%b -d 2013-${mon}-01); sqlite3 logger.sqlitedb "DELETE FROM rrds WHERE col_name_19 LIKE '${MON}_%'"; done

sqlite3 logger.sqlitedb "VACUUM;"

zmloggerctl start
rm -R /opt/zimbra/logger/db/data/wrong_rrds
rm /opt/zimbra/logger/db/data/logger.sqlitedb.backup

If you have configured the following keys, you will need to replace them as described here.

The following keys are deprecated:

httpclient_client_connection_timeout
httpclient_connmgr_connection_timeout
httpclient_connmgr_idle_reaper_connection_timeout
httpclient_connmgr_idle_reaper_sleep_interval
httpclient_connmgr_keepalive_connections
httpclient_connmgr_max_host_connections
httpclient_connmgr_max_total_connections
httpclient_connmgr_so_timeout
httpclient_connmgr_tcp_nodelay

They are replaced by the following keys:

httpclient_internal_client_connection_timeout
httpclient_internal_connmgr_connection_timeout
httpclient_internal_connmgr_idle_reaper_connection_timeout
httpclient_internal_connmgr_idle_reaper_sleep_interval
httpclient_internal_connmgr_keepalive_connections
httpclient_internal_connmgr_max_host_connections
httpclient_internal_connmgr_max_total_connections
httpclient_internal_connmgr_so_timeout
httpclient_internal_connmgr_tcp_nodelay
httpclient_external_client_connection_timeout
httpclient_external_connmgr_connection_timeout
httpclient_external_connmgr_idle_reaper_connection_timeout
httpclient_external_connmgr_idle_reaper_sleep_interval
httpclient_external_connmgr_keepalive_connections
httpclient_external_connmgr_max_host_connections
httpclient_external_connmgr_max_total_connections
httpclient_external_connmgr_so_timeout
httpclient_external_connmgr_tcp_nodelay

Install/Upgrade Zimbra Drive NG

Performing these step installs/updates zimbra-docs as well.

As root run the below command:

RHEL

yum install zimbra-drive-ng

Ubuntu

apt-get install zimbra-drive-ng
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Installing Zimlets for Modern Web App

These five zimlets are available.

Slack
Zoom
Dropbox
Google Drive
Onedrive

You have to install and configure them for users to integrate and use these zimlets. Once you are done installing the zimlet(s), you need to restart the mailbox service before configuring them.

Slack

As root run the below command:

RHEL

yum install zimbra-zimlet-slack

Ubuntu

apt-get install zimbra-zimlet-slack
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Zoom

As root run the below command:

RHEL

yum install zimbra-zimlet-zoom

Ubuntu

apt-get install zimbra-zimlet-zoom
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Dropbox

As root run the below command:

RHEL

yum install zimbra-zimlet-dropbox

Ubuntu

apt-get install zimbra-zimlet-dropbox
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Google Drive

As root run the below command:

RHEL

yum install zimbra-zimlet-google-drive

Ubuntu

apt-get install zimbra-zimlet-google-drive
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Onedrive

As root run the below command:

RHEL

yum install zimbra-zimlet-onedrive

Ubuntu

apt-get install zimbra-zimlet-onedrive
Restart mailbox service as a zimbra user:

su - zimbra
zmmailboxdctl restart

Please visit Configuring Zimlets for Modern Web App for instructions for on how to configure zimlets for Modern Web App users.

Ephemeral Data Migration

Versions of Zimbra 9 prior to 9.0.0 stored ephemeral data in LDAP. Examples of ephemeral data include:

zimbraAuthTokens
zimbraCsrfTokenData
zimbraLastLogonTimestamp

Zimbra Collaboration version 9.0.0 introduced the ability to store ephemeral data in an external service such as SSDB. This is an optional feature; however, it can improve LDAP performance and stability.

Please refer to the Zimbra Collaboration Administration Guide for more information. Migration of ephemeral data out of LDAP and into SSDB must be performed after an install or upgrade has been completed.

Remove Current Version and Perform Clean Install of Zimbra 9

If you do not want to upgrade, but prefer to install Zimbra Collaboration 9.0.0 as a new installation, when you run the Zimbra Collaboration 9.0.0 install script, enter N when asked Do you wish to upgrade?

A warning displays asking if you want to delete all existing users and mail. If you enter Yes, all users, mail, and previous files are removed before proceeding with the new installation. Refer to the installation guides for installation instructions.

Status of Your Customization after Upgrade

Upgrading to the newest release does not delete your accounts or change your configuration. Configuration settings stored in LDAP and localconfig are preserved during upgrades. Any files installed by Zimbra Collaboration might be deprecated and/or overwritten during upgrades, removing any customizations. This includes customized themes, logo branding changes, and crontab changes.

Branding needs to be re-configured to work with the Modern Web App. And the Modern Web App currently does not support themes.

Only the core Zimlets are enabled after the upgrade. Zimlets that you customized and/or deployed are preserved during the upgrade but will be disabled. As upgrading of customized Zimlets cannot be tested before the release, Zimbra recommends that you verify that your customized Zimlets work correctly before re-enabling them for your end-users after the upgrade.

Zimlets are supported on both the Classic Web App and the Modern Web App. However, Zimlets used for Classic Web Client are not compatible with the Modern Web App. Currently, there is no way to migrate the zimlets from Classic to the Modern Web App or vice-versa. Existing zimlets need to be re-developed for them to work on the Modern Web App.

When upgrading to Zimbra Collaboration 8.5.x and later from a previous major Zimbra 9 version, the upgrade step disables Zimlets that are not the core Zimlets for Zimbra 9 in all COSs. If you have enabled other Zimlets at the account level, you might need to manually disable these Zimlets. See Bug 77836.

All entries between the designated comments in the Zimbra 9 crontab file are overwritten with new defaults upon upgrade. Customized backup schedules stored in the Zimbra 9 crontab and customizations to the crontab entry outside the designated comments are preserved.

Changes to Customized Themes

In Zimbra Collaboration 8.5.x and later, a new design for default skins was implemented. Custom skins created for Zimbra 9 7.x might not work as intended with Zimbra Collaboration 8.5.x and later. Depending on what is in the skin, the issues might range from simple things such as colors being used in the wrong places to larger issues like functional components being hidden or placed in inaccessible areas of the screen. The proper fix for this is to take an existing 8.5.x or later skin, duplicate it, and update the skin to meet the same needs as the old skin. See Bug 62523.