Parte 9 – Serie de artículos de migración a Exchange 2013 / 2016
Dependiendo del estado de la plataforma y de los requerimientos de la organización los distintos tipos de errores que podemos encontrar durante el proceso de migración.
En este sentido algo fundamental es verificar que la instalación actual se encuentre funcionando correctamente antes de comenzar con la migración, en particular a nivel de configuración de servicios web, certificados y Autodiscover en general.
En adición, confirmar que los clientes que se conecten al servicio se encuentren actualizados, en particular las versiones que se usen a nivel de Outlook. El tema de problemas con clientes desactualizados es más que frecuente por lo que es uno de los primeros temas a revisar.
Por fuera de esto, en esta sección voy a hacer foco en algunos errores frecuentes al hacer la transición de Exchange 2007 / 2010 a Exchange 2013 o 2016 dependiendo del caso.
(Migración de Exchange 2007) No configurar apropiadamente el registro “Legacy” para redirección de clientes
Organizaciones que migren de Exchange 2007 a Exchange 2013 deben considerar que en complemento al nombre principal para acceder a servicios como OWA se debe agregar un nuevo registro “legacy” para soportar la redirección de clientes alojados en Exchange 2007 durante la coexistencia con 2013.
Este registro “legacy” es un registro en DNS que no tiene porque llamarse “legacy” pero debe ser diferente al registro principal, por lo que si durante la coexistencia los servicios asociados a “mail.empresa.com” apuntan a un servidor con Exchange 2013, los usuarios con buzón en 2007 al conectarse por ejemplo a OWA recibirían una redirección al registro configurado como “legacy”, ya sea “legacy.empresa.com”, “mail2.empresa.com” o el nombre definido para esta función.
Este registro debe ser configurado externa e internamente. En el caso del registro configurado hacia Internet usualmente se asocia con una IP pública dedicada para este fin, pero si esto es 100% necesario depende del tipo de firewall o dispositivo en uso para la publicación de servicios. Adicionalmente, el registro definido como “legacy” debe ser incluido de algún modo en el certificado configurado en los servidores con Exchange.
De no configurar este registro o alguna de sus dependencias, varios servicios dejarían de funcionar al momento de cambiar el punto de conexión de clientes a la nueva versión de Exchange.
Certificado seleccionado para Exchange
La recomendación a nivel de certificados para Exchange es usar un certificado público, es decir uno emitido por una CA de terceros confiable, como por ejemplo Godaddy, Digicert o Comodo. El utilizar otro tipo de certificado no sería necesariamente un error pero no seguiría la recomendación oficial de Microsoft, por lo que salvo que se cuente con un buen motivo para esto no sería el camino a seguir ya que entre otras cosas podría derivar en errores a nivel de acceso de clientes.
Dependiendo del tipo de migración y el certificado que utilice la organización si es necesario solicitar uno nuevo para la transición de Exchange.
Si por ejemplo consideramos el caso de una migración de Exchange 2007 a Exchange 2013 donde ya se cuenta con un certificado de tipo wildcard (*) no sería necesario actualizar o solicitar un nuevo certificado para incluir el registro “legacy” (ya que estaría incluido dentro del “*”). Pero si se utiliza un certificado de otro tipo como por ejemplo de tipo SAN (que incluye nombres alternativos aparte del principal) si sería necesario hacer una nueva solicitud para incluir este registro “legacy” adicional.
Si se migra a Exchange 2016 ya sea desde Exchange 2010 o Exchange 2013 y ya se cuenta con un certificado confiable e incluye todos los nombres requeridos para acceder a los servicios del correo, no sería necesario hacer cambios porque en este caso los nuevos servidores actúan como proxy hacia Exchange 2010 por lo que no se utilizaría un registro “legacy” para redirección de usuarios.
El tema de certificados lo amplio en detalle en la siguiente guía gratuita:
Sobre Reglas de Transporte…
Las reglas de transporte nos habilitan a por ejemplo agregar un disclaimer al pie de todo correo saliente (entre otras acciones), “Si usted ha recibido este correo por error elimínelo inmediatamente…”.
Si se migra de Exchange 2010 a Exchange 2016 no debería haber problemas con esto (salvo en algún caso muy particular), en cambio si se está haciendo la transición desde Exchange 2007 a Exchange 2013 debemos considerar pasos adicionales para que estas continúen funcionando una vez finalizada la migración.
Esto implica la exportación de las reglas en Exchange 2007 e importación manual luego en Exchange 2013.
El proceso se encuentra descrito en el KB2846555 de Microsoft:
Aplicaciones y dispositivos que envían correo a través de Exchange
Una situación frecuente en ambientes corporativos es que existan aplicaciones o dispositivos que envíen correo a través de Exchange. En algunos casos se configuran apuntando a una dirección IP y en otros a nombres DNS, independientemente del modo antes de dar de baja la versión anterior de Exchange es necesario hacer ajustes a nivel de transporte para evitar errores de envío de correo. En particular en la configuración predeterminada, errores asociados al relay. En este caso y dependiendo del tipo de conexión (anónima o autenticada) puede ser necesaria la creación de conectores adicionales.
Para evitar esta situación es conveniente relevar los casos que requieran enviar correo a través de Exchange y hacer las modificaciones correspondientes en 2013 / 2016 e incluso en las aplicaciones o dispositivos existentes para conectarse con la nueva versión.
Se debe prestar especial atención cuando se configura el relay en Exchange, si por ejemplo se habilita relay anónimo (restringiendo por dirección IP), un error en la configuración puede dejar el servidor en un estado de Open relay (relay abierto) lo que podría derivar en varios problemas incluyendo que las direcciones IP que se utilicen para enviar correo externo terminen en listas negras con las consecuencias que esto implica.
Más información sobre configuración de relay en el siguiente artículo:
Por último, qué hacer cuando un buzón no migra “bien”?
Esto lo vemos en el próximo artículo, en el punto #10 de esta serie.
Volver a la serie de artículos «10 cosas que tenés que saber antes de migrar a Exchange 2013 / 2016«
Te puedo hacer una consulta con respecto a los certificados de seguridad, tengo 1 exchange 2013 con un certificado del tipo wildcard instalado, pero al momento de conectarse los clientes me indica que hay un problema en el certificado, el cual hace alusión a que el nombre del certificado de seguridad no es valido o no coincide con el nombre del sitio.
el nombre que le puse a este exchange fue exchange2013saf.ad.saf y el common name es *.saf.cl
Tienen que coincidir los nombres ? me pasa exactamente lo mismo tanto con un wildcard como con un certificado normal emitido por una CA con todas las SAN asociadas.
Hola Carlos, todos los nombres configurados deben estar incluidos en el certificado.
De forma predeterminada al instalar Exchange, los servicios quedan configurados con el FQDN del servidor (ej: servidor.dominio.local). La idea es que se cambie la configuración de los servicios para que quede asociada al nombre que utilizan para conectarse los clientes. Esto requiere configuración a nivel de Exchange, un certificado válido (que puede ser de tipo wildcard o SAN por ejemplo) y en general Split DNS configurado.
Te dejo más info sobre split DNS en el siguiente artículo:
https://aprendiendoexchange.com/split-dns-con-exchange
Y también sobre certificados:
https://aprendiendoexchange.com/certificados-en-exchange-2013