Infraestructura de migración de etapas, intercambio y detección automática | Parte 1#2 | Parte 35#36

En el artículo actual, revisaremos el tema de la migración de la etapa Exchange y la cuestión de configurar un nuevo perfil de correo de Outlook para los usuarios cuyo buzón migró a la nube.

El presente artículo trata de la “parte teórica”, en la que revisaremos los caracteres especiales de la etapa de migración de Exchange y, el “problema” que debemos resolver para poder crear un nuevo perfil de Outlook que conectará a los usuarios migrados. su buzón de Exchange Online.

El próximo artículo incluirá una descripción de una solución sugerida que se puede implementar.

Migración de Exchange Stage e infraestructura de detección automática | la serie de artículos

La serie de artículos incluye los siguientes artículos:

• Infraestructura de migración de etapas, intercambio y detección automática | Parte 1#2 | Parte 35#36
• Conectar usuarios a su buzón de Exchange Online - Migración por etapas - Resolviendo el misterio | Parte 2#2 | Parte 36#36

Cuando se utiliza la opción de migración por etapas de Exchange, el "destino final" es migrar toda la infraestructura local de Exchange existente a la infraestructura de "correo en la nube", pero el proceso de migración, como su nombre lo indica, se implementará en "etapas". .

Una de las características principales de la migración de la etapa Exchange es que el proceso de migración de correo continuará durante un período prolongado, como semanas o incluso meses.

Durante el tiempo anterior, la infraestructura de correo de la organización estará “dispersa” por toda la infraestructura local de Exchange y la infraestructura de Exchange Online hasta que se complete la migración del correo.

Ubicación física del buzón del usuario | Migración de la etapa de intercambio

Cuando utilizamos la migración de etapa de Exchange para migrar un buzón de correo de usuario local de Exchange específico, el significado real del término "migración de buzón" es que el buzón de usuario es copiado a la nube (Exchange Online).

El resultado es que una vez completada la migración de un usuario en particular; hay dos buzones de usuario al mismo tiempo.

• Un buzón de usuario alojado en la infraestructura local de Exchange.
• Un buzón de usuario alojado en la infraestructura de Exchange Online.

En este escenario, queremos "conectar" a los usuarios cuyo buzón de correo fue migrado (copiado) a Exchange Online y evitar conectar a los usuarios a su buzón de correo "Exchange
on-Premises anterior".

Cuando usamos la opción de migración de Exchange Stage, después de haber migrado el buzón de un usuario a Exchange Online, necesitaremos crear un nuevo perfil de correo de Outlook que conecte al usuario a su buzón de Exchange Online.

Crear un nuevo perfil de correo de Outlook | La necesidad de redirigir a los usuarios a su buzón de correo en la nube

El principal problema es que cuando creamos un nuevo perfil de correo de Outlook, Outlook localizará automáticamente Exchange on-Premises y se conectará a su buzón de Exchange on-Premises.

¡El cliente Outlook “no sabe” que tenemos una copia del buzón del usuario en la “nube” (Exchange Online) y, que ahora necesita conectarse a su “buzón en la nube”!.

Nuestro principal desafío es encontrar una manera que le "indique" al cliente Outlook cómo conectarse a su "nuevo buzón de Exchange Online" en lugar del buzón local de Exchange existente.

La forma "formal" de realizar esta tarea es mediante el uso de un mecanismo integrado de Exchange, que redirigirá al cliente de detección automática a la "infraestructura de la nube" (el buzón del usuario ubicado en Exchange Online).

Para poder implementar el “mecanismo de redirección”, necesitaremos convertir el buzón del usuario local de Exchange en un contacto de correo que incluya la dirección de correo electrónico que el destinatario tiene en la infraestructura de Exchange Online.

Técnicamente, este "proceso de conversación" se puede implementar manualmente, ejecutando un conjunto de comandos, pero en realidad, la suposición subyacente es que usaremos alguna solución que nos ayudará a automatizar el proceso de conversación para docenas o incluso cientos de buzones de correo de usuarios migrados. .

