Есть ли жизнь после Exchange?

Program:

Today's event, "Is There Life After Exchange?" is led by Igor Kalmetov, CEO of MBK Laboratory.

Those who are familiar with our product know perfectly well the functions that this mail server provides. But in practice, problems arise related to migration.

Installing TEGU, in fact, can be done quickly. It takes a few minutes. But migrating the existing Exchange infrastructure is actually not an easy task. That's what I would like to talk about today. We speak honestly because there are problems. We, as a vendor, and customers, and our partners are all interested in ensuring that everyone is informed in advance and the functions of TEGU are explained, as well as the problems that may await the user. So, what is the main problem with migrating from Exchange? In principle, there are currently procedures that allow migrating from anything to TEGU. This procedure is written specifically for TEGU.

But Exchange is, firstly, the most popular solution from which you have to migrate, and secondly, the most functional solution. In addition, Exchange is quite proprietary, a closed solution. And in many ways, we are limited by this. Therefore, before we begin to consider various aspects of migration, let's first agree on the terminology. What protocols and what entities are implemented on the Exchange side and on the TEGU side?

The first line on the slide: accounts are entered, they are stored both on the Exchange side and on the TEGU side in the form of LDAP. They are compatible to a certain extent, however, the LDAP Windows schemas and the LDAP TEGU schemas may not match. Why might they not match? Because we are focused on domestic solutions, including domestic directory servers. And these directory servers, made on the basis of Linux, cannot implement the schema that is implemented on Windows. And this is a limiting factor.

We have to authorize by user, respectively, by login and password. Or rather, by e-mail and password. That's the difference. Is it critical? Well, to a certain extent - no. What is needed to create mail tag users? On directory servers or even if it is Windows AT, the e-mail field must be filled in the standard schema. That is, what we use from the extended schema that Exchange uses cannot be used, because it may simply be absent. That's the difference at the level of user accounts that we must take into account. So, what needs to be done to migrate a user account? Fill in this very additional field in the standard IMAP style, which is called EMAIL.

Mail IMAP messages. On the Exchange side, MAPI and IMAP protocols are used for this. On the TEGU side, IMAP is used and, through a slash, pay attention, a promising protocol is written - 2TMTP, which is currently already implemented on TEGU. But in general, we will talk about the fact that this protocol is still promising. Thus, is it possible to migrate mail IMAP messages? Yes, it does not cause any doubts at all. Next, mail PST messages. In this case, PST is a proprietary format. There are many versions of this format. TEGU uses the MailBox format.

Shared IMAP folders both there and there. Shared IMAP accounts. What is the real difference? Pay attention, shared IMAP folders and shared IMAP account. Those functions that are often requested from us are group mailboxes, on behalf of which the user has the right to send messages.

In one account, you can only have one name, but one e-mail on behalf of which you can send a message. In order for you to be able to choose in the client on behalf of which e-mail to send messages, you need another account of this mail program. There are simply no other possibilities in existing programs. Can we mix your account's IMAP folder into someone else's IMAP folder? Yes, we can, this is done automatically, you don't need to configure anything specifically for this. Any number of shared folders can be mounted into your personal account. But can you reply on behalf of this account? This function simply does not exist on the mail client. And therefore, the only thing that can be done here is to connect an additional e-mail account. But to connect it, you need to know the parameters of this account.

Thus, in order to implement shared IMAP accounts, you need to connect an additional account, but with your own account that you know. That's the difference here. Can this be transferred? Yes, of course, this can be easily transferred.

Global address book. There are usually no problems here.

Shared network address books. It also says here - CardDAV/2TMTP. As for DAV resources. Pay attention, we have calendars, private or shared address books private or shared, and so on. That is, the protocol for them in Exchange is MAPI, the protocol for them in TEGU is CardDAV/2TMTP or CalDAV/2TMTP, respectively.

The next entity to consider when purchasing is global and private processing rules.

And lastly, these are mailbox management functions. Functions that work on the server, their settings are implemented in Outlook. Besides Outlook, the user doesn't need anything to manage such entities. Is it possible to implement such things using standard protocols? In general, yes. What is our position when implementing such things? It is, in fact, displayed on this slide.

That is, yes, we have domestic servers. We primarily focus on domestic operating systems. Therefore, yes, there are definitely limitations. The main rule is as follows: if 100% correctness of automatic transfer cannot be guaranteed, then it should be transferred manually.

Let's list again those functions that we have, based, respectively, on this rule.

