Is There Life After 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 are well aware of the functions that this mail server provides. However, in practice, problems arise related to migration.

Installing TEGU, in fact, can be done quickly. It takes a few minutes. But migrating an existing Exchange infrastructure is actually not an easy task. That's what we would like to talk about today. We are speaking honestly because there are problems. We, as a vendor, and our customers and partners are all interested in being informed in advance and having the functions of TEGU explained, as well as the problems that users may encounter. 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 that needs to be migrated from, and secondly, the most functional solution. In addition, Exchange is a fairly proprietary, closed solution. And in many ways, we are limited by this. Therefore, before we start considering various aspects of migration, let's first agree on the terminology. What protocols and entities are implemented on the Exchange side and on the TEGU side?

The first line on the slide: accounts are entered, and 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, but the LDAP Windows schema and the LDAP TEGU schema 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's 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 user account level that we must take into account. So, what needs to be done to migrate a user account? Fill in this additional field in the standard IMAP style, which is called EMAIL.

Mail IMAP messages. On the Exchange side, the MAPI and IMAP protocols are used for this. On the TEGU side, IMAP is used, and through a slash, note that 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. So, is it possible to migrate mail IMAP messages? Yes, it certainly does not cause any doubts. 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? Note the shared IMAP folders and the shared IMAP account. The 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 from which you can send a message. In order for you to have the ability to choose in the client from 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 an IMAP folder of your account 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. Here it is also written - CardDAV/2TMTP. Regarding DAV resources. Note that 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 finally, these are the mailbox management functions. Functions that work on the server, their settings are implemented in Outlook. Besides Outlook, the user does not 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 take a number of efforts, in this case, to 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 you know, TEGU does not synchronize directory server data. This function is fundamental, this function is security-related, 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 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. See 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 monitor 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.

Postal PST messages. Is it possible to write converters? Do they work well? No, because 100% compatibility with the Microsoft solution cannot be achieved by reverse engineering. Anyway, if there are errors in such converters, write to me, and we will figure it out. Will there be fewer of them? Most likely not.

Migration of PST messages using TEGU is not possible. 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 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., 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 each 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 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 may be difficult. Users call this glitches, that is, created on one client, did not appear on another client, 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 information that is basically no longer needed by anyone. This must be taken into account when migrating from the MAPI to DAV protocol. In this case, the 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,000 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. Calendar migration is not automatically possible with TEGU. We offer, accordingly, 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 I have a user here, where he is, 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 hosted on TEGU.