Migración de correo por transferencia, Exchange local, requisitos previos | Migración completa de correo de Office 365: requisitos previos de Exchange local.com

La causa más común de un escenario en el que no podemos iniciar el proceso de migración de correo de Office 365 es la falta de requisitos previos de Exchange local.
Los objetivos principales del artículo actual son:

1. Proporcione la lista de verificación de los requisitos previos locales de Exchange
2. Explique en detalle los motivos de cada requisito previo de Exchange local.
3. Proporcionarle herramientas que le ayudarán a verificar la existencia de requisitos previos locales de Exchange.

Migración de correo de Office 365 La puerta de la manada.

El denominador común de la mayor parte del proyecto de migración de correo de Office 365 es lo que describí como el "rebaño de carreras".

El proyecto de migración de correo se ejecuta a toda prisa; Anhelamos "presionar el botón de migración de correo", sin ninguna preparación y sin ningún conocimiento previo sobre "temas aburridos" como: requisitos previos a la migración de correo, requisitos obligatorios, mejores prácticas, etc.

En caso de que la suerte esté de nuestro lado, el proceso de migración de correo electrónico se está ejecutando exitosamente, pero muchas veces, la “señora de la suerte” no viene y el proceso de migración de correo electrónico no comienza.

Los prerrequisitos previos a la migración de correo son la “pequeña cosa” que marca la diferencia entre un proyecto de migración de correo fluido y eficiente a la nube frente a un escenario en el que no somos capaces de cumplir con los plazos de migración de correo a Office 365 y la memoria de la migración a Office 365, deja un sabor amargo en la boca.

El alcance del artículo actual.

Fases de migración de correo de Office 365

El proyecto de migración de correo a Office 365 mediante migración cutover, incluye tres grandes fases:

1. Tareas previas a la migración
2. El proceso migratorio
3. Tareas posteriores a la migración

En el artículo actual, nos centramos únicamente en la primera fase en la que preparamos nuestro entorno y nuestra infraestructura de correo para el proceso de migración de correo de Office 365.

Clasificación de requisitos previos a la migración de correo de Office 365

La "primera fase" de la migración de correo electrónico de Office 365 puede incluir un par de partes, como: conocer los caracteres específicos de la migración de correo electrónico, crear un laboratorio para probar el proceso de migración diseñado y verificar que se cumplan todos los requisitos previos.

La fase de “requisitos previos a la migración de correo” también se puede dividir en diferentes secciones como:

• Requisitos previos del escritorio del usuario
• Requisitos previos de infraestructura de red
• Requisitos previos de infraestructura de Office 365
• Requisitos previos de Exchange local

En el artículo actual, nos referiremos únicamente al tema de los requisitos previos de Exchange on-Premises.

Office 365 diferentes tipos de migración de correo

Office 365 ofrece tres tipos integrados de opciones de migración de correo desde el servidor local de Exchange:

1. Migración de correo por transferencia
2. Migración de correo en etapas
3. Migración de correo híbrido de Exchange

El artículo actual está dedicado a la migración de correo de Office 365 y los requisitos previos del servidor local de Exchange.
Lo importante que debemos saber es que los "requisitos previos del servidor local de Exchange
" que son relevantes a la migración de correo de Office 365 son relevantes y casi idénticos al resto de las migraciones de correo de Office 365.

El factor de disponibilidad pública local de Exchange

Todos los diferentes tipos de opciones de migración de correo de Office 365 dictan la necesidad obligatoria en la que el servidor local de Exchange deberá tener una "presencia pública", que se traduce en:

1. Dirección IP pública.
2. Nombre público.
3. Certificado público.

El protocolo de migración de correo

En cuanto al tema del “protocolo de migración de correo” los métodos de migración de correo de Office 365 se clasifican de la siguiente manera:

La migración de correo de transición de Office 365 y la migración de correo de transición de Office 365 se implementan mediante el protocolo Outlook Anywhere. El servidor de Exchange Online "buscará" los buzones de correo locales de Exchange utilizando el protocolo RPC sobre HTTPS (Outlook Anywhere).

La migración de correo híbrido de Office 365 Exchange se implementa a través de la interfaz EWS (servicios web de Exchange) local de Exchange. En otras palabras, el entorno híbrido de Exchange no necesita utilizar el protocolo RPC sobre HTTPS (Outlook Anywhere) para la migración de correo.