La “automatización” de este proceso se puede implementar mediante el uso de un conjunto de scripts de PowerShell, que nos ayudarán a realizar el proceso de conversación en el que convertimos el buzón de correo local de Exchange en MEU (usuario habilitado para correo).

El propósito de estos scripts de PowerShell es:

1. Elimine el buzón de correo local de Exchange de los usuarios cuyo buzón migró a la nube.
2. Copie la dirección de correo electrónico del destinatario.
3. Cree un nuevo MEU (usuario habilitado para correo) que tenga la dirección de correo electrónico de los usuarios cuyo buzón migró a la nube + la dirección de correo electrónico "onmicrosoft".

Después de la complicación de este paso, cuando creamos un nuevo perfil de correo de Outlook, Outlook se dirigirá de forma predeterminada al servidor local de Exchange, pero esta vez, debido a que Exchange local no aloja el buzón del usuario, Exchange on-Premises no aloja el buzón de correo del usuario. Premises "comprenderá" que necesita redirigir el cliente de correo a su "buzón en la nube" (la dirección de correo electrónico de Microsoft).

Exchange local enviará el mensaje de redirección al cliente Outlook como parte del proceso de detección automática y Outlook comenzará de nuevo el proceso de detección automática, dirigiéndose al Infraestructura de correo Exchange Online.

¿Suena un poco complicado?

Sí estoy de acuerdo.

Según mi experiencia, el mayor obstáculo en este método es que la operación de "eliminar el buzón local de Exchange" no suena "correcta" para la mayoría de los administradores de Exchange y, la mayoría de las veces, el administrador de Exchange siente que no Necesita encontrar otra forma de realizar la tarea de conectar a los usuarios migrados a su buzón de Exchange Online, sin la necesidad de eliminar el buzón local de Exchange existente.

El objetivo principal del artículo actual y del próximo es revisar los caracteres particulares de la migración de la etapa de Exchange relacionados con el tema de conectar el cliente Outlook a su buzón de Exchange Online mediante el uso de un método que "evite" el "método formal" en el que son necesarios para eliminar los buzones de correo locales de Exchange existentes.

Cartas específicas de migración de etapa de intercambio

Antes de comenzar con la descripción de la solución opcional que podemos implementar para conectar el cliente de correo Outlook a su buzón de Exchange Online cuando utilizamos la etapa de migración de Exchange, para no revisar los caracteres base del entorno de migración de la etapa de Exchange:

1. Copiar en lugar de mover
La migración de la etapa de Exchange se basa en un concepto en el que el buzón del usuario se copia desde el servidor local de Exchange al servidor de Exchange Online. El significado es que técnicamente, cada uno de los usuarios que participa en el proceso de migración tiene dos buzones de correo.

Un buzón de correo alojado en el servidor local de Exchange y un buzón de correo adicional alojado en el servidor de Exchange Online.

2. "Consejos" de detección automática
Al implementar una migración de etapa de Exchange, no actualizamos la infraestructura DNS existente.

La infraestructura local de Exchange continúa prestando servicios a los clientes del servidor local de Exchange existentes.
Mientras continúe la migración de la etapa, la infraestructura de detección automática seguirá apuntando a la infraestructura local de Exchange.

Escenario de migración por etapas | La identidad duplicada de los usuarios migrados.

En el siguiente diagrama, podemos ver que cada usuario que migró a la nube tiene una “doble identidad” + doble buzón.
Por ejemplo, un usuario llamado Alice cuyo buzón migró a la nube, tiene una cuenta de usuario en el Active Directory On-Premise + en Windows Azure Active Directory.
En cuanto a la infraestructura de Exchange, Alice tiene un buzón que está alojado en el servidor Exchange on-Premises y al mismo tiempo, un buzón adicional que está alojado en Exchange Online. servidor.

Infraestructura local de Exchange | La infraestructura de detección automática predeterminada

