Written by IT News on 11:01 PM
he collaboration space is getting crowded these days, with various products offering Exchange-like functionality and a few enticing extras. Among the available solutions is Zimbra, which provides a collaboration server that runs on Linux. Find out what Justin James discovered when he installed Zimbra and put it through its paces.
This article is also available as a PDF download. For a detailed comparison of Exchange vs. Zimbra costs, check out this worksheet.
It seems like a lot of new players are entering the "collaboration server" space lately. In a nutshell, these servers try to contain much, if not all, of the functionality of Microsoft Exchange Server, which is the baseline product in this market. Some of them introduce new features and functionality as well.
Along with the already established Scalix (TechRepublic's review of Scalix can be found here), Zimbra is entering the space with a collaboration server that runs on Linux. Like Scalix, Zimbra comes in a range of editions, from the open source Community Edition through to the Network Professional Edition at the high end. To get the Exchange/MAPI functionality, your only Zimbra choice is the Network Professional Edition. The only difference between this edition and the next lower version is the Exchange/MAPI capability.
Zimbra brings all of the usual collaboration server features to the table: SMTP MTA, a Web client, POP3 and IMAP servers, calendaring, and address books. It also brings into the mix a document sharing system (similar to a wiki).
System requirements, installation, and documentation
The system requirements to install Zimbra are not too hefty: 1 GB of RAM, 5 GB of drive space, and one of the supported Linux distributions (RedHat Enterprise Linux, Fedora, SuSE Enterprise Linux, openSUSE, or Ubuntu) or Mac OS X 10.4.7. Oddly enough, BSD is not supported, even though Mac OS X, which is based upon BSD, is supported. Hopefully this will change, as BSD is much more prevalent in the server room than Mac OS X. Also of note is that clustering is not supported under SuSE Linux. For the purpose of this article, I used openSUSE.
Installation should have been pretty simple, but it was not. The documentation is dominated by RedHat Enterprise Linux, with a fair amount of information about installing Zimbra on Mac OS X as well. To be fair, RedHat is a Zimbra partner. Speaking with Zimbra, it took a poll of its users to determine what OSes and distros to support, and what it supports is what its users asked them to support.
From what I saw of the RedHat instructions, a default RedHat installation will definitely not work, including the amount of space available in the root directory. This could be a sticking point for someone looking to add Zimbra to an existing server. SuSE Linux was barely mentioned in the documentation. The documentation did provide a list of dependencies, which were not far off from what was installed with openSUSE by default. One bizarre gotcha was that Zimbra requires fetchmail to be installed and Postfix to be disabled. However, Postfix is a prerequisite for fetchmail. It did work, but it was rather odd.
Following the installation directions on openSUSE was an abject disaster. The system did not work, plain and simple. The installer complained that I was using a system other than the one it was built for, despite using the openSUZE 10 link on Zimbra's Web site. I wiped the openSUSE installation twice and retried, and it still would not install. Before I tried a third time, I went to the Zimbra site hoping to find some other source of help, since the directions obviously did not apply to openSUSE. In the Zimbra forum, I found a post with full, complete, and accurate installation directions, which worked like a charm.
Another real pain point was that the Zimbra log was created but completely empty. I was ready to roll up my sleeves and start troubleshooting, but the lack of logging stopped me dead in my tracks. In fact, one of the corrections to the installation that the forum post contained was to get the logging to work correctly. Even after these difficulties, the installer did not even ask for an admin password or the location of the license file, two items that are needed to install the system. These pieces of information had to be provided through a menu system, and it is up to you to read the manual or wade through the menus to figure out where to provide this information.
One other disappointment was a post in the same thread by a Zimbra employee stating the openSUSE was not supported. This was in direct contradiction to the information on Zimbra's Web site. I found it to be quite disturbing to see this difference in supported OSes. I was also surprised that while these excellent directions were on the Zimbra forum for some time, nothing similar had been put into the Zimbra installation guide. In contrast with Exchange or Scalix, Zimbra definitely scored quite poorly in the installation department.
Another point that stuck with me is that Zimbra uses its own Tomcat, MySQL, and JDK installations. I have never liked systems that did this. One of the outstanding advantages of the GNU/Linux platform is that its modularized structure allows systems administrators to swap components with equivalents as needed. Using its own Tomcat, MySQL, and JDK installations not only removes this flexibility, but it also takes those components out of the system administrator's patch cycle. Additionally, an organization unfamiliar with these components will be in trouble if it ever needs to do any deep diving on problems. Zimbra does allow three authentication options: Internal (using Zimbra's own system), LDAP, and Active Directory, which restores a small portion of modularity to the system.
Overall, the Zimbra documentation was not of the caliber I have come to expect from enterprise class software. All too often, the directions assumed a level of Linux knowledge that not every system administrator has. The directions were definitely not step-by-step or the "Type this and click that" variety; they were more along the lines of "Go do this and provide this command-line argument." The instructions and documentation were so lackluster, it was up to me to figure out that the Web client could be reached by pointing the browser at the IP address or hostname of the server, and that no port number or directory was needed. I could not find anywhere in the manuals a section that contained this basic information. The manuals did, however, have the URL to the Administration Console. All too often, the "documentation" simply described what items were in part of the system but not how or why you would use them.
Administration and backend features
Administration of Zimbra was easy enough. The Web client did most of the common functions. One obvious hole was that while periodic backups were configured out of the box and ad hoc backups could be run through the Administration Console (Figure A), a command-line program was needed to edit the schedule of the periodic backups. On the flip side, management of storage space and data store volumes (Figure B) was quite easy and well done.
Figure A
Figure B
Additionally, Zimbra supports the restoration of even a single mailbox, without the need to take the server or storage group offline as with Exchange. That is a real benefit that many e-mail administrators will appreciate. The storage system supports functionality such as storing an attachment only once if it was sent to multiple users in the same e-mail; this can significantly reduce storage costs. It also supports many more storage volumes per server than Exchange does, allowing for much more granular control over storage usage.
There was nothing particularly wrong with the Administration Console, but it was not particularly amazing either. It was definitely functional. This is a good thing in an administration system, though; better to have a pleasant experience with no surprises than one filled with adventure. This may be a result of Zimbra's relatively simple configuration compared to Exchange. Everything worked as expected, and there really were no surprises at all, good or bad.
What was most noticeable about the Administration Console is just how few items were available to configure. Experienced Exchange administrators know that the management of it is quite in depth. Zimbra's administration was rather sparse. One quirk of the system was that some pages needed to scroll vertically but presented no vertical scrollbar. This made it hard to notice additional options or configuration settings in some areas.
One item that was quite disappointing was the lack of facility to provide a new SSL certificate. Zimbra created a self-signed certificate. But nowhere in the documentation or the Administration Console did I find a way to use a third-party SSL certificate. This means that if you want to use a third-party signed SSL certificate, you need to hack up the custom Tomcat installation, as far as I could see. Again, this brings up the issue of Zimbra having its own Tomcat installation instead of allowing the system administrators to build upon their own existing systems or preferred configurations.
Zimbra uses the standard ClamAV to handle the antivirus duties and equally standard SpamAssassin for anti-spam chores. Sadly, the Administration System declaws both of these excellent systems. As you can see in Figure C, the highly flexible and configurable ClamAV and SpamAssassin have been reduced to a mere six configuration values. While this may be nice for someone who has no intention of ever really performing in-depth configuration of these items, it is highly unsuitable for an enterprise. It may of course be possible to make changes that are more precise through the configuration files directly. In addition, it is important to note that Zimbra at least comes with antivirus and anti-spam utilities; for Exchange, third-party software or hardware is required, which usually costs a fair amount of money.
Figure C
Connecting to Zimbra
Zimbra really pushes its Web client (Figure D). The system has e-mail (Figure E), calendaring (Figure F), an address book, and a Documents system (Figure G). As you can see in Figure D, the Documents system is marked as "beta." Some of the features that Outlook and Outlook Web Access users have come to expect are missing here: tasks, notes, and Public Folders. (Public Folders have been removed from Exchange 2007, though.) The Documents system might be able to function like Public Folders, but right now it is essentially a basic wiki.
Figure D
Figure E
Figure F
Figure G
As you can also see, the Zimbra Web client does support themes, although I found that the only theme that rated above bland was the Steel theme you see in many of these screenshots. (The default theme, Sand, appears in the Administration Console screenshots.) About half of the installed themes are downright ugly, and most of them are rather lacking in usability, thanks to vague icons.
The Zimbra Web client does have some functionality that Outlook Web Access (OWA) lacks and that would require Outlook to use. As a result, Zimbra positions itself as being less expense than Exchange, because it pushes the idea that unlike Exchange, a separate Outlook license is not needed. This may be a fair comparison. Zimbra's search is much more robust than the search in OWA or Outlook, for example. Zimbra also allows sharing of address books, calendars, and so on, whereas Outlook is needed for much of this functionality on the Exchange platform. The Web client is also capable of rendering more than 200 file types in HTML, a pretty impressive feat that can be rather nice.
The basic functionality seemed to work fine. One item of note is that the error messages can be strange. While Zimbra is working on a client that supports working offline (the client is currently in public alpha, so I didn't test it), trying to send an e-mail while disconnected from the network threw off a rather useless error message (Figure H). This was a rather low moment in my mind; Zimbra recognizes the "offline problem" enough to work on a client that can handle it but does not provide error messages in its existing software that handles it well. I can't imagine the frustration that a user with little technical skills would experience seeing an error message like this.
Figure H
The Web client is capable of not just the basics of sending e-mail, but can also be extended through "Zimlets." This is supposed to be one of the shining stars of Zimbra. However, the Zimlet Gallery is extremely lightweight and contains nothing to make up for the lack of features in the Web client. The documentation for the Zimlets is lacking as well (much like the rest of Zimbra's documentation), which may explain the absence of any quality Zimlets.
Compared to the well-documented API hooks into Exchange and the equally well-documented REST APIs that Scalix exposes, Zimbra offers few options in terms of extensibility. That being said, Zimbra demoed some extremely cool Zimlets to me. With some elbow grease, a company can put together a collection of Zimlets that integrate the Web client directly to its unique workflow in a way that can be a real productivity enhancement. I believe that a company that invests the time and effort into developing its own Zimlets will end up with a solution that can potentially be better than Exchange + Outlook for its needs and show real ROI. But again, it will be work to do it, and it requires an IT department that views e-mail as an opportunity to increase productivity, not merely a necessary evil.
Overall, the Zimbra Web client more than meets the needs of all but the few Outlook power users out there. Zimbra's roadmap for the client is also quite promising. I believe that the Zimbra Web client could definitely replace Outlook for users who are rarely disconnected from the network, and Zimbra is working to address those users as well.
Connecting to Zimbra from a POP3 and IMAP client worked as expected. As a nice touch, it does support SSL for POP3 and IMAP. Unfortunately, a separate installation of the Zimbra Connector for Outlook is needed to connect Outlook to Zimbra with the same functionality that Outlook has when it connects to Exchange. While the connector works fine, it is a shame that an additional desktop installation is needed. On the other hand, Zimbra believes that the real goodies are in its Web client, which is rushing toward Outlook parity. Indeed, Zimbra currently has a system in alpha release status that allows the Web client to be used offline. Although I didn't test this system (reviewing alpha products can be unfair), the demo that Zimbra provided showed it to be at least as swift and powerful as Outlook working with local PST files.
Pricing
Zimbra, like Scalix, bills itself as an open source solution. Like Scalix, the open source end of Zimbra extends only to basic functionality. For the full functionality that comes closest (but misses) the Exchange standard, you need to purchase Zimbra's Network Professional Edition. This edition is priced in blocks of 25 users, at $35 per user per year for the first 25 users and $28 per user per year for each additional block of 25 users.
Table A shows a brief comparison between the costs for Microsoft Exchange and Zimbra. One thing in Zimbra's favor is that there are deep discounts for certain customers, such as education institutes, government agencies, and nonprofit organizations. However, as the table shows, the cost of Zimbra's yearly licenses can get very steep very quickly. Zimbra's license does include free upgrades and patches on a yearly per-users basis, but it is much more expensive than Exchange unless you buy Exchange and then decide to upgrade it to a newer version soon after.
Table A
| | Total Cost - 1 Year | Total Cost - 3 Years | Total Cost - 5 Years |
| # of Clients | Exchange | Zimbra | Exchange | Zimbra | Exchange | Zimbra |
| 100 | $11,698.00 | $4,274.00 | $11,698.00 | $12,822.00 | $11,698.00 | $21,370.00 |
| 250 | $21,748.00 | $8,474.00 | $21,748.00 | $25,422.00 | $21,748.00 | $42,370.00 |
| 500 | $38,498.00 | $15,474.00 | $38,498.00 | $46,422.00 | $38,498.00 | $77,370.00 |
| 1,500 | $105,498.00 | $43,474.00 | $105,498.00 | $130,422.00 | $105,498.00 | $217,370.00 |
* These numbers take into account $35 per user per year for the first block of 25 users, $28 per user per year for an additional block of 25 users, and $1,299 per year for a RHEL Enterprise Linux Premium Subscription. On the Microsoft side, there is a $999 Windows 2003 Enterprise Server R2 license, $3,999 Exchange 2007 Enterprise Edition license, and $67 Exchange Standard CAL per user.
Table B shows a price comparison between Zimbra and Scalix. Scalix may be a better price comparison, because they are both more similar in feature set to each other than either one is to Exchange. They also both run on the Linux platform, and they are both trying to break into the space that is Exchange's to lose. As you can see, Scalix comes more heavily loaded at the beginning of the contract, but by Year 3, Zimbra's heftier yearly per-user fee brings it about neck in neck with Scalix, and by Year 5, Zimbra is significantly more expensive than Scalix.
Table B
| | Total Cost - 1 Year | Total Cost - 3 Years | Total Cost - 5 Years |
| # of Clients | Scalix | Zimbra | Scalix | Zimbra | Scalix | Zimbra |
| 100 | $7,799.00 | $4,274.00 | $12,797.00 | $12,822.00 | $17,795.00 | $21,370.00 |
| 250 | $17,549.00 | $8,474.00 | $26,147.00 | $25,422.00 | $34,745.00 | $42,370.00 |
| 500 | $32,799.00 | $15,474.00 | $47,397.00 | $46,422.00 | $61,995.00 | $77,370.00 |
| 1,500 | $95,799.00 | $43,474.00 | $134,397.00 | $130,422.00 | $172,995.00 | $217,370.00 |
* These numbers take into account $35 per user per year for the first block of 25 users, $28 per user per year for an additional block of 25 users, and $1,299 per year for a RHEL Enterprise Linux Premium Subscription. On the Scalix side, there is the $60 per user Scalix perpetual license for Scalix Enterprise Edition, the Scalix Migration Tool costs ($5/user for 250 users or less; $3 per user for more than 250 users), $1,299 per year for a RHEL Enterprise Linux Premium Subscription, and the $12 per user per year (after the first year) Scalix Software Subscription Service fees.
Of course, these are all comparisons of the vendors' list price. It may be quite possible to negotiate a better deal through volume licensing. Indeed, finding a street price on Microsoft products that is lower than list price is not difficult. It's also important to note that this is simply a comparison of the Exchange server to the Zimbra server with base OS costs. Zimbra believes (and I agree) that its Web client is good enough for most users to not need Outlook. Taking the costs of Outlook into account can tip the scale quite heavily in Zimbra's favor.
Cost breakdown
Check out this worksheet for a detailed comparison of Zimbra vs. Exchange costs.
Conclusion
The Zimbra Collaboration Suite works fine. Other than the difficult installation I experienced, nothing particularly stood out about it on a base, technical level as being bad. I believe that it is has a few weak points from a business standpoint. It took dings for its implementation of ClamAV and SpamAssassin, the "beta" label on the Documents system, its poor documentation, the lack of support beyond a handful of GNU/Linux distributions, its use of an outside-the-OS application server, database, and JDK, and a number of other items noted above.
Unless the idea of making your own Zimlets really appeals to you, Zimbra compares well with Scalix; Zimbra is better at some things, Scalix at others. If you are looking to replace your Windows and Exchange servers with a GNU/Linux system, it is worth trying out. If you are happy with your current Windows and Exchange servers, the Zimbra Collaboration Suite is probably not a strong enough alternative to tempt you away, unless you find that you do not use the bulk of your Exchange functionality anyway. In such a scenario, a lower level edition of Zimbra (or Scalix, for that matter) may be suitable for your organization. The best fit for Zimbra is for the enterprise that is ready and willing to dump Outlook, as well for a Web client. In this scenario, Zimbra is an excellent solution.
| Posted in »