¿Cuál es el significado exacto de “migración de correo”?

Antes de continuar con la descripción de la migración de correo de Office 365, es importante que estemos de acuerdo en la definición del término "migración de correo".

La primera asociación que nos viene a la mente con respecto al término "migración de correo" es: una migración de buzones de Exchange.

Esta asociación es parcialmente cierta porque el buzón de Exchange no tiene vida propia.

El significado es que el buzón de Exchange debe estar "adjunto" o "conectado" a una cuenta de usuario.

El proceso de migración de correo de Office 365 está diseñado para implementar un proceso de migración que creará dos "canales de migración" separados.

1. Proceso de migración de cuenta de usuario/grupo

Un canal de migración es: la cuenta de usuario y grupo que se copiará de Active Directory local a Windows Azure Active Directory.

2. Proceso de migración de buzones de correo local de Exchange

El segundo canal de migración es el proceso de buzones de correo de Exchange, en el que todos los
buzones de correo locales de Exchange (100 %) se copiarán a la infraestructura de Exchange Online.

Migración de correo electrónico de Office 365: migración de usuarios y buzones de correo

Un detalle adicional que me gustaría enfatizar es que el término "migración" se traduce en una operación de copia y no en una operación de movimiento.

Cuando decimos migración de correo mediante transición de Office 365, el término "transición" puede ser engañoso porque, en realidad, no "cortamos" los buzones de correo locales de Exchange (mover), sino que copiamos el contenido del buzón de correo local de Exchange al servidor de correo de Exchange Online.

Durante todo el proceso de migración de correo de Office 365, habrá dos buzones de correo de usuario al mismo tiempo.

El “buzón de Exchange original” almacenado en Exchange local y la copia de los buzones de correo de los usuarios que se almacena en Exchange Online.

¿Cuáles son los requisitos previos obligatorios del servidor local de Exchange?

Más adelante, revisaremos en detalle cada uno de los "requisitos previos" que el servidor local de Exchange debe admitir para implementar la migración de correo de Office 365.

En pocas palabras, los requisitos previos de Exchange local más esenciales y obligatorios son:

1. Disponibilidad pública
2. Admite las opciones Outlook en cualquier lugar.

Para poder simplificar el proceso de migración de correo electrónico, podemos utilizar una metáfora en la que el servidor de Exchange Online extiende su mano, golpea la red de su organización y solicita una copia de todos los usuarios, grupos y contactos locales de Active Directory. y todos los buzones de correo de los usuarios almacenados en los servidores locales de Exchange.

El representante de la organización que se comunica con “Office 365” es el
servidor local de Exchange.

Para poder habilitar este canal de comunicación entre Office 365 y su servidor Exchange local, Exchange local deberá tener disponibilidad pública.

El término “disponibilidad pública” se traduce en tres componentes diferentes:

1. IP pública: una dirección IP pública a la que pueden acceder hosts externos. La
   dirección IP pública local de Exchange se “asignará” al nombre público local de Exchange.
2. Nombre público: el término más preciso es FQDN (nombre de dominio completo). El servidor local de Exchange deberá utilizar un nombre público que los hosts externos, como Exchange Online, utilizan para dirigirse a nuestro servidor local de Exchange. Por ejemplo: o365info.com
3. Certificado público: técnicamente hablando, el certificado del servidor no está directamente relacionado con el proceso de comunicación con el servidor local de Exchange porque todo lo que realmente necesitamos es solo una dirección IP pública. La razón por la que “envolvemos” el certificado público con el término “disponibilidad pública” es porque la necesidad de un certificado de servidor público válido es un requisito obligatorio de la migración de correo de Office 365.

Migración definitiva de correo | Fase A

La migración de correo de Office 365 se inicializó desde el “lado de Office 365” (portal de administración de Exchange Online) que necesita ubicar y comunicarse con el servidor local de Exchange.

El canal de comunicación entre Exchange Online y Exchange local debe implementarse como un canal de comunicación seguro (cifrado mediante SSL).

El establecimiento del canal de comunicación servirá para el propósito de - copiar información del servidor On-Premise de Active Directory y Exchange on-Premise.

