¿Hay vida después de Exchange?

Evento conjunto de OCS y "Laboratorio MBK", una empresa rusa desarrolladora del servidor de correo nacional de nueva generación Tegu. En esta reunión, intentamos responder a la pregunta principal: "¿Existe un reemplazo para Exchange?"

Programa:

• Propiedades únicas del servidor MS Exchange, ¿se pueden reemplazar con componentes de software de código abierto (SPO)?
• Similitudes y diferencias entre el servidor de correo TEGU y MS Exchange.
• ¿Es posible un reemplazo completo y cuáles son las perspectivas?

El evento de hoy «¿Hay vida después de Exchange?» está dirigido por Igor Kalmetov, director general de la empresa «Laboratorio MBK».

Aquellos que conocen nuestro producto, conocen perfectamente las funciones que ofrece este servidor de correo. Pero en la práctica surgen problemas relacionados con la migración.

Instalar TEGU, en realidad, se puede hacer rápidamente. Lleva unos minutos. Pero migrar la infraestructura existente en Exchange es, en realidad, una tarea difícil. De esto es de lo que me gustaría hablar hoy. Hablamos con honestidad, porque hay problemas. Nosotros, como proveedor, y los clientes, y nuestros socios, estamos interesados en que todos estén informados con anticipación y se expliquen las funciones de TEGU, y los problemas que pueden esperar al usuario. En esencia, ¿cuál es el principal problema de la migración desde Exchange? En principio, actualmente existen procedimientos que permiten migrar desde cualquier cosa a TEGU. Este procedimiento está escrito específicamente para TEGU.

Pero Exchange es, en primer lugar, la solución más popular desde la que hay que migrar y, en segundo lugar, la solución más funcional. Además, Exchange es una solución bastante propietaria y cerrada. Y en gran medida, estamos limitados precisamente por esto. Por lo tanto, antes de comenzar a considerar los diferentes aspectos de la migración, primero acordemos la terminología. ¿Qué protocolos y qué entidades se implementan en el lado de Exchange y en el lado de TEGU?

La primera línea en la diapositiva: se introducen las cuentas, se almacenan tanto en el lado de Exchange como en el lado de TEGU en forma de LDAP. Son compatibles hasta cierto punto, sin embargo, los esquemas LDAP de Windows y los esquemas LDAP de TEGU pueden no coincidir. ¿Por qué pueden no coincidir? Porque estamos orientados a soluciones nacionales, incluidos los servidores de directorio nacionales. Y estos servidores de directorio, hechos sobre la base de Linux, no pueden implementar el esquema que se implementa en Windows. Y este es un factor de limitación.

Tenemos que autorizar por usuario, respectivamente, por nombre de usuario y contraseña. O más bien por correo electrónico y contraseña. Esta es la diferencia. ¿Es crítica? Bueno, hasta cierto punto, no. ¿Qué se necesita para crear usuarios de etiquetas de correo? En los servidores de directorio o incluso, si es Windows AT, es necesario que se complete el campo de correo electrónico en el esquema estándar. Es decir, lo que usamos de lo que el esquema extendido que usa Exchange, no se puede usar, porque simplemente puede estar ausente. Esta es la diferencia a nivel de cuentas de usuario que debemos tener en cuenta. Entonces, ¿qué se debe hacer para migrar una cuenta de usuario? Complete este campo adicional en el estilo IMAP estándar, que se llama EMAIL.

Mensajes de correo IMAP. En el lado de Exchange, se utilizan los protocolos MAPI e IMAP para esto. En el lado de TEGU, se utiliza IMAP y, a través de una barra inclinada, preste atención, se escribe un protocolo prospectivo: 2TMTP, que actualmente ya está implementado en TEGU. Pero en general, hablaremos de que este protocolo aún es prospectivo. Entonces, ¿es posible la migración de mensajes de correo IMAP? Sí, no hay duda alguna. Lo siguiente, mensajes PST de correo. En este caso, PST es un formato propietario. Existen muchas versiones de este formato. En TEGU se utiliza el formato MailBox.

Carpetas compartidas IMAP tanto allí como allí. Cuentas compartidas IMAP. ¿Cuál es realmente la diferencia? Preste atención, carpetas compartidas IMAP y cuenta IMAP compartida. Las funciones que a menudo nos solicitan son buzones de correo grupales, en nombre de los cuales el usuario tiene derecho a enviar mensajes.

