Is there life after Exchange?

Hi, my name is Yakov, I am a design engineer at T1 Integration. My team and I integrate new mail systems for customers — CommuniGate Pro, RuPost, VK WorkMail — and help with data migration (mainly from Exchange).

In our time of instant messengers and instant messages, email still remains an indispensable service, the failure of which can stop the work of the entire company. Coordination of important issues, appointments, calendar management, address book – all these functions are provided by mail servers. And historically, Microsoft Exchange was the standard in this area for many years, including in Russian companies. But the world is changing rapidly, and Microsoft has already suspended the work of many of its services in our country.

So is there life after Exchange? Yes! And quite a happy one. We found this out from our own experience: we tested countless Russian mail systems that are popping up like mushrooms after the rain, and also implemented several projects to migrate thousands of users.

Notes on Migration

Regardless of the solution chosen, the integrator must ensure that data transfer and user transition to the new system is as painless as possible. Many vendors provide migration tools and recommendations, but each case must be considered separately.

For small and medium-sized companies, the easiest way is to migrate all users over a weekend, but this is usually a utopian scenario. As a rule, the scale of mail in organizations is such that it is necessary to plan for a long period of coexistence of systems – from three months to a year. In this case, letters are sent between the source and target systems using third-level service domains. For example, in the case of the company.com domain, you can use the old.company.com domain for Exchange and new.company.com for the target mail system. This way, inboxes are supported in them, which allows you to return the user back to Exchange with minimal costs, if necessary.

For example, when replacing Outlook, one of the most important tasks is to meet the user's expectations. After all, if he does not receive an adequate analogue of the usual mailer, the project is doomed to failure. Most domestic vendors understand this, so developers offer means of modifying it. Of course, Outlook can work with the SMTP and IMAP protocols (and even POP3, if it is still relevant for someone), but it does not really know how to work with the CalDav and CardDav protocols. There are plugins that correct this omission and allow you to synchronize calendars and address books so that the user feels as comfortable as possible.

Key players

CommuniGate Pro

The largest and most scandalous product on the domestic mail system market. The first version was released back in 1998, it was developed by a team of three Russian programmers. Over the years, the CommuniGate platform has acquired various add-ons and has become a serious competitor to Microsoft Exchange and Microsoft Teams. CommuniGate Pro is currently used by over 6,000 Russian companies and government agencies, with over three million users.

And everything would have been fine, if not for the sudden death of one of the developers. His daughter and heir unleashed a whole patent war, which led to the fact that CommuniGate Pro licenses were not sold for quite a long time, and new versions were not released. Later, sales were resumed, but the aftertaste remained.

VK WorkMail

If CommuniGate was initially developed as a corporate mail server, then our next hero came to the B2B segment from the mass market. The VK WorkSpace project was launched in 2013 on the basis of Mail.ru Mail as a set of cloud services for collaboration. In December 2016, it was relaunched, turning into a platform combining three main products: the VK Teams messenger, the VK WorkDisk file storage, and the VK WorkMail mail service, which is available in the VK cloud or can be deployed on-premise.

VK WorkMail is a corporate mail system with a microservice architecture, aimed primarily at large companies. During installation, many containers are created that are responsible for various system functions. This ensures high responsiveness and fault tolerance at the level of individual components.

VK WorkMail has a built-in monitoring system for all components based on Zabbix and Grafana:

At the moment, VK WorkMail is the only system that has the functionality of shared mailboxes (analogous to Shared Mailbox in Exchange):

The authors understood who they would have to compete with, and created a migration and coexistence mechanism adapted for a long period of joint work with Exchange:

How to migrate from Exchange to VK WorkMail

Migration consists of the following stages:

  • Setting up coexistence of Exchange and VK WorkMail (sending and receiving emails via Exchange).

  • Migration of all data from Exchange to VK WorkMail.

  • Maintaining data consistency across the two systems during the migration period.

  • Gradually switching users to VK WorkMail.

  • Switching sending and receiving emails to VK WorkMail.

VK WorkMail provides high performance and availability of email, but the system itself is quite complex to initially install and configure. There may also be difficulties with debugging due to the complex microservice architecture. It may require a significant amount of computing and storage resources.

RuPost

We will take a closer look at the youngest, but no less promising participant in our review — RuPost from the Astra Group. This is a corporate mail system without any frills. It can be easily integrated — “out of the box”! — with Russian antiviruses, antispam systems, DLP solutions and other systems. Please note that the developers of RuPost focus on integration only with those third-party products that are included in the register of the Ministry of Digital Development.

We believe that user convenience is extremely important for a mail system. An ordinary employee of the company should not feel any difference when migrating from one system to another. And here RuPost has an attractive advantage: its server supports regular Outlook, which is not only familiar to everyone, but can also, for example, work with local mail archives stored on users' workstations. In our experience, the problem of compatibility with Outlook often arises when replacing foreign mail systems.