1. Localización de nuestro servidor local de Exchange

Como se mencionó, el proceso de migración de correo de Office 365 se inicializa desde el lado de Office 365 que "extiende su mano" y accede al servidor local de Exchange.

Para permitir que la migración de correo de Office 365 localice nuestro servidor Exchange local, debemos proporcionar a la migración de correo de Office 365 la información requerida.

El método preferido\recomendado es utilizar el proceso de detección automática.
Dado que nuestro servidor Exchange local tiene la configuración requerida para la detección automática, cuando creamos el lote de migración de correo total, Office 365 usará el "nombre de dominio" de el mensaje de correo electrónico que le proporcionaremos para localizar “nuestro” servidor local de Exchange.

En caso de que nuestro servidor local de Exchange no admita la detección automática o la configuración de detección automática sea incorrecta, podemos proporcionar a Office 365 la información requerida sobre el servidor local de Exchange manualmente.

2. Comunicarse con el servidor local de Exchange.

Después de que la migración de correo de Office 365 localice nuestro servidor local de Exchange, necesita "hablar" con el servidor local de Exchange con el fin de solicitar una copia de los usuarios de Active Directory locales existentes y los buzones de correo locales de Exchange.

El requisito obligatorio para el canal de comunicación del lado de Office 365 es que la comunicación se implementará mediante el protocolo HTTPS (puerto 443).

El servidor local de Exchange deberá identificarse proporcionando un certificado público válido.

Migración definitiva de correo | Fase B

El canal de comunicación entre Office 365 y el entorno On-Premises (Exchange on-Premises) se implementa mediante el protocolo SSL.

El proceso de migración real se implementa mediante el protocolo RPC. El protocolo RPC está colocado "encima" del protocolo SSL.

Esta implementación, descrita como encapsulación (el método de usar un protocolo que usa un protocolo adicional) y en un entorno basado en Exchange, este método se describe como RPC sobre HTTPS.

El nombre descriptivo de este método es: Outlook Anywhere.

1. Exchange local y Outlook en cualquier lugar

Para poder implementar la migración de correo total, Exchange local deberá ser compatible con Outlook en cualquier lugar.

Outlook Anywhere no exige la necesidad de un certificado público, pero la migración de correo de Office 365 sí.

2. Intercambio en línea | Las credenciales de usuario requeridas

La migración de correo de Office 365 se basa en el supuesto de que podremos copiar todo el contenido de Active Directory local (no todo el contenido, pero sí la mayor parte) y todos los buzones de correo locales de Exchange.

Cuando definamos la configuración de migración de correo de Office 365 (punto final de migración), necesitaremos proporcionar un nombre de usuario + credenciales de usuario que serán utilizadas por la migración de correo de Office 365 cuando se conecte a nuestro servidor Exchange local.

El término técnico para el "usuario" que proporcionaremos a la migración de correo de Office 365 es: administrador de migración.

Para una migración total, la cuenta del administrador de la migración debe ser:

Miembro del grupo Administradores de dominio en Active Directory en la organización local.

O

Se asignó el permiso FullAccess para cada buzón local.

O

Se asignó el permiso Recibir como en la base de datos de buzones de correo local que almacena los buzones de correo de los usuarios.

Intercambiar certificado local

Una necesidad obligatoria de la migración de correo de Office 365 es la necesidad de que el servidor local de Exchange utilice un certificado público válido.

En muchos escenarios, esta necesidad obligatoria molesta a la persona responsable del proceso de migración de correo de Office 365 porque no todas las organizaciones utilizan un certificado público válido. Otro escenario posible es un escenario en el que la organización usa
un certificado local de Exchange, pero usa un certificado público (certificado que no fue inscrito por una autoridad de certificación pública).

P1: ¿Existe alguna forma de implementar la migración de correo de Office 365 sin utilizar un certificado válido público local de Exchange?

A1: No, este es un requisito obligatorio

P2: ¿Cuál es el significado de “certificado público válido”?

A2:

• El significado de "certificado público" es: un certificado adquirido de una CA (autoridad de certificación) pública reconocida.
• El significado de "certificado válido" es: un certificado que tiene una fecha de vencimiento válida + un nombre de host válido o un nombre de dominio válido.