En una cuenta, solo puede tener un nombre, pero un correo electrónico en nombre del cual puede enviar un mensaje. Para que tenga la opción en su cliente de elegir en nombre de qué correo electrónico enviar mensajes, necesita otra cuenta de este programa de correo. Simplemente no hay otras opciones en los programas existentes. ¿Podemos mezclar una carpeta IMAP de su cuenta en la carpeta IMAP de otra persona? Sí, podemos, esto se hace automáticamente, no es necesario configurar nada especialmente para esto. Se puede montar cualquier número de carpetas compartidas en su cuenta personal. ¿Pero es posible responder en nombre de esta cuenta? Simplemente no existe esta función en el cliente de correo. Y, por lo tanto, lo único que se puede hacer aquí es conectar una cuenta de correo electrónico adicional. Pero para conectarlo, necesita conocer los parámetros de esta cuenta.

Por lo tanto, para implementar cuentas IMAP compartidas, debe conectar una cuenta adicional, pero con su propia cuenta que conoce. Esta es la diferencia aquí. ¿Se puede transferir esto? Sí, por supuesto, esto se puede transferir fácilmente.

Libreta de direcciones global. Aquí, por lo general, no hay problemas.

Libretas de direcciones de red compartidas. Aquí también está escrito: CardDAV/2TMTP. En cuanto a los recursos DAV. Preste atención, tenemos calendarios, libretas de direcciones privadas o compartidas, privadas o compartidas, etc. Es decir, el protocolo para ellos en Exchange es MAPI, el protocolo para ellos en TEGU es respectivamente CardDAV/2TMTP o CalDAV/2TMTP.

La siguiente entidad en la que debe pensar al comprar es en las reglas de procesamiento globales y privadas.

Y por último, estas son las funciones de administración de buzones. Las funciones que se ejecutan en el servidor, su configuración se implementa en Outlook. Además de Outlook, el usuario no necesita nada para administrar tales entidades. ¿Es posible implementar tales cosas utilizando protocolos estándar? En general, sí. ¿Cuál es nuestra posición al implementar tales cosas? Se muestra en esta diapositiva.

Es decir, sí, tenemos servidores nacionales. En primer lugar, nos centramos en los sistemas operativos nacionales. Por lo tanto, sí, definitivamente hay limitaciones. La regla principal es la siguiente: si no se puede garantizar la corrección del 100% de la transferencia automática, entonces debe transferirse manualmente.

Repasemos una vez más las funciones que tenemos, basándonos, respectivamente, en esta regla.

Con respecto a las cuentas de usuario. Para hacer esto, es necesario hacer una serie de esfuerzos, en este caso, completar el campo de correo electrónico para cada miembro del servidor de correo. ¿Se puede hacer esto automáticamente? Sí, por supuesto, esto se hace en el lado del servidor de directorio. Un punto más. Como saben, TEGU no sincroniza los datos del servidor de directorio. Esta es una función fundamental, esta es una función de seguridad, esto se debe a que TEGU en el peor de los casos no puede comprometer la cuenta de nadie. Por lo tanto, la integración del servidor de directorio resulta ser unilateral. Y muy a menudo requieren funciones, por ejemplo, para ayudar al programa de correo, cambiar la contraseña del usuario. Colegas, esto es imposible, partimos del hecho de que todas las contraseñas se almacenan en el servidor de directorio, TEGU no puede cambiar ninguna contraseña en el lado del servidor de directorio.

Existe tal limitación. Sin embargo, ¿es posible la migración de cuentas de usuario? Sí, es posible. ¿Es posible la coexistencia? La coexistencia es cuando tanto el antiguo servidor de correo, como en el caso de Exchange, como el nuevo servidor de correo, en nuestro caso TEGU, funcionan simultáneamente como un único sistema de correo. ¿Es posible su coexistencia? Sí, en este caso es posible.

Mensaje IMAP de correo. ¿Es posible la migración de mensajes de correo? Sí, respectivamente, es posible. Para esto, existe una función de migración en el lado de TEGU, que, respectivamente, realiza esto. Y aquí llamo su atención sobre el hecho de que esto no se hace por medio de Exchange, sino por medio de TEGU. Y esta misma función se utiliza al migrar mensajes de correo de servidores de correo que no son Exchange, por ejemplo, servidores en la nube. Entonces sí, existe tal función, está escrita, pero implementa precisamente la coexistencia.

