Problemas frecuentes al migrar a Exchange 2013 o 2016

Publicado el 09 febrero 2018 por Aprendiendoexchange

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.

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.

Certificado seleccionado para Exchange

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.

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.

Sobre Reglas de Transporte...

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:

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.

Aplicaciones y dispositivos que envían correo a través de Exchange

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:

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:

Volver a la serie de artículos "10 cosas que tenés que saber antes de migrar a Exchange 2013 / 2016"

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.