P4: ¿Por qué la migración de correo por transferencia “insiste” en utilizar un certificado público?

A4: La migración de correo de Office 365 requiere verificar que el servidor local de Exchange tenga un certificado público por dos razones principales:

1. Privacidad e integridad de los datos

La migración de correo de Office 365 se implementa a través de una infraestructura de red pública que se considera un entorno no privado o no seguro. Para poder satisfacer las necesidades de seguridad más básicas para la privacidad y la integridad de los datos, la migración de correo de Office 365 se implementa mediante el protocolo SSL. La implementación del protocolo SSL requiere un certificado de servidor.

2. La necesidad de autenticación e identificación

Aunque utilizamos el término "nuestro servidor local de Exchange", Office 365 realmente no conoce ni confía en nuestro servidor local de Exchange.

Cuando utilizamos SSL, el mecanismo que utilizamos para satisfacer la necesidad de verificar la identidad de una entidad en particular es mediante el uso de un certificado público registrado por una CA pública.

Cuando la migración de correo de Office 365 conecta el servidor local de Exchange, Office 365 deberá estar seguro, más allá de toda duda, de que el servidor local de Exchange que representa un dominio en particular es realmente quien dice ser.

La capacidad de probar la identidad del servidor local de Exchange se implementa cuando Exchange local muestra un certificado público válido proporcionado por una CA en la que Office 365 confía.

P5: ¿Qué tipo de certificado público puede utilizar el servidor local de Exchange?

A5: Se podría necesitar un certificado de servidor válido.

Certificado SAN (nombre alternativo del sujeto) o un certificado comodín.

Caso 1: uso de un certificado SAN

El certificado SAN incluye información sobre los hosts que están autorizados a utilizar el certificado. La información sobre este host aparece como FQDN (nombre de dominio completo).

En un entorno basado en Exchange, ese certificado SAN deberá incluir al menos dos nombres de host (FQDN):

1. El nombre público del servidor local de Exchange.
2. El nombre de host de detección automática que representa un nombre de dominio específico.

Por ejemplo: en nuestro escenario específico, el nombre de dominio de la organización es o365info.com

• El nombre público del servidor local de Exchange es: mail.o365info.com
• El nombre de host de detección automática es: autodiscover.o365info.com

Caso 2: uso de un certificado comodín

En caso de que utilicemos un certificado comodín, el certificado “cubre” todos los hosts en un nombre de dominio específico.

Por ejemplo, un certificado comodín para el nombre de dominio incluirá la siguiente información: *.o365info.com

Todos los nombres de host que aparecen "debajo" de este nombre de dominio, como "correo" (el nombre de host de nuestro servidor Exchange local) o Autodiscover, se consideran un nombre de host válido que está autorizado a utilizar el certificado.

Verificar mi certificado de servidor local de Exchange

Como se mencionó, el requisito obligatorio de la migración de correo de Office 365 es que el servidor local de Exchange utilice un certificado público válido.

En la siguiente sección, me gustaría revisar brevemente un certificado público SAN "estándar" y mostrar las partes del certificado que debemos verificar.

Validación de fecha del certificado

El parámetro más básico que debe verificarse con un certificado de servidor es el asunto de la fecha de validación del certificado.

Cuando seleccionamos la pestaña general, podremos ver la sección denominada - válido desde, que el certificado específico es válido hasta el 2/2/2018

Certificado y el anfitrión nombrado

En nuestro escenario específico, el nombre de dominio de la organización es: o365info.com

El nombre de host público del servidor local de Exchange es: mail.o365info.com
el registro de detección automática para el dominio o365info.com es: autodiscover .o365info.com
Cuando seleccionamos la pestaña detalles, podemos ver la sección denominada - Nombre alternativo del sujeto, los nombres de host que se incluyen en el Certificado SAN.

En nuestro escenario buscamos

• Un nombre de host de detección automática válido

• Un nombre público local de Exchange válido: nombre de host

Certificado y CA pública (autoridad certificadora).

Como se mencionó, cuando se utiliza la migración de correo de Office 365, el certificado del servidor local de Exchange debe ser un "certificado público" proporcionado por una CA pública.