¿Cómo se realiza la transferencia? Para esto, recomendamos utilizar funciones de código abierto. Desde nuestro punto de vista, esta función, que se ha estado desarrollando durante mucho tiempo, está escrita muy bien. Y en el ejemplo de esta función, me gustaría llamar su atención. Mire lo que sucede cuando hacemos la integración con Exchange. Una vez que hacemos una función similar, nos condenamos a que todo el tiempo restante rastrearemos la relevancia de esta función, la compatibilidad de esta función con todas las versiones de los desarrollos de Microsoft por el resto de nuestras vidas. Y esto consumirá el 90% de nuestros recursos. Podríamos escribir algo más valioso que una migración similar, pero nos veremos obligados, de hecho, ya que hemos declarado tal función, a gastar el 90% de nuestros esfuerzos en garantizar la compatibilidad. No podemos compararnos en potencia con Microsoft, por lo tanto, simplemente no emprenderemos tal tarea. Es decir, la diferencia no es solo en garantizar esta compatibilidad una vez, la diferencia es en garantizarla con todas las versiones y ediciones, etc. Dado que si esto funciona mal, los usuarios se dirigirán a nosotros en primer lugar.

Mensajes PST de correo. ¿Se pueden escribir conversores? ¿Funcionan bien? Mal, porque es imposible lograr una compatibilidad del cien por ciento con la solución de Microsoft mediante ingeniería inversa. De una forma u otra, si hay errores en conversores similares, escríbeme, lo solucionaremos. ¿Habrá menos? Lo más probable es que no.

La migración de mensajes PST con TEGU no es posible. Recomendamos utilizar conversores de PST a IMAP o las herramientas de Outlook. El procedimiento en modo lote es prácticamente imposible.

Características del funcionamiento de los servidores DAV. Aquí también hablaremos de calendarios y libretas de direcciones. En general, Web DAV no es una solución del todo adecuada para estas funciones, pero no hay otra en los programas estándar. Web DAV es un protocolo que permite la sincronización HTTP, es decir, el intercambio en una dirección. Estos archivos en los programas de correo pueden ser calendarios y libretas de direcciones.

¿Cuál es la limitación de este protocolo? Una libreta de direcciones es un archivo, y un calendario también es un archivo. Por lo tanto, la sincronización tiene que hacerse cada vez con todo el calendario y toda la libreta de direcciones. Sí, existen extensiones que permiten sincronizar solo las actualizaciones. Pero, sin embargo, debemos estar preparados para tener que sincronizar todo el archivo también. Los archivos pueden ser de diferentes tamaños. Es decir, si hablamos de un calendario, podemos almacenar adjuntos, es decir, varios archivos binarios. Estos archivos se añaden una vez y nunca desaparecen de ahí, a menos que elimines los eventos creados anteriormente y que contengan estos archivos binarios. Por lo tanto, resulta que con el tiempo el tamaño de este archivo aumenta y, en general, puede alcanzar un tamaño muy considerable, lo que puede dificultar su sincronización. Los usuarios lo llaman fallos, es decir, se crea en un cliente, no aparece en otro cliente, desaparece, etc.

En realidad, este problema está relacionado con la sincronización, es decir, simplemente con la transferencia de este enorme archivo que contiene información que en principio ya no le sirve a nadie. Esto hay que tenerlo en cuenta al migrar de MAPI a DAV. En este caso, la migración puede causar dificultades, precisamente relacionadas con lo que he descrito antes. Por lo tanto, hay que tener mucho cuidado.

Imagínate que has sincronizado esta libreta de direcciones global con tu teléfono. ¿Admite tu teléfono 10.000 cuentas? No lo hemos comprobado. En general, es una cosa interesante.

Hablemos concretamente de las libretas de direcciones. Entonces, la implementación de libretas de direcciones globales, en general, en este caso no se requiere ninguna migración. Aquí la fuente de las libretas de direcciones son los servidores de directorio, sobre cuya base TEGU forma un archivo único y, por lo tanto, lo envía a través del protocolo CardDAV.

Aquí no se requiere la migración de GAL. La migración de contactos privados requiere esfuerzos adicionales, pero no causa dificultades. Aquí la coexistencia es posible.

Porque todos los programas de correo nacionales son forks de Thunderbird y hasta ahora no existe nada más.

Las siguientes entidades son los calendarios. La migración de calendarios automáticamente con TEGU no es posible. Ofrecemos, respectivamente, un método de exportación-importación. De nuevo, para evitar variantes de incompatibilidad. ¿Es posible la coexistencia de calendarios? Sí, hasta cierto punto es posible. Es decir, si los usuarios se invitan entre sí a reuniones, funciona bien, sin problemas y nadie sabe dónde está mi usuario, dónde se encuentra, no importa. ¿Es posible utilizar, por ejemplo, calendarios compartidos? Bueno, naturalmente, no. Si ya existe tu cuenta en TEGU, entonces, en general, estando todavía en el antiguo servidor de correo, puedes utilizar los calendarios compartidos que están alojados en TEGU.