Zimbra is designed for a dedicated server. It brings all packages like apache, ldap, mysql which means that it might proove difficult to add any other webservice to the zimbra-apache or something like this.

It means that zimbra should run on its own server where nothing else runs.

Install-process seems critical. If something fails or if you got interrupted, you should start all over again by purging all zimbra-packages and rm -rf /opt/zimbra.

The usual zimbra-install-process goes on for a while and then ends in the config-menu. After you set the adminpassword and the serverclass you can apply the settings with “a” and thats it.

please be very careful when cloning or moving zimbra !! the new zimbra can easily mess up your old zimbra cause it knows its hostname and its passwords. Be sure to read the section about moving zimbra on this page!!!

https://zimbraserver:7071/zimbraAdmin

all this must be run as zimbra-user !!

• zmcontrol status
• zmcontrol stop
• zmcontrol start
• zmcontrol maintance

used for provisioning

zmprov help command | less

will give you a list of available commands like creating domains and users.

this is for modifying mailboxes

zmmailbox help commands|less

zmmailbox -m peter -z gfrl 
"bikekitchen" active all header "subject" contains "[BikeKitschen]" fileinto "_projects/bike/BikeKitschXXn" stop

zmprov ca USER@ZIMBADOMAIN.COM PASSWORD displayName 'MY NAME' givenName NAME sn NAME zimbraMailCanonicalAddress MYEMAIL zimbraPrefFromAddress MYEMAIL

you can pipe scripts like the following directely to zmprov

createAccount andy@domain.com password displayName 'Andy Anderson' givenName Andy sn Anderson
createAccount betty@domain.com password displayName 'Betty Brown' givenName Betty sn Brown

NOTE to get a list of all attributes to a certain user and therefore a list of all available attributes you can perform “zmprov ga USER” as described in next chapter.

zmprov ga USER

zmprov gaa 
zmprov -l gaa    ... for  zimbra 6.x

zmprov setPassword NAME PASS

This will get you all mailboxes to a certain user:

zmmailbox -z -m USER@DOMAIN.COM gaf

This will delete a certain mailbox:

zmmailbox -z -m USER@DOMAIN.COM df SUB/LINUX/WINDOWS/GEEK

zmmsgtrace -i 3836172.14011130514432170
zmmsgtrace -s user@example.com 
zmmsgtrace -r user2@example2.com -t 20051105

• -s ... sender
• -r ... recipient
• -t ... time
• -i ... message_id

To increase the maximum mailsize from 10M to 50M, execute the following:

zmprov mcf zimbraFileUploadMaxSize 50000000

and check if proper set

zmprov gacf zimbraFileUploadMaxSize

 zmprov ma peter zimbraPrefMailItemsPerPage 500

as zimbra-user:

$zmprov mcf zimbraMtaRelayHost SMTP.HOST.COM
$zmprov gacf zimbraMtaRelayHost 
zimbraMtaRelayHost: SMTP.HOST.COM
$zimbra@zimbra:/data$ postconf -e smtp_use_tls=yes
$ postfix reload
postfix/postfix-script: refreshing the Postfix mail system

If a user has different personalities or external accounts and sends an email choosing one of these in the “FROM”-dropdown, the “real” identity of this user is still used in the SMTP-From command and therefore visible in the return-path of the mail header. Thats annoying in many cases and cannot be changed via GUI but with the following command:

zmprov ma user@domain zimbraSmtpRestrictEnvelopeFrom FALSE

and check with

zmprov ga user@domain | grep zimbraSmtpRestrictEnvelopeFrom

or set it on COS-level for all users in this COS. (exectute zmprov gac to get a list of all COS on your system. Mostly it will be “default”)

zmprov mc COS-NAME zimbraSmtpRestrictEnvelopeFrom FALSE

and check with

zmprov gc COS-NAME | grep zimbraSmtpRestrictEnvelopeFrom

if you set on COS-level this will apply to all users.

Further discussions of this can be found at:
https://bugzilla.zimbra.com/show_bug.cgi?id=51240
https://bugzilla.zimbra.com/show_bug.cgi?id=40731

If your emails are not sent to zimbra directly but to a different mailgate and then forwarded to zimbra via SMTP or LMTP then OOO is not working (at least up to version 7.3 altough changes are planned) because zimbra does not recognize the To-Adress and considers the email not worth OOO-replying.

Solution is to set the following for each account and each emailadress this account has:

zmprov ma USER-ID@zimbra.domain.com zimbraPrefOutOfOfficeReplyEnabled TRUE
zmprov ma USER-ID@zimbra.domain.com +zimbraPrefOutOfOfficeDirectAddress
adress1@domain.com
zmprov ma USER-ID@zimbra.domain.com +zimbraPrefOutOfOfficeDirectAddress
adress2@domain.com

Then check if everything worked as planned using:

$zmprov ga USER-ID@zimbra.domain.com | grep OutOfOffice
zimbraFeatureOutOfOfficeReplyEnabled: TRUE
zimbraPrefOutOfOfficeCacheDuration: 7d
zimbraPrefOutOfOfficeDirectAddress: adress1@domain.com
zimbraPrefOutOfOfficeDirectAddress: adress2@domain.com
zimbraPrefOutOfOfficeFromDate: 20120119230000Z
zimbraPrefOutOfOfficeReply: ** autoreply OOO test**
zimbraPrefOutOfOfficeReplyEnabled: TRUE
zimbraPrefOutOfOfficeUntilDate: 20120202230000Z

If you check your mailbox.log (in /opt/zimbra/logs) you’ll find the following line if OOO is not working:

Mailbox - outofoffice not sent (not direct)

Please note that after applying the above you should restart zimbra or wait some time until changes sink in.

When you set up external accounts these are not queried automatically but you have to manually load them. This is very annoying. Note that the poll-time you set up in preferences does nothing have to do with external accounts.

There is a setting to do what we want but its not accessible via GUI. Reason seems to be that this polling is done regardless if the user is logged in or not and so if many users have many external accounts and a short poll-intervall this can put heavy load on the server.
(My guess is that the polling-code is not so perfect yet to include the setting in the official GUI but this might change in coming Zimbra7)

Ok : You first have to enable the setting for your COS (ClassOfService) which could mean:

zmprov mc default zimbraDataSourcePollingInterval 10m
zmprov mc ANOTHERCOS zimbraDataSourcePollingInterval 10m

This is important. It does not mean that all users will have a poll-interval of 10minutes on external sources now, but it means that if users have set a poll-interval that it will work. I dont know if this COS-value is automatically passed to new users.

Second you have to enable it for all external accounts for all users. There are scripts to do that, but they didnt work for me. So I did it by hand for the handful of users that brought this issue to my attention, but writing a script should be very easy

zmprov gds USERNAME
This will list all external accounts. zimbraDataSourceName is what we want for each account. Because then we can do the following:

zmprov mds USERNAME DATASOURCENAME zimbraDataSourcePollingInterval 300

300 seconds is 5 Minutes and remember : you have to run zmprov mds for every external account on every user !!

We set 10m on COS-level and 5m on user-level. I dont have any glue which one will apply at the end. Sorry.

People recommenden using zimbraDataSourceID instead of zimbraDataSourceName in case you have unusual chars in your zimbraDataSourceName, but this didnt work for me, but enclosing the name in simple “hyphs” worked well.

When you want to move your zimbra or clone it be very careful. Zimbra accesses all its services (especially ldap) via its hostname/publicIP.

So when you move your zimbra (ie. with rsync) and fire it up then the new zimbra still will partially access your old zimbra and mess things up. It happened to me and I had to revert to backup. zimbra is a difficult customer.

If you want to move your zimbra without changing hostname, just stop zimbra, rsync it to your new location, move ip and hostname and fire it up on the new server.

Here is a setup for cloning your zimbra-server, so you will have two running copies with different hostnames after:

1. shut down backup-zimbra if there is already a running clone
2. rsync your original zimbra to your backup-zimbra
3. shut down original zimbra
4. rsync again to get a consistant clone
5. fire up the original zimbra to have minimal downtime
6. edit /etc/hosts on clone-server and set original server name to clone ip. So your clone-zimbra cannot talk with your original zimbra. This is mandatory and really important. To increase safety, you could additionally implement a firewall or have the original zimbra down during the next steps, but this will increase downtime of your original zimbra-server, so I just block communication via /etc/hosts and its prooven enough till now.
7. start your clone-zimbra
8. change hostname on clone zimbra : /opt/zimbra/libexec/zmsetservername -n <newservername>
9. start your clone-zimbra again cause previous step will shut it down.
10. remove the entry in /etc/hosts altough I keep it in there cause I use alternate hostnames to communicate between this servers anyway and there is not much communication beside the rsync that I initate from the original server and not from the clone-server.

note that if zmsetservername or starting zimbra later fails with strange ldap-errors, you might look on which interface slapd is actually listening during the zmsetservername and if the new name actually points to this adress. slapd only binds to the “main-interface” and zmsetservername tries to reach ldap with its new name and if this does not match you will end up screwed. In that case its best to resync and do it again with fixed DNS.

Zimbra is a container that provides all you need and you dont need to know how things exactely work in the inside. Thats very convinient ... until things start breaking and you dont have a clue how to fix it.

Zimbra provides loads of log-files in /opt/zimbra/log - However one must never forget to look into /var/log/syslog - This is where the main-stuff comes together. Especially the output of the very initial zimbra-start-command. (zimbra is started on your machine via the standard linux rc-structure : /etc/init.d/zimbra start)

However zimbra-logging is a mess in my eyes cause there is no central point where to increase log-levels. To increase the log-level of zimbra-ldap to log connections for debugging-purpose you have to run:

zmlocalconfig -e ldap_common_loglevel=16896
see man slapd for the meanings of this value. Restarting ldap is not required. After a few minutes ldap starts logging to /var/log/zimbra although there are reports that it goes to /var/log/debug ... You’ll find out :)