Cuando seleccionamos la pestaña Ruta del certificado, podemos ver la sección denominada - Ruta del certificado, podemos ver información sobre la CA pública que proporciona el certificado. En nuestro escenario específico, la CA pública es
- Go Daddy.

P6: En el caso de que mi servidor Exchange local no incluya el certificado de servidor, ¿pueden indicarme cómo comprar e instalar el certificado de servidor requerido?

R6: El tema de “cómo instalar un certificado de servidor en el servidor local de Exchange” está fuera del alcance de nuestro artículo actual.

El canal de comunicación entre Exchange Online y el servidor local de Exchange

Una “parte” adicional que me gustaría agregar a nuestra lista de verificación de migración de correo de Office 365 es la necesidad obligatoria de permitir que hosts externos como Office 365 y Exchange Online accedan al servidor local de Exchange a través del puerto 443 (SSL).

En realidad, el servidor local de Exchange no está "expuesto" a la red externa ni se comunica directamente con hosts externos como Exchange Online.

El acceso al servidor local de Exchange implementado a través de la mediación de servidores Firewall o Proxy, que representan nuestros hosts internos.

Cualquier solicitud de comunicación de hosts externos llegará al Firewall y será "reenviada" al "servidor interno Exchange local".

En pocas palabras: para poder iniciar la migración de correo de Office 365, Exchange Online deberá acceder al servidor local de Exchange mediante el puerto 443.

Versión del servidor local de Exchange

P7: ¿Cuál es la versión del servidor local de Exchange que admite la migración de correo de Office 365?

A7: Todas las versiones existentes del servidor Exchange local a partir de
Exchange local 2003.
Técnicamente hablando, Exchange 2003 local ya no es compatible, pero no Esto significa que no puede intentar utilizar la migración de correo de Office 365 y lo más probable es que si Exchange 2003 incluye todos los requisitos previos, la migración de correo de Office 365 se complete exitosamente.

P8: ¿El servidor local de Exchange necesita incluir un paquete de servicio específico, un paquete acumulativo específico o una actualización acumulativa específica?

R8: Lo interesante con respecto al tema de los requisitos mínimos del sistema del servidor local de Exchange para implementar la migración de correo de Office 365 es que, hasta donde yo sé, no existe ningún artículo formal que defina este Exchange. Requisitos de software local.

Mi respuesta a esta pregunta es - la regla general que dice - cuanto más actualizada sea la versión, mejor.

Por ejemplo, en caso de que su servidor Exchange local sea un servidor Exchange 2010, la versión de software recomendada es Exchange service pack 3 + Exchange 2010 Rollup 32.

Esto no significa que un paquete acumulativo más bajo no funcione, pero en caso de que queramos maximizar nuestras posibilidades de implementar un proceso exitoso de migración de correo de Office 365, el paquete acumulativo de Exchange 2010 más avanzado aumenta la probabilidad de un proceso de migración de correo exitoso.

Servidor local de Exchange y protocolo Outlook Anywhere

Como se mencionó, el requisito obligatorio para implementar la migración de correo de Office 365 es que Exchange local sea compatible con la función Outlook Anywhere.

En caso de que su Exchange local no admita la opción Outlook Anywhere o en caso de que no esté familiarizado con la opción Outlook Anywhere, aquí hay una breve revisión de las configuraciones de Outlook Anywhere tal como aparecen en Exchange 2010 y Exchange. 2013.

Intercambio 2010

En Exchange 2010, activamos la función Outlook Anywhere utilizando la siguiente ruta:

Configuración del servidor => Acceso del cliente => Habilitar Outlook en cualquier lugar

En la siguiente captura de pantalla, podemos ver que Outlook Anywhere ya estaba habilitado.

Si queremos ver la configuración de Outlook en cualquier lugar, podemos seleccionar el menú propiedades.

En la siguiente captura de pantalla, podemos ver un ejemplo de la configuración de Outlook Anywhere.

El nombre de host que aparece en la sección “Nombre de host externo” es el nombre de host al que se dirigirá Outlook.

Intercambio 2013

En Exchange 2013, activamos la función Outlook Anywhere utilizando la siguiente ruta:

servidores => servidores => <Servidor nombre>

En la siguiente captura de pantalla, podemos ver que Outlook Anywhere ya estaba habilitado.

