A ‘bit’ of history

Some of you might know me as a dedicated MS Exchange junkie. Ever since Microsoft launched version 5.0 of Exchange, I’ve been working with it and I must admit I never found a collaboration suite quite like it. I’ve had numerous discussions with Lotus Notes or Novell  Groupwise folks but they never conviced me (believe me, I tried all suites hands-on). And yes, I am aware of all the problems Exchange had in the past, including being a spamrelaying nuisance, a memory hog, a disk killer and so on (most errors were caused by faulty configurations, btw).

About 8 years ago some folks in, I think it was Germany, started a project with opensource software to create an Exchange equivalent with nothing but opensource software. Actually, it is pretty logical. If you strip down everything around Exchange, you are left with a (pretty ancient) database system (Jet), a webserver (IIS) and an SMTP engine. So, why can this not be done with MySQL, Apache and Sendmail or Postfix? It should be possible.

As I am also a fan of opensource software, I watched that project closely but it never really got around to being a proper alternative. After a company in Germany took over the initiative, I kind of lost interest. I’ve had dealings with this company before and frankly, I was pretty annoyed by their attitude towards opensource and people who are trying to help.

About 3 years ago, a colleague of mine pointed me to Zimbra. Back then Zimbra was just bought by Yahoo!. I kind of liked the idea of Zimbra but at that time it had one huge drawback for me: it did not support Outlook as a native client. Through Zimbra I found the other suite based on opensource software, called Zarafa. You could see Zarafa as the sequel to Exchange4Linux (which actually died a silent death back in 2007).

Zarafa supported Outlook as a native client through a small piece of software you had to deploy as a connector on Windows. I noticed that the same german company is developing and selling it throughout the world but it seemed to have changed it’s attitude towards opensource quite a bit. I tried Zarafa a few times but always ran into so many installation problems and version-problems on the various linux platforms, I soon stopped my efforts and decided to wait until the developers have matured the product.

Last year we attended a conference in Utrecht (Netherlands) about storage and the likes. VMware was there too, as well as Dell|Equallogic, which was the main reason we attended. Parallel to this there also was an opensource and tooling event. And guess what, there was a pretty large stand by Zarafa. So, I decided to give it another try. The idea was to use it as a messaging platform for our VMguru services. I got it to work but I still ran into some troubles and it could never quite convince me of being totally safe and waterproof. As is the case with almost all servers on the internet, we experience a big load of ‘security checks’ by friendly nations like the China on an hourly basis. With that in mind, I decided not to deploy Zarafa, also because the patch management is way to labor-intensive.

Then, at the beginning of 2010, VMware bought Zimbra and my interest in this product was renewed. Due to my work and private activities I did not get around to trying it out until about 4 weeks ago. One of my main issues with Zimbra, no Outlook support, actually isn’t that important any more. Today, I quite like the idea of not being dependent on some piece of client software and this is also the big trend in the market anyway (moving to a web-based clientsoftwareless solution for all classical client-server products).

 

Present day – where to start

So, I took a look at the Zimbra site and found out there are mainly three editions to choose from:

  • The open source edition
  • The appliance editon
  • The network editition

With my efforts in the past in mind (trying to build a linux server which never really succeeded) I decided to go with the appliance version. There were three bit reasons why I picked this one.

First of all, it comes running out of the ‘box’. No need to build a linux server which never quite suites the needs or where you have some versioning problems with the releases of opensource modules. As I’ve been down that path a few times before, I did not feel like getting frustrated by huge logfiles filled with errors I had to reverse-engineer one by one.

Second, it does mobile sync right from the start. As this might not have been one of the big reasons before, nowadays we almost all have mobile internet on our iphones, HTC’s and so on. An effortless implementation of mobile access would definitely be a big advantage. If we would not use it right away, we sure will in the future.

And last but not least, it does multidomain. This really is a big issue for me, as I use a few domainnames but I want to be able to have it do all of them at the same time and still have only one platform and one VM where all users interact with.

So the appliance edition was selected and the installation orgy starts. Well.. sort of..

 

‘Installing’ Zimbra

I decided to go with the OVF file. I imported the OVF file into our ESX server, which is hosted in a datacenter in Amsterdam. After waiting about 10 minutes, it told me it had 1% imported and the total process would take about 8 hours(!). As I did not find that pretty acceptable, I decided to download the OVF file and the VMDKs and install from the local system. This went slightly better. After several attempts the appliance finally was up and running.

Now, I am not really sure why this was such a hard thing to do. One thing I noticed is that the downloadserver from Zimbra really was a slow boy over here. Downloading the VMDK’s I never got a rate over 250 kilobytes per second. When you’re importing about 18 gigs of data, it really takes alot of time. Another thing is, it might also be the way OVF deployment works. I noticed that there is also some room for improvement there. Of course, if you deploy locally and not remotely like I did, you might not have (all of) these issues :).

The main thing however was, I got it imported and working. Now off to the most interesting part of the deployment; configuring it.

 

Configuring Zimbra

When importing it, you have to decide what resources you will give the appliance. Having no clue about the needs of Zimbra, I do have a pretty good idea about what resources a linux server generally needs. With that in mind and also the load we will be putting upon it, i decided to go with the general proposal by Zimbra when selecting the ‘TRIAL’ configuration which will select 1 vCPU and 2 gigs of RAM.

After booting the VM, you are required to do some initial things like accepting the license agreement, enter your administrative password and so on. After that, you can login to the console to configure the basic networking settings like IP, subnet, default gateway, hostname and proxy. The login name for your console is not admin, root or the likes. It’s ‘vmware’. During the initial deployment you had to enter an administrative password. This is the spot to enter it.