RuPost has not forgotten about system administrators, who are often forgotten. For them, there is a convenient and intuitive web interface, allowing those who are used to administering Exchange to quickly get used to it.

There is also a monitoring system here.

There is also a monitoring system here.

Cluster instance management interface

Cluster instance management interface

Managing mailboxes

Managing mailboxes

Web client

Web client

Desktop client

Desktop client

Another important task is that when switching from one system to another, the service should not be interrupted for a second. This requires an effective data transfer mechanism, as well as joint work of the two systems during the transition. RuPost has a utility for switching from another mail system. Migration consists of the following stages:

  • Setting up coexistence of Exchange and RuPost using a special configuration template.

  • Installing and configuring the migration node.

  • Data migration to RuPost.

  • Finalizing data and switching the user to RuPost. Switching is one-way and does not imply rolling back users to Exchange.

RuPost is relatively easy to install and configure initially, and is easily scalable. It has a centralized configuration system with templates for cluster deployment. Overall, the functionality is already quite rich:

  • Trusted mail server mechanism at the domain level.

  • Separation of domains and aliases (pseudonyms), which are written in the Proxy address field.

  • You can configure AutoDiscover (automatic selection of the client when one domain coexists in Exchange and RuPost) at the level of DNS group policies or by adding an entry to hosts.

The disadvantages of RuPost include the presence of two potential points of failure – PostgreSQL and the Memcached service. Their fault tolerance must be ensured by third-party means.

Also not yet implemented:

  • Client authentication within a domain via Kerberos and other centralized management systems (however, this is already planned for development).

  • Recalling sent letters.

  • Granular recovery of data in the account profile.

How to migrate from alternative systems to RuPost

Migration from other mail systems (SourceOne, Commvault, Zimbra, etc.) will not be as simple as with Exchange. Each case will have to be considered separately, and the help of an integrator may be required.

In general, available migration tools like IMAPsync are used, and a lot of automation scripts are required to interact with the source and target systems. Unfortunately, RuPost does not yet have rich CLI and API functionality, and some automation capabilities are limited.

Stress Testing

The new mail system must withstand the same load as Exchange, and even more, since the load will be doubled when users migrate to the new server. And email is usually a highly loaded system anyway, especially in large organizations. We conducted various load tests, using JMeter to generate load on various components of the mail systems and simulate typical user work during the day.

Here is an example of our stand for load testing RuPost:

The stand was a cluster of 8 RuPost 2.5 nodes, a PostgreSQL DBMS server, a Memcached service server, an NFS storage, and an HAproxy load balancer. We used JMeter as a load generator.

Characteristics of test machines:

Machine name

CPU

RAM

Purpose of the machine

rupost01

4

32 GB

RuPost cluster node

rupost02

4

32 GB

RuPost cluster node

rupost03

4

32 GB

RuPost cluster node

rupost04

4

32 GB

RuPost cluster node

rupost05

4

32 GB

RuPost cluster node

rupost06

4

32 GB

RuPost cluster node

rupost07

4

32 GB

RuPost cluster node

rupost08

4

32 GB

RuPost cluster node

memcached

4

4 GB

RuPost component for data caching

postgres

16

32 GB

PostgreSQL DBMS Server

balance

4

4 GB

Load balancer

jmeter

10

8 GB

Load generator

dc-01

4

8 GB

AD DS Domain Controller, DNS Server

Storage

Server name

Read IOPS

Write IOPS

NFS

4000

11000

NFS storage for mailbox, queue and index data

The load was generated internally for two hours from 100 randomly selected sender addresses to 500 randomly selected recipient addresses. The average was 5000 messages per minute. The message was an email with a filled subject, randomly generated text, and a .txt file of 100 KB. The metrics were taken using Zabbix once per minute.

Note: we tested in close cooperation with the vendor's engineers, since the system “out of the box” does not withstand such a load and requires modifications to the RuPost configuration template. After a series of adjustments, we managed to achieve stable queue processing indicators:

On average, peaks of active queues during testing reached 500 messages and lasted no more than a minute. We also tested scenarios of mass connection of clients via the IMAP protocol and login to the web interface of the mail system.

We believe that the system can work in large companies, but it requires careful development of scaling, architecture and consideration of the conditions of the customer's specific IT infrastructure. However, most Russian systems show themselves well in such tests and provide the necessary performance.

Afterword

As our experience shows, it is quite possible to find a suitable alternative to Exchange among Russian mail solutions. Of course, new systems are unusual for users and administrators, but you can always find an integrator who will help you move as painlessly as possible.

Similar Posts

Leave a Reply

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