Программа:

Сегодняшнее мероприятие «Есть ли жизнь после Exchange?» ведет Игорь Кальметов, генеральный директор компании «Лаборатория МБК».

Те, кто знакомы с нашим продуктом, они прекрасно знают функции, которые предоставляет данный почтовый сервер. Но на практике возникают проблемы, связанные с миграцией.

Установить TEGU, на самом деле, можно быстро. Это занимает несколько минут. А вот смигрировать существующую в Exchange инфраструктуру - это на самом деле дело непростое. Вот, собственно говоря, об этом хотелось бы сегодня поговорить. Говорим честно, потому что проблемы есть. Мы, как вендор, и заказчики, и наши партнеры все заинтересованы в том, чтобы все были заблаговременно проинформированы и объяснены функции TEGU, и о тех проблемах, которые могут ожидать пользователя. Собственно говоря, в чем основная проблема миграции с Exchange? В принципе, в настоящее время есть процедуры, которые позволяют мигрировать с чего угодно на TEGU. Эта процедура написана именно для TEGU.

Но Exchange представляет собой, во-первых, наиболее популярное решение, с которого приходится мигрировать, а, во-вторых, наиболее функциональное решение. Кроме того, Exchange достаточно проприетарное, закрытое решение. И во многом, мы ограничены именно этим. Поэтому, прежде чем начать рассматривать различные аспекты миграции, давайте сначала договоримся о терминовании. Какие протоколы и какие сущности реализованы на стороне Exchange и на стороне TEGU?

Первая строчка на слайде: вводятся аккаунты, они хранятся и на стороне Exchange, и на стороне TEGU в виде LDAP. Они до определенной степени совместимы, однако схемы LDAP Windows и схемы LDAP TEGU могут не совпадать. Почему они могут не совпадать? Потому что мы ориентированы на отечественные решения, в том числе и отечественные серверы каталогов. И эти серверы каталогов, сделанные на базе Linux, они не могут реализовать ту схему, которая реализована на Windows. И это фактор ограничений.

Нам приходится авторизовывать по пользователю, соответственно, по логину и паролю. А точнее по e-mail и паролю. Вот такая разница. Является ли она критичной. Ну, в определенной степени - нет. Что необходимо для того, чтобы создать пользователей почтовых тэгов? На серверах каталогов или даже, если это Windows АТ, необходимо, чтобы было заполнено поле e-mail в стандартной схеме. То есть, что мы используем из того, что расширенная схема, которую пользует Exchange, она не может быть использована, потому что она может быть просто отсутствовать. Вот такая разница на уровне пользовательских аккаунтов, которую мы должны принимать во внимание. Таким образом, что нужно сделать для того, чтобы мигрировать пользовательский аккаунт? Заполнить вот это самое дополнительное поле в стандартном IMAP стиле, которая называется EMAIL.

Почтовые IMAP сообщения. На стороне Exchange используются для этого протоколы МАPI и IMAP. На стороне TEGU используется IMAP и через слеш, обратите внимание, написан перспективный протокол - 2TMTP, который в настоящий момент уже реализован на TEGU. Но в общем и целом будем говорить о том, что этот протокол пока перспективный. Таким образом, возможно ли миграция почтовых IMAP сообщений? Да, она совершенно не вызывает никаких сомнений. Следующее, почтовые PST-сообщения. В данном случае PST – это проприетарный формат. Существует много версий этого формата. В TEGU используется формат MailBox.

Общие папки IMAP и там, и там. Общие аккаунты IMAP. В чем на самом деле различие? Обратите внимание, общие папки IMAP и общий IMAP account. Те функции, которые не редко просят от нас, это групповые почтовые ящики, от имени которых пользователь имеет право отправлять сообщения.

В одном аккаунте у вас может быть только одно имя, но один е-мейл, от имени которого вы можете отсылать сообщение. Для того, чтобы у вас в клиенте была возможность выбирать от имени какого е-мейла отправлять сообщения, вам необходим другой именно аккаунт этой почтовой программы. Других возможностей в существующих в программах просто нет. Можем ли мы подмешать в чужую IMAP-папку IMAP–папку вашего аккаунта? Да, можем, это делается автоматически, для этого ничего не нужно специально настраивать. Любое количество общих папок могут быть замонтированы в ваш персональный аккаунт. Но можно ли отвечать от имени этого аккаунта? Этой функции просто-напросто нет на почтовом клиенте. И поэтому единственное, что здесь можно сделать, это подключать дополнительный e-mail account. Но чтобы его подключать, необходимо знать параметры этого аккаунта.

