Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 2/3
El siguiente artículo es la parte 2 de la lista de verificación de configuración híbrida y la serie de artículos sobre requisitos previos. En el siguiente artículo, revisamos los "componentes" adicionales que están involucrados y se relacionan con el entorno híbrido:
- Servicios EWS del servidor local de Exchange
- Servicios de detección automática del servidor local de Exchange
- Servidor local de Exchange y certificado público
Implementación híbrida Office 365: la serie de artículos
La serie de artículos incluye los siguientes artículos:
- Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 1/3
- Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 2/3
- Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 3/3
7. Servidor híbrido local de Exchange | Servicio de descubrimiento automático
El servicio Autodiscover sirve como "base" para las "relaciones híbridas" entre Exchange On-Premise y Exchange Online y viceversa.
El servicio de detección automática se utilizará para la configuración por primera vez del entorno híbrido (cuando se utiliza el HCW) y para la comunicación continua entre el entorno local y el de la nube.
Por este motivo, es fundamental verificar y comprobar la siguientes secciones que se relacionan con los servicios de detección automática:
1. Registro de detección automática y red pública
Necesitaremos verificar que el registro de detección automática para el dominio público de la organización esté publicado y apunte al servidor local de Exchange.
El registro de detección automática se basa en una convención de nomenclatura reservada. Implementado de la siguiente manera: Detección automática
Por ejemplo, el registro de detección automática para el dominio público o365info.com es: Autodiscover.o365info.com
Necesitaremos verificar y verificar que el registro de detección automática se haya publicado correctamente y que el registro de detección automática apunte al servidor local de Exchange.
En el siguiente diagrama, podemos ver una descripción del proceso de detección automática.
En nuestro ejemplo, Exchange Online necesita obtener información sobre la organización o365info.com.
Para obtener la información requerida, Exchange Online accede a un DNS público y consulta sobre el registro Autodiscover.o365info.com .
En caso de que el registro DNS de detección automática esté configurado correctamente, el registro DNS proporciona la IP pública y Exchange Online utiliza esta IP para comunicarse con los servicios de detección automática local de Exchange.
Nota: En esta sección nos relacionamos únicamente con la configuración de DNS para el servicio Detección automática y en el resto de la sección revisamos otros aspectos del servicio Detección automática que debemos verificar y comprobar.
Descubrir automáticamente el registro DNS | Un expediente
En un entorno híbrido, la detección automática debe implementarse como un registro A que se publica a través del servidor DNS público.
En algunos escenarios, la configuración de detección automática local de Exchange se basa en el registro SRV. Este escenario no es compatible con el entorno híbrido.
En otras palabras: en caso de que la detección automática local de Exchange actual se base en un registro DNS SRV, deberá cambiar/actualizar esta configuración a una "configuración de detección automática estándar" que se implemente mediante el uso de un registro que apunte al público. Dirección IP del servidor local de Exchange.
También deberá incluir estos registros en el certificado SAN. Podría usar registros CNAME para la redirección de detección automática, pero eso no cambiaría el hecho de que debe agregar todos los registros de detección automática al certificado SAN. Además, las implementaciones híbridas de Exchange no admiten la redirección de detección automática basada en SRV.
Verifique el funcionamiento exitoso del proceso de detección automática local de Exchange
El hecho de que se publiquen el registro de servicios de detección automática y la IP pública es solo la primera parte de la configuración requerida. En el siguiente paso, debemos verificar que podemos acceder al servicio de detección automática de Exchange On-Premise y obtener la información requerida (Exchange On-Premise proporcionará la información requerida mediante un archivo XML).
En el siguiente diagrama, podemos ver que el host externo (como Exchange Online) intenta conectarse al Exchange local (los servicios de detección automática del servidor local de Exchange).
En caso de que el servidor local de Exchange “responder”, Exchange Online deberá identificarse y, después de una autenticación exitosa, Exchange On-Premise proporciona la información requerida utilizando un archivo llamado - autodiscover.xml
Verificar la disponibilidad del servicio de detección automática local de Exchange
La verificación del servicio de detección automática local de Exchange se puede implementar mediante una herramienta muy poderosa y recomendada llamada Microsoft Remote Connectivity Analyzer (MRCA).
En la siguiente sección, revisamos un ejemplo de los pasos necesarios que debemos implementar para verificar la disponibilidad del servicio Exchange On-Premise AutoDiscover.
- Elija la pestaña del servidor Exchange y luego, en "Pruebas de conectividad de Microsoft Office Outlook", elija la opción: Detección automática de Outlook.
- Proporcione las credenciales de usuario de Exchange On-Premise.
Para poder obtener la información requerida, necesitaremos proporcionar las credenciales de usuario de los usuarios que tienen un buzón de correo de Exchange On-Premise.
En nuestro ejemplo, utilizamos las credenciales de los usuarios. llamado: Usuario2
- En la pantalla de resultados, podemos ver que el encabezado es: “Prueba de conectividad exitosa con advertencia”.
Este es el “resultado requerido”, a pesar de que el resultado incluye un “signo de exclamación amarillo”. La prueba de detección automática incluirá de forma predeterminada algunos errores menores, causados por el mecanismo de "prueba y error" del proceso de detección automática.
El hecho de que obtengamos el "icono verde" es la indicación de la implementación exitosa del proceso de detección automática. .
- En caso de que queramos obtener información más detallada, podemos hacer clic en "Paso de prueba".
En la siguiente captura de pantalla, podemos ver el contenido del archivo XML de detección automática.
3. Versión del servidor local de detección automática y Exchange
En un entorno mixto de Exchange On-Premise, que incluye un par de versiones de Exchange On-Premise, tendremos que verificar que el registro de detección automática "apunte" a la versión más actualizada del servidor Exchange On-Premise.
Técnicamente, cada uno de los servidores Exchange desde la versión 2007 de Exchange puede proporcionar servicios de detección automática, pero el motivo por el que ese servidor Exchange "prepara" los datos requeridos (el archivo XML) y el contenido del "archivo de detección automática" se crea e implementa en un forma diferente en cada una de las versiones del servidor Exchange.
En un entorno mixto de Exchange, se implementa el concepto de “computabilidad hacia atrás”.
La “última” versión del servidor Exchange puede recibir consultas de información de detección automática y “comprender” cómo formatear la respuesta requerida.
Por ejemplo, en caso de que apuntemos el registro de detección automática al servidor de Exchange 2013 y el cliente externo solicite el tiempo libre/ocupado de un destinatario (servicios de disponibilidad) que está alojado en el servidor de Exchange 2007, Exchange 2013 "sabe" cómo para formatear la solicitud y la respuesta que se envía desde el servidor Exchange 2007 de forma adecuada.
4. Registro de detección automática que apunta al servidor local de Exchange
Uno de los errores más comunes relacionados con el registro de detección automática y las implementaciones híbridas es: actualizar el registro de detección automática para que apunte a la "nube" (autodiscover.outlook.com).
Esta suposición puede parecer lógica, pero esta actualización debería no se implementará.
En una configuración híbrida, el registro de detección automática que "representa" el nombre de dominio público debe apuntar al servidor local de Exchange.
Nota: no necesitamos configurar ni actualizar ninguna de las configuraciones de detección automática relacionadas con la "nube" porque en Office 365, todas las configuraciones requeridas de los servicios de detección automática se configuran automáticamente mediante el uso del "dominio de servicio" o Tenet Office. Dominio 365 como o365info.mail.onmicrosoft.com
8. Servidor híbrido local de Exchange | servicio EAS
El entorno híbrido se basa en el concepto en el que dos organizaciones Exchange separadas operan como una sola entidad. Por ejemplo, permita a los usuarios de Exchange local ver información de tiempo libre/ocupado sobre los destinatarios de Exchange Online, recibir mensajes de Fuera de la oficina y mucho más.
La infraestructura para esta "colaboración" entre el servidor Exchange local y Exchange Online se basa en el servicio Exchange EWS (Exchange Web Services).
El significado es que:
- Exchange On-Premise deberá ser accesible desde la red pública.
- Los servicios Exchange On-Premise EWS deben configurarse correctamente.
Nota: la configuración híbrida se basa en una "relación bidireccional" en la que Exchange On-Premise también necesitará acceder al EWS de Exchange Online, pero la suposición básica es que la "infraestructura de la nube" (Exchange Online) está configurada correctamente y Además de eventos muy raros, asumimos que el lado de la nube está disponible y configurado correctamente.
Verificar: verifique la disponibilidad de: Servicio EWS del servidor híbrido local de Exchange
Podemos comprobar o verificar la disponibilidad del servicio Exchange On-Premise y EWS mediante una de las siguientes opciones:
Opción 1: Verificar/comprobar la disponibilidad del servicio Exchange On-Premise y EWS mediante la URL de EWS
En esta opción, simplemente podemos intentar acceder a la URL de los servicios web locales (EWS) de Exchange.
La URL predeterminada se basa en la siguiente conversación de nomenclatura: https:/
En nuestro escenario, el nombre público de Exchange On-Premise es: mail.o3655info.com
Abriremos un navegador web y usaremos la siguiente dirección URL: https:/mail.o365info.com/ews/exchange.asmx
En la siguiente captura de pantalla, podemos ver que podemos conectar con éxito los servicios EWS de Exchange On-Premise.
Como respuesta, el servidor Exchange on-Premises envía un requisito de autenticación.
Además, podemos ver que el certificado del servidor es "correcto" porque el icono de candado no tiene errores.
Las credenciales que necesitaremos proporcionar son simplemente una credencial de usuario simple de cualquier destinatario que tenga un buzón en el servidor local de Exchange.
La “respuesta” de Exchange On-Premise es un archivo XML que incluye la información o descripción requerida sobre los servicios web de Exchange On-Premise.
No hay ningún significado real para nosotros. El único significado es que podríamos acceder al servicio EWS local de Exchange y obtener la respuesta del servidor Exchange.
Opción 2: verificar/comprobar la disponibilidad del servicio Exchange On-Premise y EWS mediante el Analizador de conectividad remota de Microsoft
El servicio Verificación de Exchange On-Premise EWS se puede implementar mediante el uso de una herramienta muy poderosa y recomendada llamada Microsoft Remote Connectivity Analyzer (MRCA).
En la siguiente captura de pantalla, podemos ver un ejemplo de los pasos necesarios que debemos implementar para verificar la disponibilidad del servicio Exchange On-Premise EWS.
1. Elija la pestaña Servidor Exchange y luego, en “Pruebas de conectividad de servicios web de Microsoft Exchange”, elija la opción : Sincronización, Notificación, disponibilidad y Respuesta automática
2. Proporcione las credenciales de usuario de Exchange On-Premise.
Para poder obtener la información requerida, necesitaremos proporcionar las credenciales de usuario de los usuarios que tienen un buzón de correo de Exchange On-Premise.
En nuestro ejemplo, usamos las credenciales de usuarios llamados: Usuario2
3. En la pantalla de resultados, podemos ver que el encabezado es: “Prueba de conectividad exitosa con advertencia”.
Este es el “resultado requerido” a pesar de que el El resultado incluye un “signo de exclamación amarillo”.
La prueba del servicio web local de Exchange incluirá de forma predeterminada algunos errores menores causados por el mecanismo de "prueba y error" del proceso de detección automática.
El hecho de que obtengamos el “ícono verde” es una indicación de la implementación exitosa del proceso del servicio web local de Exchange.
4. En caso de que queramos obtener información más detallada, podemos hacer clic en “Paso de prueba“.
En la siguiente captura de pantalla, podemos ver el contenido. del archivo XML de detección automática.
9. Servidor híbrido local de Exchange | Certificado Público
El canal de comunicación entre Exchange Online y Exchange On-Premise se basa en el supuesto básico de que el canal de comunicación es "seguro". La necesidad de proteger el canal de comunicación se debe al hecho de que la información entre los dos puntos finales se transfiere a través de la red pública.
La creación del canal de comunicación seguro implementado mediante el uso de un protocolo seguro como HTTPS y SMTP\TLS y el componente que se utiliza para crear el cifrado de datos. La integridad de los datos, la autenticación mutua, etc., se basa en un certificado público que utilizan ambas partes (Exchange Online y Exchange On-Premise).
La suposición subyacente es que el certificado público de Exchange Online está configurado correctamente y está disponible.
En nuestro escenario, necesitaremos verificar el asunto del certificado público en el "lado del servidor local de Exchange".
Nota: no entraremos en detalles sobre cómo crear una solicitud de certificado, instalar un certificado público en Exchange On-Premise, etc.
La suposición subyacente es que Exchange On-Premise incluye un aislamiento de certificado público, y solo queremos verificar que el certificado público esté instalado e incluir la información requerida.
El certificado público de Exchange On-Premise se utilizará como parte del servicio AutoDiscover y, de hecho, para el cifrado del flujo de correo (SMTP/TLS) entre el servidor Exchange On-Premise y el servidor Exchange Online.
En el siguiente diagrama, podemos ver un ejemplo de los "Nombres de hosts" que deberán incluirse en el certificado público local de Exchange.
En nuestro escenario, el certificado público local de Exchange debe incluir el nombre del host: Autodiacover.o3655info.com para los servicios de detección automática y un nombre de host adicional: mail.o3655info.com
este es el nombre de host que utilizará el servidor Exchange Online para dirigirse al servidor Exchange On-Premise (creando un canal de comunicación seguro con el servidor Exchange On-Premise).
Tipos de certificados públicos
Hay un par de tipos de certificados públicos. Los tipos más comunes son:
Certificado comodín y certificado SAN (nombre alternativo del sujeto).
La principal diferencia entre estos dos tipos es: que el certificado comodín no incluye información sobre el nombre de un host específico frente al SAN. certificado que debe incluir un nombre específico del "Host" que puede usar el certificado.
Requisitos del certificado público
Para poder verificar/verificar la configuración del certificado público en Exchange On-Premise, use Exchange MMC, configuración del servidor, elija el nombre del servidor híbrido (EX01 en nuestro escenario) mirando la pestaña Certificado de Exchange.
Nota: estas instrucciones son relevantes para la interfaz de Exchange 2010.
Hay tres requisitos principales relacionados con el certificado Exchange On-Premise:
1. Certificado público
El significado del término "Certificado público" es el certificado creado por una CA pública (Autoridad de certificación).
En la siguiente captura de pantalla, utilizamos la interfaz MMC local de Exchange 2010 para obtener información sobre el certificado público.< br>Podemos ver que en la sección “autofirmado”, el valor del certificado es: Falso (número 1 en la captura de pantalla).
El significado es que este certificado no fue creado por el servidor local de Exchange (autofirmado pero creado por un proveedor de certificados públicos).
2. Asignación de certificado
El Certificado Público debe asignarse a los siguientes servicios Exchange: IIS y SMTP (número2 en la captura de pantalla).
3. Certificado público SAN
Un certificado SAN (nombre alternativo del sujeto) incluye el nombre de los hosts que "permitieron" utilizar el certificado. El término "Asunto" describe el nombre de host que podría implementarse como un nombre de host simple como SRV1 o FQDN como mail.o3655info.com.
Cuando el servidor local de Exchange "presente" su certificado público a Exchange Online, Exchange Online deberá verificar que el nombre del servidor de correo configurado en el conector de recepción de Exchange Online esté incluido en el certificado público que proporciona el servidor local de Exchange.
(En nuestro escenario: el certificado público que el proveedor del servidor local de Exchange deberá incluir el nombre de host: mail.o3655info.com.
Recomendamos que proporcione todos los nombres DNS necesarios en el mismo certificado utilizando un certificado de Comunicaciones Unificadas que admita el campo Nombre alternativo del sujeto. El uso de un certificado de Comunicaciones Unificadas reduce la complejidad de configurar y administrar las URL del servicio de detección automática y de los servicios de Exchange. Sin embargo, el uso de un certificado de Comunicaciones Unificadas puede aumentar el costo, ya que este tipo de certificado puede ser más costoso que los certificados de nombre único que ya tenga.
Certificados: el certificado digital utilizado para el transporte seguro de correo entre las organizaciones locales y Exchange Online debe instalarse en todos los servidores de acceso de cliente locales, debe ser emitido por una autoridad certificadora (CA) de terceros y no debe estar caducado y debe tener asignados los servicios IIS y SMTP. Si no se cumplen estos requisitos de certificado, el transporte seguro de correo desde la organización de Exchange Online a la organización local no funcionará correctamente.
Leer más: Solucionar problemas de una implementación híbrida.
Verificar: verificar el contenido del certificado público del servidor local de Exchange
Opción 1: obtener información sobre el Certificado Público usando Exchange MMC
Para poder verificar los hosts nombrados que están incluidos en el certificado Público, haga doble clic en el certificado público y en la pestaña de detalles busque el campo - Nombre alternativo del sujeto
En las siguientes capturas de pantalla, podemos ver que el certificado público incluye todos los nombres de host requeridos.
Nota: el tema de incluir los nombres de los hosts en un certificado público no es relevante cuando usamos un certificado comodín porque en este escenario, el certificado se relaciona con "todos los hosts" bajo un dominio específico. .
Opción 2: verificar el certificado público local de Exchange accediendo a la URL de OWA
Otra opción para verificar el certificado público local de Exchange es acceder a la URL local de Exchange que se utiliza para el acceso OWA.
En nuestro escenario, la URL de OWA es: https://mail.o365info.com/owa
En la siguiente captura de pantalla podemos ver que usamos la URL, en la esquina derecha de la barra de URL podemos ver el ícono de candado que representa el hecho de que el sitio proporciona un certificado.
Cuando hagamos doble clic en el icono del candado podremos ver el “contenido” del certificado público que proporciona el servidor Exchange on-Premises.
10. Servidor Microsoft MFG y proceso de prueba de propiedad
El primer paso cuando necesitamos crear una configuración híbrida es el paso en el que el servidor Exchange On-Premise crea relaciones de confianza” con Microsoft Federation Gateway (MFG).
Esta relación de confianza se describe como Confianza de federación
Nota: cuando se utiliza una configuración híbrida, ambas partes (Exchange On-Premise y Exchange Online) deben “confiar” en MFG. La infraestructura en la nube de Office 365 está configurada para confiar automáticamente en el servidor MFG, por lo que el único requisito es "construir" una nueva confianza entre Exchange On-Premise y MFG.
La “creación” del fideicomiso de Federación con el servidor Microsoft MFG, se crea mediante la implementación de un proceso de “prueba de propiedad” para el dominio público que utilizamos.
Por ejemplo: en caso de que queramos configurar una configuración híbrida utilizando el nombre de dominio público: o3655info.com, necesitaremos demostrar que somos propietarios de este dominio.
El proceso de "prueba de propiedad" se implementó de la siguiente manera: cuando se utiliza HCW, Exchange On-Premise se comunica con el servidor Microsoft MFG.
El servidor MFG responde con una "cadena TXT".
Necesitaremos copiar esta cadena de texto, ir a nuestro servidor DNS público, agregar un nuevo registro TXT que incluya el valor proporcionado por el servidor MFG y solo después de haber creado la "prueba", los servidores MFG accederán a nuestro DNS público. servidor que busca esta cadena TXT.
En el siguiente diagrama podemos ver una descripción del flujo o los pasos necesarios para generar confianza con el servidor Microsoft MFG.
Cuando se utiliza HCW (asistente de configuración híbrida de Exchange), la cadena TXT requerida que se envió desde el servidor MFG se mostrará en la pantalla.
En caso de que por algún motivo no se muestre la cadena TXT requerida, podemos usar un comando de PowerShell para mostrar la cadena TXT (la prueba de dominio TXT).
El PowerShell que utilizamos se basa en la siguiente sintaxis:
Get-FederatedDomainProof -DomainName "<Domain name>"En la siguiente captura de pantalla, podemos ver la cadena de texto de prueba de dominio.
Opción 1: Verificar que el registro TXT esté configurado correctamente en el DNS público usando una herramienta de comando Nslookupl
En caso de que queramos verificar que el registro TXT (Prueba de Dominio TXT) fue configurado correctamente en el DNS Público, podemos crear una consulta para un registro TXT.
Para verificar que el registro TXT (Prueba de Dominio TXT) configurado en En el DNS público, puede verificar la información utilizando el comando NSLOOKUP.
Por ejemplo, podemos usar la herramienta NSLOOKUP para obtener información sobre el registro TXT que está configurado en el dominio: o3655info.com
desde el símbolo del sistema escribimos:
Nslookup
Set type=txt
A continuación escribiremos el nombre del dominio que queremos consultar.
o365info.com
En la siguiente captura de pantalla podemos ver el resultado del comando Nslookup
Opción 2: Verificar que el registro TXT esté configurado correctamente en el DNS público mediante la herramienta web.
Existen muchas herramientas web gratuitas que pueden ayudarnos a consultar el servidor DNS.
A continuación Por ejemplo, usaremos el sitio MxToolbox.
- Elija el menú Más
- Elija la opción TXT y escriba el nombre de dominio que desea consultar.
En nuestro ejemplo, nos gustaría obtener información sobre todos los registros TXT en el dominio o365info.com
En la siguiente captura de pantalla, podemos ver el resultado de la consulta. Hay dos registros TXT en el dominio o365info.com.
Uno de estos registros TXT es la cadena de texto proporcionada por el servidor Microsoft MFG y actualizada en el dominio o365info.com como un registro TXT.
11. Canal de comunicación directa | Servidor local de Exchange a Exchange Online
El tema del flujo de correo en la configuración híbrida se relaciona con muchos escenarios de flujo de correo entrante y saliente.
Por ejemplo -
- Correo que se envía desde la “infraestructura de la nube” a la red pública.
- Correo que se envía desde la "infraestructura de la nube" a los destinatarios locales de Exchange.
- Correo que se envía desde Exchange local a la red pública.
- Correo que se envía desde Exchange local a destinatarios de Office 365.
No entraremos en detalles de todos los escenarios de flujo de correo disponibles, sino que me gustaría enfatizar solo el flujo de correo entre el servidor local de Exchange y Exchange Online y viceversa.
Como se mencionó anteriormente, en la configuración híbrida, el servidor local de Exchange y Exchange Online actúan como una unidad o una entidad.
La configuración se implementó mediante la creación de una ruta de comunicación directa entre el servidor local de Exchange y Exchange Online basada en el protocolo SMTP\TLS y HTTPS.
Todo el flujo de correo entre el servidor local de Exchange y Exchange Online pasa a través de este canal de comunicación seguro.
Por ejemplo, en caso de que el buzón de Bob esté ubicado en el servidor local de Exchange y Bob envíe un correo a Alice indicando que su buzón está ubicado en el servidor de Exchange Online, el El servidor local de Exchange “transferirá” el correo a Exchange Online mediante el “enlace de comunicación segura directa” que existe entre el servidor local de Exchange y Exchange Online (este “canal seguro” lo crea HCW - Exchange Hybrid). Asistente de configuración)
En el siguiente diagrama, podemos ver un ejemplo de la configuración requerida para el enlace de comunicación seguro entre Exchange On-Premise y el servidor Exchange Online.
En nuestro escenario, el dominio compartido es - o365info.com
Cada uno del correo que se enviará desde el destinatario de Exchange On-Premise al “destinatario de la nube” (Exchange Online) y viceversa, que incluya el nombre de dominio: o365info.com, se enrutará a través del canal de comunicación segura directa que existe.
Nota: el "canal de comunicación segura directa" se implementa mediante un conjunto de cuatro conectores:
1 conector de envío y 1 conector de recepción creado en el servidor híbrido local de Exchange y el mismo en el “lado de Exchange Online”.
Otro escenario admitido podría ser un escenario en el que el entorno local de Exchange incluya un servidor de transporte perimetral. En esta situación, el canal de comunicación segura directa se creará utilizando el servidor de transporte perimetral como "punto final" o puerta de enlace en el lado local.
Un escenario no admitido | utilizando un servidor que no sea Exchange como “punto final local”
Un escenario no compatible que debemos evitar es: un escenario en el que utilizamos un "servidor que no es Exchange" como punto final en el entorno local.
Por ejemplo: en el siguiente diagrama, podemos ver un escenario en el que el canal de comunicación segura directa creado entre una puerta de enlace de seguridad de correo (“servidor que no es Exchange”) y Exchange Online.
Técnicamente hablando, podemos implementar este escenario, pero esta configuración no es compatible y existe una posibilidad razonable (si no cierta) de que experimente muchos tipos de problemas.
La razón por la que este escenario no es compatible es porque el "canal de comunicación directa segura" en un entorno híbrido no es simplemente un conector simple entre dos servidores de correo separados, sino un canal de comunicación que incluye muchas configuraciones y parámetros que se relacionan directamente con "Servidores de Exchange".
No puede haber otros hosts o servicios SMTP entre los servidores locales de acceso de cliente de Exchange 2013 o un servidor de transporte perimetral de Exchange 2013/2010 SP3 y EOP. La información agregada a los mensajes que habilita las funciones de transporte híbrido se elimina cuando pasan a través de un servidor que no es Exchange 2013, servidores anteriores a Exchange 2010 SP3 o un host SMTP.
Leer más: Opciones de transporte en implementaciones híbridas de Exchange.