remember : zimbra includes ldap, mysql, apache ... - which means that your system must not have any of these installed cause otherwise the mysql of your system will bind to the standard mysql-port and your zimbra-mysql will fail to start or work proper.

So check if there is any other service running that might block your zimbra-services. Especially on modern linuxes (like ubuntu) some packages turn up unexpectedly. On my ubuntu 8.04 mysql and postfix seemed to have instelled “themselfes” when I installed a minor package.
Note: semi-gurus can of course install a mysql on their system and binding to a different port. Normal users will not want to do this.

as zimbra-user you can use zmcontrol as described above, but never forget the mainswitch which is operated as root : /etc/init.d/zimbra start/stop

starting zimbra - especially after a hard shutdown - will take several minutes. Thats fine, but dont be unpatient. Check the logfiles (again mainly syslog) to see if there is still activity going on.

When your zimbra does not start by itself after booting and you cant get it going by starting/stopping ....
Maybe even running zmcontrol status gives a timeout and in syslog you find irriating lines like:

May  5 09:15:03 zimbra zimbramon[7310]: 7310:info: zmstatuslog timeout after 60 seconds

Then try doing it the hard way:

• as zimbra user : zmcontrol stop
• as root : /etc/init.d/zimbra stop
• now look on your system what is still running. ps waux is the tool you might want to use. Find all zimbra-related processes still running and kill them. But especially find all processes that does not belong to zimbra but might interfere like processes with suspious names like ..sql.. ...www... ...ldap... ...mail... ...post... ...apache... ...web... - you get the idea. find them - kill them and make sure they will never start again.
• now start zimbra /etc/init.d/zimbra start and be patient. Starting zimbra will take minutes. Watch the logfiles.

This is a complicated thing and there seems to be more aspects and therefore solutions to this problem

Host  abc.def.com
        antispam                Running
        antivirus               Running
        ldap                    Running
        logger                  Stopped
                zmlogswatchctl is not running
        mailbox                 Running
        mta                     Running
        snmp                    Stopped
                zmswatch is not running.
        spell                   Running
        stats                   Running
        zmconfigd               Running

I had this problem quite frequently until I found the (or at least one) solution. This two services were not running but zimbra seemed to be working fine and after a few hours the services started running by itself. I could easily start them before when doing a “zmcontrol restart” or “zmlogswatchctl start” and “zmswatchctl start” as zimbra.

It took me a while to discover that this problem occured after I restarted zimbra via a cron-job (root) using the following command:

su -c ‘zmcontrol restart’ zimbra
and that the problem did not occure when using:
su -lc ‘zmcontrol restart’ zimbra
so simple. Some environment-variables seems to be very important here. Didnt take the time to find out which.

You can easily reproduce the problem by running the following commands as root:

su -c '/opt/zimbra/bin/zmlogswatchctl stop' zimbra
su -c '/opt/zimbra/bin/zmlogswatchctl start' zimbra
su -lc '/opt/zimbra/bin/zmlogswatchctl start' zimbra

You will find that the first attempt to start logswatchctl-service will fail and the second will suceed :)

As from 6.x in the zimbra-admin-interface you can easily create a new self-signed certificate and overwrite the old one. This step is recommended anyway after a fresh installation cause you can enter your local information while zimbra defaults to country=US and knows nothing about your companies name ...

after upgrading my zimbra-server (zimbra 6.0.10) from Ubuntu 8.04LTS64 to 10.04LTS64 zimbra was running extremely unstable and had to be restarted every few hours cause mail-delivery to zimbra MTA via lmtp started failing and users got these strange errors in the webinterface or could not connect via imap. I drove me mad until I found the solution.

bugreport including the fix : http://bugzilla.zimbra.com/show_bug.cgi?id=42870
The errors always contain something like this:

• com.zimbra.common.service.ServiceException: system failure: ZimbraLdapContext
• java.net.SocketException: Bad file descriptor

Of course a filesystem-check is always recommenden if one faces “Bad file desciptors”, but FS was clear.

So I mad to changes to my system. First I increased some kernel-limits (reboot after editing the file):

/etc/security/limits.conf:

root soft nofile 1048576
root hard nofile 1048576
zimbra soft nofile 1048576
zimbra hard nofile 1048576

I think on performant servers with high zimbra-load you could even increase this values.


Additionally I increased the timeout-values for zimbra by running the following as zimbra

zmlocalconfig -e ldap_read_timeout=300000

and the other values listed below:

ldap_common_writetimeout = 0
ldap_connect_pool_timeout = 120000
ldap_connect_timeout = 300000
ldap_read_timeout = 300000

Then you have to restart zimbra or at least the zimbra-ldap

Zimbra stores its files - at least its mails - on the harddisk, but the “where” is stored in the mysql.

A detailed explanation about the structure of mail-storage can be found at : http://wiki.zimbra.com/index.php?title=Account_mailbox_database_structure