Note: This blog was written together with Dave Stork after reading a Zimbra and Exchange product comparison. You can find the article on Dave’s blog here, including a personal note by Dave.
In a blog post by Christopher Wells, alias vSamurai, the author positions VMware Zimbra Collaboration Server (ZCS 7.x) as an enterprise-ready drop-in replacement for Microsoft Exchange Server 2010 environments of all sizes. He also suggests Zimbra is a better multi-tenant solution for ISPs. The author does this by comparing both products in a feature comparison.
These reviews are helpful in order for companies to make an informed decision. After all, there’s nothing wrong with a bit of competition. However, Dave Stork and I wanted to create a response, because some statements are flawed or just plain wrong. In the process, we will be following the structure of the referenced blog:
Backup and Restore
The author starts off by claiming that “the ease with which backup and restore can be performed in Zimbra outweighs the capabilities of Exchange”. While it’s interesting to note the author implicitly admits Exchange is more capable, he misses the point. The product should follow a well-designed backup and recovery strategy, based on customer demands and compliance regulations. Where Exchange has server, database, mailbox and single item recovery options, Zimbra is built on top of MySQL, meaning recovery requires brick level restore or (partially) restoring information from MySQL dumps. Also, in Zimbra the databases only contains meta information; the actual messages and attachments are stored on the file system. While this makes sense for Zimbra, as many SQL people consider storing binary data in databases a bad practice, it increases the complexity of backup and restore, because meta information and file system needs to be in sync. Note that Exchange’s Extensible Storage Engine (ESE) is purpose-built for storing mailbox information, including attachments.
Then, the author claims that Zimbra has better scaling capabilities than Exchange. First, let’s start by looking at the definition of scaling. A system is said to scale well if:
- it can handle increased load without (serious) performance penalties, or
- the system is able to accommodate growth by adding resources (scale up) or additional systems (scale out).
Ideally, scaling up should show a linear pattern, meaning two systems equal can handle twice the load. Scaling out most of the time doesn’t, which makes sense when looking at how computers are designed using shared resources like buses for example.
Now, scaling isn’t solely a matter of hardware; a system also requires software built to scale. The role-based model of Exchange, with its specific roles for serving mailboxes and handling replication, routing e-mail and servicing clients, is a good example of a thought-out scalability supporting concept. Of course, you can install all roles on a single server, which is currently the recommended practice by Microsoft, but you’re still able to design fit-for-purpose farms and clusters.
Thus, the ability to scale is determined by the whole set of components playing well together, hardware and software. With this in mind we’d like to include an interesting table which is part of the VMware (acquired Zimbra early 2010) study “Zimbra Collaboration, Server Performance on VMware vSphere 5.0”:
In their analysis, VMware primarily focuses on the CPU utilization figure. That figure implies that Zimbra has more headroom than Exchange using the same configuration. However, Exchange also has several background processes which perform tasks in the background, like optimizing the database to reduce the number of IOPS. Yes this takes up a certain % of CPU cycles, but optimizing storage for sequential access could explain the significant 240% decrease in IOPS for Exchange. Lower IOPS reduces storage requirements – and costs – for Exchange. The over 60% lower latency figure for Exchange is also an indication overall processing of messages is faster in Exchange.
As often in these Open Source Software (OSS) discussions, the cost card is played. The author claims that on average, Zimbra is 50% cheaper than Exchange. However, this claim is made without any supporting references or figures, making it difficult to verify this statement. However, from our experiences, those claims are often primarily based on retail prices and licensing costs. What is often overlooked (or ignored) in comparisons with OSS, are training costs or hidden costs like support or maintenance.
Functionality is also a potential cost saver, as companies can work more efficiently due to added or enhanced functionality. These savings depend on customer needs, although some are widely used and immediately contribute to lower costs, like for example AutoDiscover (automatic configuration of Outlook 2007 and later clients or ActiveSync devices).
Exchange natively supports Outlook, common browsers and mobile devices; Zimbra requires an Outlook plug-In, Zimbra Connector for Microsoft Outlook, increasing support and maintenance costs. Note that this connector is only available for Zimbra Collaboration Server Network Edition Professional users.
Regarding maintenance, Exchange requires Exchange, Active Directory and (optionally, but a big bonus) PowerShell skills. Zimbra consists of a set of 3rd party products, requiring knowledge of each product, like Postfix, mbox e-mail storage, MySQL, Apache. OpenLDAP, SpamAssassin, ClamAV and shell scripting. Of course, more components mean more products to configure and maintain, increasing maintenance costs.
A full paragraph is dedicated to the benefits of using Zimbra with NetApp storage. However, the NetApp products and technologies mentioned are not Zimbra specific, and therefor in our opinion do not add anything to the discussion.
The author then continues with a “direct” feature comparison between Zimbra and Exchange. Let’s have a look:
1. Platform Architecture
First, author claims ESE is over 20 years old, the .EDB file is non-modular and the ESE engine is non-tunable. Yes, ESE exists for over 20 years, but that’s also 20 years of experience in building a fit-for-purpose database engine. With each new Exchange version, ESE was redesigned to meet evolving requirements and expectations in a changing world. When looking at the VMware IOPS comparison in the Scalability section, it’s Zimbra that should worry about storage.
Second, author claims Database Availability Groups (DAGs), based on Fail-over Clustering, isn’t a proven technology for large deployments. Exchange 2010 is on the market since October 2009. Like many Exchange fellows, we have designed or seen large Exchange deployments (i.e. thousands of mailboxes). Also, if millions of Office 365 users aren’t proof of a successful large scale multi-tenant ISP-like deployment based using multiple data center DAGs, what is?
To be honest, is it really that important which exact technology is used and how old it is? In the end functionality and performance are more important, as they are relevant in any business case for Exchange. What would a decision maker most likely ask, “Does it use Microsoft SQL Server?” or “What can we do with it and how much will it cost?”. We think and know out of experience it will probably be the latter.
2. Reliability & Robustness
The author claims Microsoft is considering (moving Exchange storage to) SQL and needs to prove robustness of the new architecture. While Microsoft has considered the SQL storage engine several times, it decided to stick with the optimized ESE engine. This was also true for Exchange 2010 back in 2009, like you can read in this blog. Main reason for deciding to stick with ESE is performance.
When pleading for ZCS, the author states “Linux has better uptime”. While this may have been true in the Windows 98 era, from experience, managed Exchange systems can reach similar uptime figures. On the contrary, I’ve seen Linux systems crashing every few days. The only conclusion you can draw here is that reliability not only depends on hardware and software components and their quality, it also depends a lot on if and how systems are managed. Also, don’t confuse uptime with availability, as planned downtime will reset my uptime statistic, but that’s all it is: a statistic.
3. Tiered Storage (was Platform Scalability)
Tiered storage, or Hierarchical Storage Management, is about classifying data in terms of things like security, performance or pricing. Exchange itself partly supports this concept, using elements like DAGs, databases, mailboxes, personal archives and retention policies. For example, you can home your mailbox on multiple lean and mean servers using fast SAS storage while personal archives, used to automatically store e-mail older than 1 year using retention policies, are served by a fat server using inexpensive SATA disks on JBOD storage.
ZCS utilizes a built-in HSM solution which automatically moves items from the (fast) primary volume to the (cheaper) secondary volume. The database holds information on the actual location where the item resides. Conceptually, this matches the Exchange concept of primary mailbox and personal archive using retention policies. However, retention policies are more powerful and – when permitted – give users control over what to archive and when. When Exchange customers want to use a deeper level of storage tiering, they can opt for 3rd party solutions like Symantec Enterprise Vault (item-level stubbing) or storage solutions.
Note however, there are some important factors to take into consideration with stubbing:
- Data stored on a different tier, e.g. tape, isn’t always available online;
- Tiered storage adds complexity, introducing the need to compare reduced costs for storage against additional costs due to increased complexity;
- Stubbing may impact future migration or transition options, e.g. vendor support, or recovery options.
4. High Availability
Author claims DAGs do not provide Exchange infrastructure protection and have a learning curve. The first part of that claim is absolutely true: DAGs are designed to increase the availability of Exchange databases served by Exchange servers holding the Mailbox role, while providing a fail‑over mechanism. Covering for the other tasks are the other Exchange roles. Mail flow within an Exchange Environment is automatically redundant when you have multiple Hub Transport servers, as they monitor connectivity and possible routes for delivery. For client access, multiple Client Access servers can be made redundant using load balancing technology. Exchange has these built-in features that work independent of where Exchange is running, i.e. they also work in a non-virtualized system and no additional high priced product is required to make the underlying services highly available.
Regarding the learning curve claim, every new technology has a learning curve. DAG is built on top of fail-over clustering (nothing new) and easier to manage than its predecessors, CCR and SCR. Then again, we’d prefer Exchange admins who know what they’re doing, rather than somebody who learned an SRM trick.
Speaking of which, the whole argument that “ZCS with VMware’s Site Recovery Manager (SRM) is proven, scalable and effective” is apparently nothing more than a plug for VMware’s SRM product in conjunction with VMware licenses (vSphere required), as we see no credible arguments.
5. Platform Extensibility
The author states that Microsoft recommends using its proprietary shell. We assume he means PowerShell, which is here to stay. Other vendors, like Cisco or Quest, are adopting it and offer modules to manage their products using PowerShell. Heck, even Zimbra offers PowerShell scripts to manage Zimbra through encapsulated SOAP requests. For the record, we both don’t know of any Exchange admin complaining about some Linux product requiring bash (Bourne-Again shell) or perl for scripting, turning this in a non-argument.
The author continues by apparently mixing a few things up. The argument given for ZCS is that “SOAP API allows server access using web services framework for client access and Zimlets for integration with 3rd-party services” while Exchange offers “limited SOAP access” and “Outlook add-ins require developer effort”. This is apples versus oranges; Outlook is a fat client and Zimlets are like web parts. If you want to make a nice dashboard, we’d suggest you use something like Sharepoint instead of bloating your e-mail web client.
Finally, SOAP and Exchange Web Services (EWS) are targeted at developers, PowerShell at automation. If you’re curious about the power of EWS, we’d suggest you check out the excellent blog by Glen Scales.
6. Platform Openness
While Exchange is mostly closed source, a lot has changed since the 90’s. Exchange has a developer center nowadays, where SDK and APIs are published on how to interact with certain parts of the Exchange ecosystem, e.g.:
- Exchange Server Web Services SDK
- Transport Agents SDK
- Backup and Restore SDK
- Exchange Server protocol documentation
7. Open Standard Protocols Support
It’s true that the current Outlook version doesn’t support all available standards for exchanging calendaring or contact information. However, for most companies that isn’t an issue. When required, solutions and workarounds are available.
Also see “Mobile Support”.
The author claims Outlook Web Access (OWA) has a single theme. That might have been the case with the RTM version, but since SP1 we have over 28 themes to choose from. If that’s not enough, there’s even an Exchange Server 2010 SP1 Outlook Web App Customization SDK to take customization into your own hands. Note that the SDK also documents integrating IM (e.g. Lync).
9. Web Client Support
Regarding Web Client support, the author states “limited browser support for OWA” (Outlook Web App). Since SP1, OWA has full support for IE7+, Firefox 3.01+ (Windows, MacOS, Linux), Chrome 18.104.22.168+ (Windows), Safari 3.1+ (MacOS). In addition, OWA Mini, targeted at simple mobile browsers, reincarnated in Exchange 2010 SP2.
Yes, there are browsers out there that don’t have the full featured Premium OWA (like Opera), but “limited browser support for OWA” is a bit over-simplified, especially if you take into consideration the combined market shares of the fully supported browsers (without Safari, between 81-91% since December 2011).
10. Mac Support
Outlook team and Mac Outlook are produced by two different teams, which might be one of the reasons for the feature disparity between Outlook 2010 and Outlook for Mac 2011. Apart from differences caused by the underlying operating system, we agree features should be as on par as possible for all available platforms.
Note that the mentioned Zimbra desktop client doesn’t support Exchange’s native MAPI protocol, adding the requirement to enable the IMAP or POP protocol on the Exchange server.
The author proceeds by arguing there’s no Outlook client or Exchange Server for Linux. That is a moot point; there’s also no Zimbra server for Windows. Also, when somebody’s trying to convince you using arguments like, “ZCS server components love the Linux platforms”, that’s not very convincing now, and is often seen with discussions when emotions prevail over rational thinking.
12. Mobile Support
More and more (mobile) clients are adopting the Exchange ActiveSync (EAS) protocol for exchanging e-mail, calendar, contact and task information with Exchange. In fact, even Blackberry announced they will adopt EAS in their upcoming Blackberry 10 OS product. This is probably driven by Microsoft releasing EAS protocol as part of their Open Specifications Promise, turning EAS more or less into the de‑facto standard for (corporate) e-mail synchronization for mobile clients.
Zimbra partially supports EAS for e-mail, calendar and contacts, but requires the Zimbra Mobile add-on. It is a bit unclear if tasks are synced, here it seems so for Pro users but here it is advised against while here the screenshots tell yet another story. Confusing.
The author doesn’t show how Zimbra is a better multi-tenancy solution for ISPs when compared to Exchange 2010. But since Exchange 2010 Service Pack 2, there is no need for third party hosting software as it is now fully incorporated in Exchange without extra costs.
However; the intent was possibly to prove this implicitly via the costs argument of on-premises deployments. One other way is to look at actual hosted Zimbra and Exchange solutions available commercially.
Let’s compare costs from random Zimbra providers (picked from Zimbra’s Partners list), Exchange hosting providers and Office 365 subscriptions. It is not an extensive comparison, but it should give us an indication. Some (not all) are shown here:
|Product||MrMail Professional Zimbra Mailbox||CVM Zimbra Professional Suite||PayPerCloud Hosted Exchange Professional||Office 365 Exchange Online||Office 365 Plan E1|
(mailbox, sharepoint is separate and additional)
|Own mail domain||Yes||Yes||Yes||Yes||Yes|
|POP / IMAP||yes/yes||yes/yes||yes/yes||yes/yes||yes/yes|
|SharePoint or similar||yes||yes||no||no||yes|
|Price per user per month||$8.61*||$7*||$7.95**||$4**||$8**|
*) discounts possible with more mailboxes
**) Note that prices are per month, but only apply with an annual subscription.
This table shows that the Exchange subscriptions are comparable or provide more functionality for lower costs. We do not see the 50% cost benefit argument at all and in our opinion shows that Exchange 2010 is a very viable multi-tenancy solution for ISPs.
One very important difference we want to point out is the available storage per mailbox. This tended to be a lot (several factors) more with Exchange than with Zimbra, without heavily impacting the price. This fact alone suggests that Exchange can be a very viable groupware solution to ISPs.
This concludes the authors’ feature comparison, but there are still some important elements missing, like product support, directory integration, IPv6 readiness, traffic management (e.g. ethical walls) or IRM. Also, what about integration or support of Unified Communications technologies, like single inbox – including voicemail – or voice access to mailbox?
Now don’t get the impression we want to condemn Christopher for trying to compare both products, even though by reading just the header and counting the numerous VMware-related logos on the site we were a bit hesitant regarding what the “conclusion” would be (we have a saying here, We from WC Eend recommend WC Eend).
We do appreciate good comparisons, because it can shake up our opinions of what is and what should be with Exchange and start interesting discussions. It‘s also an opportunity to learn about similar products. We believe competition is healthy and comparisons can be educational; It can help companies make a better fit for their needs and budget, or at least provide a starting point.
It is however crucial for a fair comparison that the facts, conclusions and opinions stated are correct and sound. Unfortunately, this is not the case with this article. There are numorous factual errors and most opinions stated are poorly argumented. To add to that, the author uses a feature list which can be found on the internet in several places, like here. This may be an indication authors are copying content, without knowledge or cross-checking facts.
Therefore, with the information provided in Christophers blogpost, one can’t conclude that Zimbra is an adequate replacement for all environments, Enterprise or SMB. Also, we do not see any indication that Zimbra is better suited for multi-tenancy by ISPs. If anything, we think we have shown that Exchange is a more than capable, competitive and well-though product.
You’re invited to comment or share your opinions in the comments below.
Update (April 10th): Apparently, on March 21st Wells posted a follow up on his Zimbra versus Exchange viewpoint. Looking at it, Wells seems to enjoy the attention. Despite saying discussing viewpoints keeps vendors’ focus sharp, he doesn’t come up with arguments on why our post was – in Wells’ words – flawed. While I believe Zimbra serves a purpose – and it certainly isn’t on my radar as Wells says – I feel Zimbra or other non-Exchange evangelists should be able to take feedback like a pro. When you ignore other viewpoints or remain silent when asked for arguments, it’s more like a monologue rather than the interaction Wells claimed he’s in favour of.
Finally, our post didn’t go unnoticed, as Tony Redmond referred to it an article on Windows IT Pro. In the article, called Dispelling myths and other half truths, Redmond addresses some of Wells’ flawed claims as well.
Pingback: Comparativo entre o VMWare Zimbra e o Microsoft Exchange « Rodrigo Rodrigues .:. www.andersonpatricio.org
This blog post contains a number of factual errors:
– Performance: The whitepaper linked to does not in fact focus primarily on CPU. It focuses primarily on IOPS, secondarily on memory, and on CPU only to a lesser degree. There ARE in fact numerous whitepapers, studies, etc. that prove that Zimbra is typically 50% of the TCO of Exchange. For example: http://www.youtube.com/watch?v=NfieNwFnvsc
– HSM is built into the app. It does not require 3rd party storage technology, it does not do stubbing, and it does not create additional management headache (because both primary and secondary HSM volumes are still part of built-in application level backup and mailbox management tools)
– Backup and recovery is built into the app. Dave Stork’s assertion that Zimbra’s B&R is built on top of mysql is simply false. Zimbra uses mysql as a metadata store (for headers, read/unread status, etc.) However, Zimbra’s backup mechanism works on a single-user basis to perform hot backups without relying on mysql or other 3rd party mechanisms. Zimbra includes administrative and end-user-self-service tools
– Mobile Support: Zimbra does in fact support the ActiveSync protocol natively on the mailbox store server (and has for years and years.) “Zimbra Mobile” is not an add-on, it’s a feature of the core Zimbra product. (i.e. it’s a checkbox that the administrator turns on, not an additional module or gateway)
– Scalability: For serious discussion, you
There were a number of other less serious errors (e.g. Zimbra’s mta is built on postfix not sendmail, etc. etc.)
In general, while I commend your attempt at a “fair and balanced” response to Christopher Well’s blog post, unfortunately your own blog post contains as many errors, if not more.
Ok, here goes:
– Performance: The paper states: “As Figure 4 demonstrates, Exchange CPU utilization is significantly greater than that of Zimbra Collaboration
Server”. One of the VMWare conclusions reads: “Much better CPU efficiency and ease of provisioning than Microsoft Exchange Server 2010”. What do you mean by “does not in fact focus primarily on CPU”? Regarding the video, please take vendor-sponsored customer testimonials with a grain of salt.
– Storage Tiering: Depends on definition. The meta information (per record) in MySQL points to primary or secondary volume regarding the actual message attachment. So, you actually need to keep 3 things in sync: the MySQL meta information and the primary and secondary HSM message volumes.It’s comparable to the way Exchange 2010 works: mailbox is primary, personal archive is secondary and the retention policy works like the crontab’ed HSM job. Also, HSM isn’t 3rd party (never said that) but does require the Network Edition.
– Backup and recovery: Regarding the Open Source Edition, there are several methods and (lots of) scripts for backup or restore. Some use LVM snapshots (requiring stopping and starting MySQL for consistency), some MySQL replication in conjunction with rsync and some a mix. The Network Edition has indeed more options, but under the hood it remains a process which manages MySQL data, indexes and message data. Besides, I see no options to restore a subset of items for a mailbox or a single item, Zimbra requires full account restoration. Note that by restoring a single item, I don’t mean soft deleted (recycle bin, trashcan) or soft-deleted (recoverable items). If I’m overlooking something, please provide pointers.
– Mobile Support: Zimbra Mobile is an optional component and available in the Network Edition only. It’s an optional component which you need to enable. One can also call it add-in. Potatoe, potato.
– Scalability: Er, what?
Thanks for the heads-up on postfix (I’d prefer postfix over sendmail any day, so I’m with ya, still running a BSD box with it for testing purposes).
Unfortunately, I don’t agree with your comment on this blog being equally (or worse) flawed compared to the post by Wells (which is largely a copy/paste exercise). You can discuss a thing or two, but our arguments are concise and consistent.
You talked about B&R and HSM and mobile like they weren’t built in, then say they’re only included in the Network Edition. To be clear: are you comparing the commercial version of Zimbra to the commercial version of Exchange? Or are you comparing the free open-source of Zimbra to the free open-source version of Exchange. Oh wait… there ISN’T a free open-source version of Exchange.
By definitely, all Zimbra customers will be running the Network Edition. Also, when you say mobile is included only as an add-in in Professional: Professional is the version that 99% of customers will use (EDUs, GOV, SMB, enterprise.) Only very large ISPs will use Consumer. And for those customers, the cost for Zimbra Mobile is a rounding error. So these items really are included at no additional cost in the version that 99.99% of Zimbra customers are running.
Storage tiering: you say “So, you actually need to keep 3 things in sync: the MySQL meta information and the primary and secondary HSM message ” No, that’s just it. YOU don’t need to do anything. The application automatically manages moving the message from primary to secondary storage based on a policy you define. You just set up primary and secondary volumes (mountpoints) in the admin UI, then a policy like “everything older than 30 days”. Mailbox backups, mailbox management, etc. automagically deal correctly with the fact that the users’ message are on two different physical volumes.
Author states, “Zimbra Collaboration Server can serve as a drop-in replacement for Microsoft Exchange in Enterprise environments of all sizes”, followed by “better suited for multi-tenant ISP deployments than Exchange”. Well, that depends, hence mentioning Network Edition or Pro when appropriate.
Regarding storage tiering: It doesn’t matter who or what keeps things in sync, the argument still stands: the tupel and file (on one of the volumes) are related so transactions (DB and file system) needs to be atomic. For example, when you want to partially restore a mailbox (if possible at all), you need to restore 1) the MySQL tuples, 2) files on primary volume and 3) files on secondary volume. Also, what happens when during the HSM archival process the server crashes; the system needs to be (made) consistent on database as well as two file system levels. I’m knowledgeable of the Zimbra architecture and processes and tend not to oversimplify or play down (potential) issues.
Now, you still didn’t answer the question on how to restore a single mail item?
PS: I won’t respond any further when you’re trying to ridicule others and trolling also isn’t appreciated.
Storage tiering: That’s semantics. Whether the application does it automatically or the admin has to do it manually, the point was that _three_ things have to be in the same state or point in time in order to work properly. That increases complexity.
Furthermore, you didn’t get into the response from Michel regarding performance. Can we conclude that you agree?
Regarding the 50% cost aspect. Our main point was that Christopher Wells made statements that weren’t backed with arguments or proof.
Speaking of proof, why post only one not very convincing video when you yourself state that there are many other sources? The video does not offer enough information to verify it’s statements or to put it in context (did they used Exchange 2007 or 2010 for instance).
There’s a lot of pontificating here over points that are very subjective. That said i believe Michel has made an excellent retort to what is a non issue. As technologists i cannot understand the dogmatic insistence by some in what is nothing more than crude marketing sales pitches or childish fanboyism.
I use both products heavily. That said i consider myself an Exchange evangelist only from the perspective of it does what i want it to. Whilst Microsoft UC from a job perspective is my breadn and butter.
I’m VERY much an Open Source fan and a fan of Unix/Linux products and run a variety of Linux MTA’s/collaboration suites that include BBS servers, Postfix, and Sendmail. Bottom line is comparing Exchange to Zimbra is akin to comparing a F1 McLaren with a bicycle just because both are methods of transport. I commend Michel for his patience in responding with such detail to a lengthy article that is clearly just a sales pitch. Personally i wouldn’t have given it the time of day.
I just visited Mr. Mail website and found out that all of their packages actually shows 25MB as the attachment size and they also offer Unlimited Zimbra Mailbox, see: http://www.mrmail.com/zimbra-hosting/unlimited-zimbra-mailbox.html. I have just signed for their FREE Zimbra mailbox service, so far so good, but we’ll see how it goes. Maybe they have just updated their service offerings, but you should amend your post.
I’m looking at their site right now with the link you provided and they really only offer the 25MB attachment size only with the unlimited account. All others are 20MB.
Furthermore, their unlimited account has no ActiveSync and no Outlook connector access, making a comparison with Exchange pointless.
So, I see no reason to amend our post.
Of course, packages offered by these vendors are subject to changes. For actual information, consult the vendor site.
Absolutely agree, it seems like mr. mail is pushing and now they state 30MB as the max attachment size. I think just a few days ago I saw there 20MB, but on their page listing all packages they said 30MB. I think their web person just must be slow updating all relevant pages
This is one awesome blog post.Really looking forward to read more. Really Cool.
As commented on vsamurai.com: It’s ironic to see Exchange being critiqued for using both old (implying: outdated and obsolete) underlying technology – ESE, and new one (implying: unproven and bug-ridden) – DAGs. Heads, we win, tails, you lose.
And there’s one other thing: what is “drop-in” replacement? No-cost migration? I think that’s something akin to “bare metal” hypervisor – as if there’s no memory and process management and hardware driver model and IO management functions tuntamount to full OS.
Zimbra has migration tools built-in to the admin console at no extra cost. Migration is also very easy for PSTs. More importantly, Zimbra will support migration activity.
However, if you want to migrate from any other solution to MSE, then you would need to buy 3rd party tools…..and more importantly, MS will not support this migration activity.
There are supported options which don’t require 3rd party tooling. There is 3rd party tooling available designed for migration scenarios. However, most of the times – especially in large co-existence scenarios – costs involved with such tools outweigh (i.e. are cheaper) the costs of a labor-intensive, manual process. Those tools are in no way comparable with the “free” Zimbra functionality you’re referring to.
At the end of the day, Migration is going to be a one-time activity. You don’t want to spend too much on the 3rd party tools. Ofcourse, it is critical and as Zimbra supports this activity, there is nothing to worry.
True, but ignoring (3rd party) tools may directly affect time spent on migrating while you could have achieved the same result faster and in a more controlled fashion using proper tooling. The out of the box stuff isn’t always the cream.
Pingback: VMWare Zimbra almejando o mercado do Microsoft Exchange Server « Aldo Alves
Pingback: 2012, a short Retrospective | EighTwOne (821)
Pingback: Dave Stork's IMHO : 2012: looking back
Pingback: EighTwOne 2013 Annual Report | EighTwOne (821)
Outlook 2011 doesn’t use MAPI, it uses EWS.
It was mentioned as a side note for Zimbra desktop client.
Pingback: VMware Zimbra vs. Microsoft Exchange - Follow-up | vSamurai (仮想侍)vSamurai (仮想侍)
Pingback: 2012: looking back | Dave Stork's IMHO
Pingback: Thoughts on “VMware Zimbra vs. Microsoft Exchange” | Dave Stork's IMHO