For us there was a big heads-up here when choosing the hostname and I guess it is for most of you out there. When you enter it, please keep in mind that you enter the LOCAL domain and NOT the maildomain (internet domain) you want to host, unless it is the same as your local domain. If you do not, the result is that message routing will try to resolve the hostname and end up with the external IP where you have to open up all kinds of ports on your firewall to make internal and external messagerouting possible.

To be honest, I screwed up here on the first deployment and I didn’t notice until I was halfway in the final config. As I was not able to change the root domain to the internal domain which was not configured at all. I still gave it a try, after which Zimbra gave me a dirty errormessage, kicked me out of all webconsoles and would not let me back in at all. Even the systemconsole could not give me a quick save. I decided to go for a redeployment as I wanted to write this article with a proper deployment in mind, not a screwed-up one I had then.

After this you can login to the web console at the configured address using SSL and port 5480. Enter username ‘vmware’ and your administrative password and you are presented with a very nice administrative interface, as you can see below.

So, a few things have to be done after you go through the initial steps in the webconsole and before you actually can start creating or importing users. I noticed that you really should to do them before you do anything else.

First, click through the serveroptions. Make sure the relaying mailserver settings are correct if you have them. Second, check the default profile that is created by the system. Initially, it does not allow the users to use mobile access. If you want to, you can create more profiles where you differ between the services you want to offer to your usercommunity. Third, check your license. Initially, it will run with a 60 day trial but you should enter a valid one as soon as possible. VMware offers a FREE 10 user license which includes mobile usage.

After that, you can enter your domain and start creating users.

 

The pain of migrating

The next part is just a local problem but there are some lessons to be learned here. We here at VMguru did not have a general mailsystem used by all members. The mailhostingsystem actually is a pop3/imap server where everyone picks up their messages. Most of us are on Gmail, but those are all accounts used for other purposes too. So, the migrator assistant which comes with Zimbra unfortunately cannot help us here. However, when you log into Zimbra, you have the possibility to enter an external account, like Gmail, to collect your content and move it to the Zimbra inbox.

While I was doing that, I ran into the problem that Zimbra turned unresponsive. When I tried to access the webconsole, the server gave no response. When opening the serverconsole within the vSphere client, I was presented a pretty ‘OOM’ (OutOfMemory) error and totally no way to log in. When looking at the stats of the VM, I noticed that when I was happily configuring my personal inbox, Zimbra was not amused by my ways of i.e. entering an external account and quickly ran through the supplied 2 gigs of RAM like it was nothing. I also noticed that the vCPU had a hard time keeping up. Seeing this, I decided to change the configuration of the VM to 2 vCPUs with 4 gigs of RAM. I also installed the clientsoftware for our monitoring system so I could keep a close look on the resource usage within the VM without logging into vSphere all the time.

After booting up with the new settings, Zimbra seemed to be more responsive. I tried to enter the external account settings for Gmail again and I decided to use POP3 to enter the messages into my new Zimbra inbox. This was a HUGE mistake. My Gmail inbox contains about 2.1 gigs of messages. Using POP3, ALL of these messages were dated TODAY and marked as UNREAD. Not a great idea. So quickly killed this external account and tried the IMAP version. This works quite like every other IMAP connection. You see your mail folders within your webclient and you can read, mark, drag and drop your messages. However.. after about 5 minutes, Zimbra puked an errormessage about some networksettings, directly followed by another errormessage where Zimbra tells you it could not execute the FETCH command for your gmail account. And that’s the end of it. I was not able to convince it to work properly.

 

Conclusion

No, it’s not all bad. On the contrary. I am very charmed by the user interface and the completeness of the webclient interface. You can drag and drop images, messages, files, contacts. You can share calendars, mailboxes, addressbooks and files with your fellow Zimbra users. You can access it mobile, you can access it from Firefox, Safari, Internet Explorer and it all looks the same. In fact, based on that, I decided to make Zimbra my day-to-day mailclient instead of Gmail.

There are some drawbacks. Like it’s Microsoft nephew Exchange, Zimbra is a memoryhog. With 8 users configured it now eats away about 74% of the 4 gigs of RAM provided. And this is without a big userload. Also, the AJAX JAVA interface loves your CPU power. Serverside as well as clientside.

In fact, my Safari browser went up to 514mb of RAM on my Macbook pro while I was copying mails from my Gmail to my Zimbra inbox, mainly because of the JAVA engine. On the other hand.. how much RAM does your Outlook eat? And your Exchange 2010 server?

So, my conclusion is this:

Yes, there are some things that need improving. Being able to configure external accounts is a big plus, but it would be so nice if it would really work. The initial configuration TRIAL can actually be skipped because it will only fit if you want to try with 1 user without ANY email history.

The interface is beautiful, works like a charm, looks uniform on all browsers, supports drag-and-drop, sharing mailboxes, calendars and files. You can view almost all attachments without any problems (I tried .doc, .jpg, .pdf and .xml). From an administrative point of view it’s pretty easy to configure. Read through the manual, it really isn’t that big a hurdle and start using the server. After I properly planned what I wanted Zimbra to do, it was up and running within 2 hours. Try that with an Exchange server.

I like Zimbra. In my opinion, it’s the first opensource based collaboration suite that really brings what you want without the need of your admin to have a huge understanding of linux and the likes (though it does help if he does..).