Como se mencionó, cuando implementamos una migración de etapa de Exchange, la infraestructura de detección automática permanece igual. El significado es que un proceso de detección automática ejecutado por un cliente de Exchange como Outlook "conducirá" al cliente de Exchange al servidor local de Exchange.

A primera vista, este proceso parece lógico, pero en una segunda mirada podemos ver un posible problema.

Después de migrar el buzón local de Exchange a Exchange Online, debemos crear un nuevo perfil de correo de Outlook para los usuarios cuyo buzón migró a Exchange Online.

En caso de que iniciemos el proceso de "nuevo perfil de correo de Outlook", el cliente Outlook utilizará el proceso de detección automática estándar, pero el problema es que el proceso de detección automática "conducirá" al cliente de detección automática al servidor local de Exchange existente en lugar de la infraestructura de la Bolsa.

En el siguiente diagrama, podemos ver cómo un usuario llamado Alice que usa la dirección de correo electrónico: Alice@o365info.com , localiza su servidor Exchange CAS.
En caso de que Alice intente localizar su servidor Exchange CAS desde la red interna, Alice localizará el servidor Exchange CAS utilizando el SCP de Active Directory que incluye el nombre interno del servidor Exchange CAS (exo1.o365info .local en nuestro escenario).

En caso de que Alice intente localizar su servidor Exchange CAS desde la red externa, Alice determinará el servidor Exchange CAS utilizando el proceso de detección automática que se implementó en un entorno que no es Active Directory buscando un nombre de host como - autodiscover.o365info.com

En nuestro escenario, la consulta del nombre de host: autodiscover.o365info.com llevará a Alice al servidor Exchange público local de Exchange.

Evitar que el cliente Outlook se conecte al servidor CAS local de Exchange

El encabezado de esta sección parece un poco extraño, pero esto es exactamente lo que necesitamos y queremos hacer.

Una de las tareas más notables en el proceso de migración de la etapa de Exchange es la tarea en la que necesitamos "exigir" a los usuarios cuyo buzón de correo ya se haya migrado a la nube que no se conecten al servidor CAS local de Exchange y, en su lugar, conecten el Exchange. Servidor en línea.

El problema por el cual el cliente Outlook conecta el "servidor Exchange incorrecto" ocurre por una razón muy simple: el "usuario migrado" no sabe que su buzón migró a la nube.

Desde el punto de vista del cliente de detección automática, la infraestructura de detección automática todavía lo "dirige" al servidor CAS local de Exchange.

Técnicamente, su buzón de correo está en el servidor local de Exchange porque, si recuerda, cuando se utiliza la migración por etapas, el buzón de correo local de Exchange se copia a la "nube" (Exchange Online) y no se "mueve" a la nube, como por ejemplo. cuando se utiliza un entorno híbrido.

En el siguiente diagrama podemos ver un ejemplo del proceso de migración de buzones cuando se utiliza la opción de migración por etapas.

Podemos ver que después de la compilación exitosa de la migración de correo, el “buzón de Alice” existirá en dos lugares diferentes: el servidor local de Exchange + el servidor de Exchange Online.

El síndrome del buzón de usuario de migración de etapa

Un usuario de la organización informa sobre un extraño fenómeno en el que el correo que le envía no llega a su buzón, pero puede enviar correo electrónico a destinatarios externos.

Aquí está la respuesta simple a este problema: al implementar la migración de correo por etapas, el enrutamiento del correo se actualiza, de modo que cada correo que se envíe al destinatario que incluya una "dirección de correo electrónico pública estándar" se reenviará automáticamente a la "nube" ( Exchange Online) utilizando la dirección de correo electrónico del usuario en Microsoft.

El mecanismo de "reenvío automático" no deja una copia del buzón de correo local de Exchange del usuario, sino que "mueve" el mensaje de correo electrónico original a la nube (el buzón del usuario de Exchange Online).

El resultado es que después de la migración del buzón, cada correo enviado a un usuario en particular “residirá” en el buzón de Exchange Online.

