From open source groupware solution Zarafa to Exchange: Part 1, A New Beginning

This blog series will describe my experiences and lessons learned from migrating the Zarafa Groupware solution to Microsoft Exchange, specifically Exchange Server 2013. I’ve done this twice now and although some things are quite obvious, there are some gotchas and it might be a daunting endeavor. A normal transition from Exchange to Exchange already requires good planning, but it is even more important when migrating from a third party solution that isn’t supported by any available migration tool like Quest. I hope that with sharing my experiences, others will have a more smooth migration and happy users. Even if you don’t use Zarafa, most information will still be relevant when migrating from other (somewhat obscure) groupware systems or even from Exchange.

This part 1 post will give an overview of relevant topics in the upcoming posts.

See also Part 2: Active Directory


The goal of the migration is to migrate existing mail from Zarafa to Exchange, in such a way that users will have the most smooth transition possible. Having said that, there will be changes in how users have to use Outlook. There will certainly be some downtime, there will probably be some (meta-) data loss and users will certainly have to reapply some of their settings, after they have been migrated. As an admin, it’s important to acknowledge these things and prepare yourself and the organization for these changes. This will be discussed more extensively in a next part of this series.


But first, a little introduction of Zarafa Groupware. It’s a Microsoft Exchange Server alternative; an open source community software suite that mimics Microsoft Exchange. It runs on top of Linux-based Operating Systems, but can be integrated with Microsoft Active Directory. Users can connect via its webmail, use ActiveSync via the open source solution Z-Push, and can use Outlook via a plugin provided by Zarafa. It’s my understanding that it’s relatively popular in Europe, because some (government) organizations prefer or are required to use open source software unless closed source solutions are proven to be a better fit.

Zarafa is the core product, but it requires other open source solutions for mail flow. Organizations are free to use some of those supporting products, which makes it flexible. But it also means it’s not one big application with everything in it, and it requires admins to be knowledgeable about Postfix, Procmail and other solutions. There are multiple areas and programs where settings are required, in order to make the whole solution work as required. Where as you can administer practically everything within Microsoft Exchange, this is not the case with Zarafa, even when it’s integrated in Active Directory. You could compare it with Microsoft Exchange Server 5.5 in some regards.

Whether it’s cheaper or not, is something that I have debated regularly, but for now that is beyond the scope of this series. Zarafa can be compared with other like-minded solutions like Zimbra and OpenXchange, so as said some parts of this blog series could apply to those (and other) solutions.

I’ve migrated from Zarafa version 6.4 and 7.0 to Microsoft Exchange Server 2013 (first time to RTM and second time to CU3).

Exchange 2013

The target solution will be Microsoft Exchange Server 2013. While most actions described will be valid for Microsoft Exchange Server 2010 and perhaps even Microsoft Exchange Server 2007, the 2013 version certainly has it’s own issues to take into account. Having said that, the focus will not be how to successfully implement Exchange Server 2013, unless there are issues specific to this migration scenario.


There are several aspects of this migration that are important enough to be blogged about. As time (and writing) goes by, they might (probably) change but as for now expect posts regarding these topics:

  • Inventory
    Know what you have, what’s relevant and how it works, otherwise you can’t know how to reach the end goal.
  • Active Directory
    How Zarafa integrates in Active Directory, which attributes are used by Zarafa and challenges.
  • SMTP Mail flow and objects
    Things to take into account when functionality from Zarafa and it’s MTA’s (Mail Transfer Agents) are converted towards Exchange.For instance, Zarafa doesn’t have mail-enabled Public Folders.
  • Client Access & Coexistence
    Coexistence with different Exchange versions isn’t always easy, but most scenario’s are described by Microsoft or other bloggers. This isn’t the case with this scenario and I’ll show the impact and some possible choices.
  • Migration and Export/Import of data
    How do you get user and public folder data from Zarafa towards Exchange and expected challenges. Expect the use of PST files.
  • Communication to users
    Users will need instructions on how to survive the transition and to know what to expect. This is much, much more important than when you transition from Exchange to Exchange.
  • Planning & Concluding remarks
    Now you know what to do and how to do it, you can plan all necessary steps. Additional I probably have some concluding remarks, tips and tricks.


Now you have a bit of an idea what to expect from this series.

If you already have some questions, remarks or even suggestions for additional topics, feel free to let me know via a comment or other means of communication.

See also Part 2: Active Directory

Leave a Reply

Your email address will not be published. Required fields are marked *