Таким образом, для того чтобы реализовать общие IMAP аккаунты, нужно подключать дополнительный аккаунт, но со своей учетной записью, которая вам известна. Вот такая разница здесь присутствует. Можно ли это перенести? Да, разумеется это можно легко перенести.

Глобальная адресная книга. Тут, как правило, проблем не возникает.

Общие сетевые адресные книги. Тут тоже написано - CardDAV/2TMTP. Что касается DAV ресурсов. Обратите внимание у нас календари, частные или общие адресные книги частные или общие и так далее. То есть протоколом для них в Exchange является MAPI, протоколом для них в TEGU соответственно является CardDAV/2TMTP или CalDAV/2TMTP.

Следующая сущность, о которой необходимо задуматься, при приобретении, это глобальные и частные правила обработки.

И последнее, это функции управления почтовым ящиком. Функции, работающие на сервере, их настройка реализована в Outlook. Кроме Outlook пользователю не нужно ничего для того, чтобы управлять подобными сущностями. Возможно ли реализация подобных вещей с использованием стандартных протоколов? В общем, да. Какова наша позиция при реализации подобных вещей. Она собственно говоря, отображена на этом слайде.

То есть, да, у нас отечественные серверы. Мы в первую очередь ориентируемся именно на отечественные операционные системы. Поэтому, да, определенно, ограниченные есть. Главное правило звучит следующим образом: если не можем быть гарантирована 100% корректность автоматического переноса, то следует переносить вручную.

Давайте еще раз перечислим те функции, которые у нас есть, исходя, соответственно, из этого правила.

Касательно пользовательских аккаунтов. Для того чтобы это сделать, необходимо предпринять ряд усилий, в данном случае, заполнить поле е-mail для каждого участника почтового сервера. Можно ли это сделать автоматически? Да, разумеется, можно, делается это на стороне сервера каталога. Еще один момент. Как известно, TEGU не синхронизирует данные сервера каталога. Это функция принципиальная, это функция безопасности, это связано с тем, что TEGU в самом плохом варианте не может компрометировать ничью учетную запись. Таким образом, интеграция сервера каталогов получается односторонняя. И очень часто требуют функции, например, в помощь почтовой программе, сменить пользовательский пароль. Коллеги, это невозможно, мы исходим из того, что все пароли хранятся на сервере каталогов, TEGU не может менять никакие пароли на стороне сервера каталогов.

Вот такое существует ограничение. Тем не менее, возможно ли миграция пользовательских аккаунтов? Да, она возможно. Возможно ли сосуществование? Сосуществование - это когда одновременно и старый почтовый сервер, как в случае Exchange, и новый почтовый сервер, в нашем случае TEGU, они работают одновременно как одна единая почтовая система. Возможно ли их сосуществование? Да, в данном случае возможно.

Почтовое IMAP сообщение. Возможно ли миграция почтовых сообщений? Да, соответственно, она возможна. Для этого как раз есть функция миграции на стороне TEGU, которая, соответственно, это выполняет. И здесь обращаю ваше внимание на то, что это делается не средствами Exchange, а средствами TEGU. И эта же функция используется при миграции почтовых сообщений с почтовых серверов, которые не являются Exchange, например, облачными серверами. Значит да, подобная функция существует, она написана, но она реализует именно сосуществование.

Каким образом осуществляется именно перенос? Для этого мы рекомендуем использовать open source функции. С нашей точки зрения, эта функция, которая разрабатывается очень давно, она написана очень хорошо. И вот на примере этой функции я бы хотел заострить ваше внимание. Смотрите, что происходит, когда мы делаем интеграцию с Exchange. Единожды, сделав подобную функцию, мы обрекаем себя на то, что все остальное время мы будем отслеживать актуальность этой функции, совместимость этой функции. со всеми версиями Microsoft разработок на всю оставшуюся жизнь. И вот на это уйдет 90% наших ресурсов. Мы могли бы написать что-нибудь более стоящее, чем подобная миграция, но мы вынуждены будем, на самом деле, раз уж мы и заявили такую функцию, 90% своих усилий тратить на обеспечение совместимости. Сравнить себя по мощности с Microsoft мы не можем, поэтому браться за такое дело мы просто не будет. То есть разница не только в том, чтобы обеспечить эту совместимость один раз, разница в том, чтобы обеспечить ее со всеми версиями и редакциями, ну и так далее. При том, что если это работать будет плохо, то в первую очередь пользователи будут обращаться к нам.