En caso de que no estemos implementando los preparativos necesarios, el "usuario migrado" continuará conectándose a su buzón de correo local de Exchange.

Este buzón local de Exchange es un "buzón legítimo" y, por este motivo, el usuario puede continuar enviando correo electrónico a los destinatarios, pero el correo que se enviará al usuario se redirigirá a su "buzón de Exchange Online" y no a su Exchange. Buzón local!

La solución opcional para clientes Outlook en un entorno de migración Stage

Entonces, ahora que somos conscientes del posible problema en el que el cliente de correo Outlook continuará conectándose a su buzón de correo local de Exchange en lugar de a su buzón de correo de Exchange Online, las preguntas obvias son: ¿qué podemos hacer para solucionar este problema?

Las opciones disponibles para las soluciones se clasifican en dos tipos: lado del servidor y lado del cliente.

1. Migración escénica | Solución del lado del servidor

La solución que se describe como "Lado del servidor" se implementa mediante el siguiente procedimiento.

• Eliminar el buzón local de Exchange
• Cree un nuevo usuario habilitado para correo (MEU) que incluya la dirección de correo electrónico principal del usuario migrado y, en el valor "dirección de correo electrónico externo", use una dirección de correo electrónico adicional, la dirección de correo electrónico de Office 365 en Microsoft.

¿Suena un poco confuso?
La verdad es que esto es realmente confuso.
Como se mencionó anteriormente, cuando utilizamos una migración por etapas, el buzón de Exchange local se copia a la nube.

Después de verificar que el buzón se haya migrado (copiado) correctamente a Exchange Online, técnicamente no es necesario el buzón local de Exchange.

El proceso de migración por etapas no elimina automáticamente el buzón de correo local de Exchange.

Supongamos que después de haber leído esta información, decidimos implementar el procedimiento en el que eliminamos el buzón de Exchange On-Premise.

¿Alguna idea de qué pasará entonces?

En caso de que eliminemos el buzón del usuario, cuando intentemos crear un nuevo perfil de correo de Outlook, el asistente de correo de Outlook se conectará automáticamente al servidor local de Exchange porque, como se mencionó anteriormente, en una migración por etapas la infraestructura de detección automática sigue "apuntando" a la infraestructura local de Exchange.

En este caso, el cliente Outlook logrará conectarse al servidor local de Exchange, pero debido a que se eliminó el buzón del usuario, el intento de conexión fallará.

No olvide que el servidor Exchange On-Premise no sabe ni “entiende” que el buzón del usuario también fue copiado a la nube (Exchange Online) y por este motivo; el servidor Exchange On-Premise no sabe que necesita redirigir al destinatario a su "buzón en la nube".

En un escenario en el que solo eliminamos el buzón de correo de Exchange On-Premise sin preparativos adicionales, como crear un nuevo usuario habilitado para correo, se producirán dos problemas adicionales con el flujo de correo porque Exchange On-Premise es responsable de enrutar los correos electrónicos que se envían al buzón de Exchange On-Premise. usuario a quien se le migró su buzón a su “dirección de correo electrónico de Office 365”.

En caso de que "simplemente eliminemos" el buzón del usuario de Exchange On-Premise, Exchange on-Premise no sabrá cómo manejar el correo que se enviará a ese usuario en particular.

La segunda operación que necesitaremos implementar es: crear un nuevo usuario habilitado para correo (MEU), que actuará como "representante" del buzón migrado y tendrá la "dirección de correo electrónico del destinatario de Office 365" configurada como - Dirección de correo electrónico externa.

Después de haber eliminado el buzón de Exchange On-Premise y después de crear el nuevo usuario habilitado para correo (MEU), cada vez que el cliente Outlook intente conectarse al servidor Exchange
On-Premise, Exchange On-Premise proporcione al cliente Outlook su “nueva dirección de correo electrónico”.

Por ejemplo, Alice es un usuario cuyo buzón migró a Exchange Online.