Regarding user accounts. In order to do this, it is necessary to make a number of efforts, in this case, fill in the e-mail field for each participant of the mail server. Can this be done automatically? Yes, of course, it is done on the directory server side. One more point. As is known, TEGU does not synchronize directory server data. This is a fundamental function, it is a security function, it is related to the fact that TEGU in the worst case cannot compromise anyone's account. Thus, the integration of the directory server is one-sided. And very often they require functions, for example, to help the mail program, to change the user password. Colleagues, this is impossible, we assume that all passwords are stored on the directory server, TEGU cannot change any passwords on the directory server side.

That's the limitation. Nevertheless, is it possible to migrate user accounts? Yes, it is possible. Is coexistence possible? Coexistence is when both the old mail server, as in the case of Exchange, and the new mail server, in our case TEGU, work simultaneously as one single mail system. Is their coexistence possible? Yes, in this case it is possible.

Mail IMAP message. Is it possible to migrate mail messages? Yes, respectively, it is possible. For this, there is a migration function on the TEGU side, which, respectively, performs this. And here I draw your attention to the fact that this is not done by Exchange means, but by TEGU means. And this same function is used when migrating mail messages from mail servers that are not Exchange, for example, cloud servers. So yes, such a function exists, it is written, but it implements coexistence.

How exactly is the transfer carried out? For this, we recommend using open source functions. From our point of view, this function, which has been developed for a very long time, is written very well. And on the example of this function, I would like to draw your attention. Look at what happens when we integrate with Exchange. Once we have made such a function, we doom ourselves to the fact that all the rest of the time we will be tracking the relevance of this function, the compatibility of this function with all versions of Microsoft developments for the rest of our lives. And this will take 90% of our resources. We could write something more worthwhile than such a migration, but we will be forced to, in fact, since we have declared such a function, spend 90% of our efforts on ensuring compatibility. We cannot compare ourselves in power with Microsoft, so we simply will not take on such a thing. That is, the difference is not only in ensuring this compatibility once, the difference is in ensuring it with all versions and editions, and so on. Given that if it works badly, then users will turn to us first of all.

Mail PST messages. Can converters be written? Do they work well? Badly, because 100% compatibility by reverse engineering with a Microsoft solution is impossible. One way or another, if there are errors in such converters, write to me, we will figure it out. Will there be fewer of them? Most likely not.

Migration of PST messages by TEGU means is impossible. We recommend using PST to IMAP converters, or Outlook tools. The procedure in batch mode is practically impossible.

Features of DAV servers. Here we will touch on both calendars and address books. Generally speaking, Web DAV is not a very suitable solution for these functions, but there is no other in standard programs. Web DAV is a protocol that allows HTTP to synchronize, i.e. to exchange in one direction. These files in mail programs can be calendars and address books.

What is the limitation of this protocol? One address book is one file, and one calendar is also one file. Thus, you have to synchronize the entire calendar and the entire address book every time. Yes, there are extensions that allow you to synchronize only updates. But nevertheless, we must be prepared that we will have to synchronize the entire file as well. Files can be of different sizes. That is, if we are talking about a calendar, then we can store attachments in it, that is, various binary files. These files are added once, and they never disappear from there, unless you delete previously created events, events and containing these binary files. Thus, it turns out that over time the size of this file increases, and in general, it can reach a very significant size, when its synchronization can be difficult. Users call this glitches, that is, it was created on one client, it did not appear on another client, it disappeared, and so on.

In fact, this is just a problem related to synchronization, that is, just a stupid transfer of this huge file, which contains, in principle, information that is no longer needed by anyone. This must be taken into account when migrating from MAPI to DAV protocol. In this case, migration may cause difficulties, just related to what I described earlier. Therefore, you need to treat this very carefully.

Imagine that you have synchronized this global address book with your phone. Will your phone support 10 thousand accounts? We haven't checked. In general, this is an interesting thing.

Let's talk specifically about address books. So, the implementation of global address books, in general, in this case, no migration is required. Here, the source for address books is directory servers, on the basis of which TEGU forms a single file and, accordingly, gives it away via the CardDAV protocol.

Here GAL migration is not required. Migration of private contacts requires additional effort, but does not cause difficulties. Coexistence is possible here.

Because all domestic mail programs are forks of Thunderbird and nothing else exists yet.

The following entities are calendars. Migration of calendars automatically by TEGU means is not possible. We offer, respectively, an export-import method. Again, in order to avoid incompatibility options. Is coexistence of calendars possible? Yes, to a certain extent it is possible. That is, if users invite each other to some meetings, then it works well, seamlessly and no one knows where this user is, where he is located, it does not matter. Is it possible to use, for example, shared calendars? Well, naturally, no. If your account on TEGU already exists, then, in general, while still on the old mail server, you can use shared calendars that are located on TEGU.