Почтовые PST-сообщения. Можно написать конверторы? Хорошо они работают? Плохо, потому что стопроцентной совместимости методом обратного инжиниринга с Microsoft решением достичь невозможно. Так или иначе если присутствуют ошибки подобных конверторов, напишите мне, в этом мы разберемся. Будет ли их меньше? Скорее всего, нет.

Миграция PST-сообщений средствами TEGU невозможна. Рекомендуем использовать PST to IMAP конверторов, либо средства Outlook. Процедура в пакетном режиме практически невыполнима.

Особенности работы DAV серверов. Здесь мы затронем и календари, и адресные книги. Вообще говоря, Web DAV - это не совсем подходящее для этих функций решение, но другого в стандартных программах нет. Web DAV – это протокол, который позволяет HTTP синхронизировать, т.е. обмениваться в одну сторону. Этими файлами в почтовых программах могут быть календари и адресные книги.

В чем ограничение данного протокола? Одна адресная книга - это один файл, и один календарь - это тоже один файл. Таким образом синхронизировать приходится за каждый раз весь календарь и всю адресную книгу. Да, существуют расширения, которые позволяют синхронизировать только обновления. Но тем не менее, мы должны быть готовы, что нам придется синхронизировать весь файл в том числе. Файлы могут быть различного размера. То есть, если мы говорим про календарь, то в нем мы можем хранить течменты, то есть различные бинарные файлы. Эти файлы единожды добавлены, и они не исчезают оттуда никогда, если вы не удаляете ранее созданные эванты, события и содержащие эти бинарные файлы. Таким образом, получается, что с течением времени размер этого файла увеличивается, и в общем-то, может достигать весьма значительного размера, когда его синхронизация может быть затруднена. Это называют пользователи глюками, то есть на одном клиенте создано, на другом клиенте не появилось, пропало, ну и так далее.

На самом деле это просто проблема связана с синхронизацией, то есть просто тупой перекачкой этого огромного файла, который содержит в принципе ненужную уже никому информацию. Это нужно принимать во внимание, при миграции с MAPI на DAV протокол. В данном случае миграция может вызывать затруднение, как раз связанное с тем, что я описал ранее. Поэтому относиться к этому нужно весьма осторожно.

Представьте себе, что вы засинхронизировали эту глобальную адресную книгу с вашим телефоном. Поддержит ваш телефон 10 тысяч аккаунтов? Мы не проверяли. Вообще это интересная вещь.

Давайте конкретно адресные книги. Значит, реализация глобальных адресных книг, в общем, в этом случае миграция никакая и не требуется. Здесь источником для адресных книг является серверы-каталога, на базе которых TEGU формирует единый файл и соответственно отдаёт его по протоколу CardDAV.

Здесь миграция GAL не требуется. Миграция частных контактов требует дополнительных усилий, но не вызывает затруднений. Здесь сосуществование возможно.

Потому что все отечественные почтовые программы - это форки Thunderbird и больше пока ничего не существует.

Следующие сущности - календари. Миграция календарей автоматически средствами TEGU не возможна. Мы предлагаем, соответственно, метод экспорта-импорта. Опять же для того, чтобы избежать вариантов несовместимости. Возможно ли сосуществование календарей? Да, до определенной степени возможно. То есть, если пользователи приглашают друг друга на какие-то встречи, то это работает хорошо, бесшовно и никто не знает, где тут у меня пользователь, где он находится, это неважно. Возможно ли использовать, допустим, общие календари? Ну, естественным образом, нет. Если ваш аккаунт на TEGU уже существует, тогда, в общем-то, находясь еще на старом почтовом сервере, вы можете использовать общие календари, которые размещены на TEGU.