Cuando Alice conecta Exchange On-Premise, debido a que Alice ya no tiene un buzón de correo y debido a que Exchange On-Premise tiene un usuario habilitado para correo (MEU) con detalles de Alice, Exchange On-Premise "entenderá" que necesita proporcionar Alice su "dirección de correo electrónico de Office 365". En nuestro escenario: Alice@o365info2.onmicrosoft.com

En caso de que hayamos implementado la solución “del lado del servidor”, en la que eliminamos el buzón del usuario local de Exchange + creamos un usuario habilitado para correo electrónico con la dirección de correo electrónico de Office 365, se implementará el siguiente escenario:

Cuando un cliente de correo externo intenta crear un nuevo perfil de correo de Outlook, el cliente de Outlook accederá al SCP de Active Directory local y obtendrá el nombre de los servidores Exchange disponibles (los servidores Exchange locales locales).

Cuando el cliente Outlook se dirige al servidor CAS de Exchange local, Exchange "verá" que el usuario no tiene un buzón y, en su lugar, tiene un usuario habilitado para correo electrónico.

El servidor Exchange "comprenderá" que necesita enviar un "mensaje de redirección" al cliente Outlook que incluye la dirección de correo electrónico de Office 365 (en nuestro escenario -
Alice@o365info2. enmicrosoft.com

El cliente de Outlook comprende que ahora deberá iniciar el proceso de detección automática nuevamente utilizando el nombre de dominio que extrajo de la nueva dirección de correo electrónico.

En nuestro escenario, Outlook intentará buscar un host llamado - o365info2.onmicrosoft.com y, si no puede encontrar dicho nombre de host, intentará consultar el DNS para el siguiente nombre de host: autodiscover.o365info2.onmicrosoft.com

2. Migración escénica | Solución del lado del “cliente”

Bajo la solución de clasificación del "lado del cliente", implementaremos soluciones que nos permitirán cambiar el comportamiento estándar predeterminado de Outlook.
El "comportamiento estándar predeterminado de Outlook" que queremos cambiar es: el proceso de detección automática estándar, en qué cliente de Outlook localizará y conectará el servidor CAS de Exchange local.

Para demostrar un escenario de migración por etapas estándar, usemos el siguiente ejemplo:

El dominio público de la organización es - o365info.com
Un usuario llamado Alice que tiene la dirección de correo electrónico - Alice@o365info.com , se migró a la nube.

Para poder conectar a Alice a su buzón de Exchange Online, necesitaremos encontrar una solución que impida que su cliente Outlook utilice el "proceso de detección automática estándar", que "conducirá" al cliente Outlook al servidor local de Exchange.

Proceso de detección automática interno

En el siguiente diagrama podemos ver el “desafío” al que nos enfrentamos cuando necesitamos crear un nuevo correo Outlook para un usuario cuyo buzón migró a la “nube” (Exchange Online).

De forma predeterminada, en un entorno de Active Directory, el cliente de detección automática consultará en Active Directory el nombre del servidor CAS de Exchange local.

En nuestro escenario, queremos evitar que el cliente Outlook se conecte al Active Directory local.

Supongamos que encontramos una manera de "bloquear" que el cliente Outlook se conecte al Active Directory local (número 1).

De forma predeterminada, Outlook (el cliente de detección automática) "volverá" al método en el que extrae el nombre de dominio de la dirección de correo electrónico del destinatario y utiliza este nombre de dominio como nombre de host del punto final de detección automática.

En nuestro escenario, se supone que el cliente Outlook debe consultar el DNS local para el host llamado - o365info.com (número 2) y si no encuentra un IP, el cliente de detección automática buscará un host llamado: autodiscover.o365info.com

En teoría, el servidor DNS proporcionará la dirección IP pública del servidor CAS de Exchange público.
Y nuevamente, en nuestro escenario, queremos evitar que Outlook se conecte al servidor CAS de Exchange local porque queremos que Outlook inicie la detección automática. proceso que lo “conducirá” al “servidor de Exchange en la nube” (número 3).

Proceso de detección automática externo

En el siguiente diagrama podemos ver la infraestructura del usuario de la organización (Alice) que quiere crear un nuevo perfil de correo de Outlook pero esta vez; el usuario ubicado en una red pública.

La diferencia es que ahora el usuario no puede utilizar el método de detección automática implementado en un entorno de Active Directory.

En nuestro escenario, se supone que el cliente Outlook debe consultar el DNS público para el host llamado - o365info.com (número 1) y si no encuentra un IP, el cliente de detección automática buscará un host llamado: autodiscover.o365info.com

El servidor DNS público proporcionará la dirección IP pública del servidor CAS de Exchange público.
Y nuevamente, en nuestro escenario, queremos evitar que Outlook se conecte al servidor CAS de Exchange local porque queremos que Outlook inicie el proceso de detección automática. eso lo “conducirá” al “servidor de Exchange en la nube” (número 2).

La solución del “lado del cliente”

La solución del “lado del cliente” en un entorno de migración por etapas incluye dos opciones:

Opción 1: actualizar los archivos de configuración locales

En esta opción, cambiamos el comportamiento predeterminado del cliente Outlook editando los componentes del sistema operativo: el registro del escritorio local y el archivo HOSTS local.

1. Las actualizaciones del registro incluirán un nuevo DWORD que impedirá que el cliente Outlook utilice el método de detección automática estándar en un entorno de Active Directory.
2. La actualización del archivo HOSTS incluirá un pequeño "truco" en el que asignamos el nombre de host de detección automática a una dirección IP de los componentes de Office 365 que redirigirá el cliente de detección automática al servidor de Exchange Online.

Opción 2: usar la dirección de correo electrónico de Microsoft

Cada uno de los usuarios de Office 365 que tienen un buzón de Exchange Online, tiene al menos dos
direcciones de correo electrónico:

La “dirección de correo electrónico pública”, como por ejemplo: Alice@o365info.com
y la dirección de correo electrónico de Office 365.

La dirección de correo electrónico de Office 365 se basa en el nombre del principio de Office 365 + el sufijo de dominio: onmicrosoft.com

En nuestro ejemplo, la dirección de correo electrónico de Office 365 de Alice es: Alice@o365info2.onmicrosoft.com

En un escenario en el que queremos evitar que los usuarios se conecten al servidor Exchange local, podemos usar un pequeño truco en el que proporcionamos la dirección de correo electrónico de Office 365 al crear un nuevo perfil de correo de Outlook en lugar de la dirección de correo electrónico estándar. Correo Electronico ".

Por ejemplo, en nuestro escenario, cuando necesitamos crear un nuevo perfil de correo de Outlook para el usuario Alice (cuyo buzón ya ha migrado a Exchange Online), en caso de que usemos la dirección de correo electrónico predeterminada: Alice@o365info.com, el proceso de detección automática utilizará el nombre de dominio - o365info.com y el resultado será que Outlook se conectará al servidor CAS de Exchange local.

En caso de que queramos “decirle” a Outlook que queremos implementar un proceso de detección automática diferente, usaremos la “otra” dirección de correo electrónico que tiene Alice:
Alice@o365info2. enmicrosoft.com

Cuando creamos un nuevo perfil de correo de Outlook usando esta dirección de correo electrónico (Alice@o365info2.onmicrosoft.com), el proceso de detección automática se implementará de la siguiente manera:

El cliente Outlook creará una consulta DNS buscando un punto final de detección automática llamado - o365info2.onmicrosoft.com y, en caso de que no pueda encontrar la dirección IP de dicho host, el proceso de detección automática “Pasará” a una consulta de DNS adicional, buscando un punto final de detección automática llamado - autodiscover.o365info2.onmicrosoft.com

El host: autodiscover.o365info2.onmicrosoft.com es un componente de Office 365 que redirigirá al cliente Outlook a su buzón de Exchange Online.