En los casos en que el cliente tiene una organización Exchange muy grande suele ser necesario un periodo largo de coexistencia durante el cual se van moviendo buzones desde la organización en casa del cliente (on premises) y la organización en la nube. Durante ese tiempo los correos deben seguir llegando a todos los buzones independientemente de que estén en una organización u en otra.
Existen dos aproximaciones posibles en estos casos, una sería a través de un dominio auxiliar al que se redirigirían los correos y la otra es el espacio de nombres compartido.
Vamos a configurar dos organizaciones, una 2007 que simulará nuestro cliente (el sistema origen) y otra 2010 que simulará el proveedor (o sistema destino) .
Se tratará de dos organizaciones totalmente distintas pertenecientes a dos bosques distintos. Ambas deben ser capaces de recibir correos dirigidos al mismo dominio DNS con un funcionamiento transparente independientemente de dónde se encuentre el buzón de destinatario.
El flujo de entrada del correo en el inicio de la migración será el siguiente: el correo entrará por la organización 2007 la cual comprobará si existe el buzón para el destinatario y en caso de no existir lo redirigirá la organización 2010.
El flujo de salida será el siguiente:
- Los correos dirigidos a un miembro del mismo dominio en la misma organización serán entregados localmente.
- Los correos dirigidos a un miembro del mismo dominio en la otra organización serán entregados directamente a un servidor de la otra organización a través de un canal dedicado.
- Los correos al exterior serán enrutados por cada organización que albergue el buzón origen.
sharednamespace.local MX preference = 10, mail exchanger = servidor2007.sharednamespace.local
Con el objeto de hacer que la segunda organización pueda recibir correos en un futuro crearemos un segundo registro MX para la nueva organización con un peso superior, por ejemplo 20 que apunte a la organización 2010 en el proveedor. De esta forma en caso que nuestra IP pública no esté disponible el proveedor recepcionará nuestros correos y siguiendo el flujo de correo antes comentado los entregará los buzones que el albergue o los entregará a la organización en casa de cliente (en este caso la 2007).
NOTA: Si bien para el espacio de nombres compartido no es necesaria una relación de confianza entre dominios, dado que este suele ser un proceso dentro de una migración de buzones (y esta si que lo requiere) lo normal es que tengamos una relación de confianza entre ambos bosques.
Los registros MX quedarán como sigue:
sharednamespace.local MX preference = 10, mail exchanger = servidor2007.sharednamespace.local
sharednamespace.local MX preference = 20, mail exchanger = servidor2010.miproveedor.local
Dominios autoritativos:
Para que nuestra organización acepte los correos de los buzones que hay dentro de ella pero que reenvíe los de los buzones que ya se hayan migrado o que se hayan creado directamente en el Exchange del proveedor (y viceversa) hay que configurar el espacio de nombres compartido.
Para ello debemos realizar dos pasos en cada organización.
En la organización 2007 u origen:
1. Cambiaremos el dominio aceptado sharednamespace.local del tipo "autoritativo" al tipo "dominio de retransmisión interna" (Internal Relay).
2. Crearemos un conector de envío personalizado para el dominio sharednamespace.local que apunte a la organización 2010 a través de un smarthost.
En la organización 2010 o destino realizaremos unos pasos similares:
1. Crearemos el dominio aceptado sharednamespace.local del tipo retransmisión interna.
2. Crearemos el conector de envío contra la organización 2007 a través de un smarthost.
Vamos con estos pasos.
Organización 2007 u Origen: Dominios Aceptados
En la organización 2007 (el cliente) abrimos los dominios aceptados, seleccionamos el dominio en cuestión y en propiedades cambiamos el tipo de dominio por el tipo "dominio de retransmisión interna":
Conectores de envío
Ahora vamos a la pestaña de conectores de envío o send conectors y crearemos un nuevo conector de envío para el dominio sharednamespace.local. Indicamos el tipo como internal.
Únicamente queremos que se use para el dominio especificado (no incluimos subdominios):
Indicamos que use un smarthost en lugar de la resolución MX para la entrega de correo. Indicamos la IP del servidor del proveedor que recepcionará el correo (independientemente de que se trate de un Exchange o un appliance de correo).
No especificamos seguridad ya que no es el objetivo del presente post (eso ya lo veremos en otro post más adelante):
Finalmente indicamos el servidor origen que será el HUB de la organización 2007:
Y finalizamos el asistente.
Organización 2010 o destino (el proveedor):
Ahora toca realizar los pasos en la organización 2010 (la de el proveedor):
Creamos un dominio de retransmisión interna para sharednamespace.local (dentro de dominios aceptados -> dominio aceptado nuevo -> tipo interno):
Y después en Configuración de la organización -> Transporte de concentradores -> enviar conectores -> Nuevo conector de envío.
Los pasos son los mismos pero indicando como smarthost la IP de recepción de correo del cliente y como servidor origen el del proveedor (el 2010).
Ahora podemos crear usuarios con el mismo sufijo de correo @sharednamespace.local en los dos servidores y comprobar que llegan los correos a ambos.
Para probar que todo funciona lo hacemos enviado un correo desde una de las dos organizaciones y/o desde fuera a dos usuarios uno en cada organización. Comprobaremos que el correo se recepciona en ambos destinatarios.
Flujo de correo entrante:
Ahora mismo todos los correos que llegan desde fuera entran por la organización 2007 mientras que los internos son enviados por ambas organizaciones contra la opuesta.
En el momento que se migren todos los buzones desde el Exchange 2007 al 2010 del proveedor habría que cambiar los registros MX de forma que el correo completo entre por el servidor 2010 (el del proveedor).
Los MX quedarían así:
sharednamespace.local MX preference = 20, mail exchanger = servidor2007.sharednamespace.local
De hecho una vez finalizado el periodo de coexistencia habría que eliminar el registro MX correspondiente a la organización origen (que estaría vacía de buzones) y proceder a su desinstalación.
No obstante en próximos post abordaremos la migración de buzones.
Bibliografía:
http://technet.microsoft.com/en-us/library/bb676395(v=exchg.141).aspx
http://technet.microsoft.com/en-us/library/dd876952(v=exchg.141).aspx
No hay comentarios:
Publicar un comentario