En la siguiente tabla, puede encontrar enlaces a artículos que incluyen pautas sobre los pasos que se deben implementar para "activar" la función Outlook en cualquier lugar en diferentes versiones del servidor Exchange:

Verificación del servicio Outlook en cualquier lugar mediante el Analizador de conectividad remota.

Antes de comenzar el proceso de migración de correo de Office 365, la mejor práctica es probar y verificar que nuestro Exchange local admita la opción Outlook Anywhere y que podamos implementar exitosamente una sesión exitosa de Outlook Anywhere con nuestro Exchange local.

La buena noticia es que contamos con una herramienta web muy útil para este propósito
llamada Analizador de conectividad remota.

El Analizador de conectividad remota es una herramienta útil y potente basada en la web de Microsoft que se utiliza para probar muchos servicios diferentes de Exchange local y Exchange Online.

La característica más poderosa de la herramienta Remote Connectivity Analyzer es la capacidad de proporcionar un informe detallado sobre "lo que sucede detrás de escena" de protocolos de comunicaciones específicos.

En caso de que el proceso de comunicación falle, podemos utilizar la información del informe para encontrar la posible causa del fallo de comunicación.

En nuestro escenario, antes de comenzar la migración de correo de Office 365, queremos verificar que:

1. La función Outlook Anywhere está habilitada en nuestro servidor local de Exchange.
2. Ese cliente externo puede conectarse a Exchange local utilizando el protocolo Outlook Anywhere (RPC\HTTPS).

En la siguiente sección, demostramos los pasos que se deben implementar para utilizar la herramienta Analizador de conectividad remota para verificar la conectividad de Outlook en cualquier lugar.

Para acceder a la herramienta Remote Connectivity Analyzer, utilizaremos la siguiente dirección URL: https://testconnectivity.microsoft.com

• Seleccionaremos la pestaña Exchange
• En la sección denominada- Pruebas de conectividad de Microsoft Office Outlook, seleccionaremos la opción - Conectividad de Outlook.

En la siguiente pantalla, necesitaremos proporcionar las credenciales de usuario que representan al destinatario de Exchange local que necesita acceder a su buzón.

• En la sección Dirección de correo electrónico, proporcionaremos la dirección de correo electrónico del destinatario: david@o365info.com (número 1).
• En la sección dominio\nombre de usuario (o UPN), escribiremos las credenciales del usuario en un formato basado en UNC -o365info\david (número 2).
• Le proporcionaremos la contraseña de usuario (número 3).

De forma predeterminada, la prueba de conectividad de Outlook intentará utilizar la opción de detección automática (use la detección automática para detectar la configuración del servidor).

• Tendremos que marcar la casilla en la que aprobamos que la herramienta Remote Connectivity Analyzer está autorizada a utilizar nuestras credenciales (número 1).
• Tendremos que anotar las lentejuelas captcha y seleccionar Verificar

Para inicializar las Pruebas de Conectividad de Microsoft Office Outlook, seleccionaremosRealizar prueba

En la siguiente captura de pantalla, podemos ver que las pruebas de conectividad de Microsoft Office Outlook se están ejecutando (la herramienta Analizador de conectividad remota está intentando acceder a nuestro servidor Exchange local y conectarse al buzón de David utilizando el protocolo Outlook Anywhere).

En la siguiente captura de pantalla, podemos ver que las Pruebas de conectividad de Microsoft Office Outlook se completaron con éxito.
El significado es que Exchange local admite los servicios de Outlook en cualquier lugar y que Pudimos acceder al buzón del destinatario.

Observe la pequeña flecha blanca que aparece a la izquierda del resultado.
La información que se muestra de forma predeterminada es solo el resumen del resultado de la prueba. En caso de que queramos obtener información detallada de cada uno de los pasos que se incluyeron en la simulación, podemos hacer clic en la pequeña flecha blanca y la información se ampliará.

En la siguiente captura de pantalla podemos ver que hemos hecho clic en la flecha pequeña.

El resultado de la prueba se amplió y ahora podemos ver que las pruebas de conectividad de Microsoft Office Outlook constan de dos partes diferentes:

La prueba de detección automática que se utilizó para localizar y conectar el servidor local de Exchange y la segunda parte, que es el canal de comunicación de Outlook Anywhere.