Flujo de conectividad del protocolo de cliente de servicio web ActiveSync y Exchange en la coexistencia de Exchange 2013/2010 | 4/4 | 23#23

El artículo actual es el cuarto de una serie de cuatro artículos, sobre el tema: “Entorno de coexistencia de Exchange 2013/2010 y flujo de conectividad del protocolo del cliente de correo”. En este artículo, nuestro enfoque principal es revisar dos tipos de flujo de conectividad de protocolo de cliente en el entorno de coexistencia de Exchange 2013/2010:

Flujo de conectividad del protocolo del cliente ActiveSync
Flujo de conectividad del protocolo de cliente de servicios web de Exchange

Para poder comprender los diferentes flujos de protocolos de conectividad de “clientes Exchange” en el entorno de coexistencia de Exchange 2013/2010, revisaremos cinco tipos de “relaciones” que existen entre el cliente Exchange 2010 y el servidor Exchange CAS 2013:

Cliente de detección automática: flujo de conectividad del protocolo (Parte 2#4)
Cliente Outlook: flujo de conectividad del protocolo (Parte 2#4)
Cliente OWA: flujo de conectividad del protocolo (Parte 3#4)
Cliente ActiveSync: flujo de conectividad del protocolo (Parte 4#4)
Cliente de servicio web de Exchange: flujo de conectividad de protocolo (Parte 4#4)

Convivencia Intercambio 2013/2010 | Flujo de conectividad del protocolo del cliente ActiveSync

Los clientes de Exchange ActiveSync (clientes móviles) siempre se consideran "clientes externos" porque la infraestructura de red del cliente móvil se basa en una red móvil pública. El cliente móvil (cliente ActiveSync) siempre necesitará dirigirse al servidor CAS de Exchange público y, por esta razón, el "punto de conexión" (servidor CAS de Exchange) que aceptará las solicitudes de comunicación del cliente móvil (ActiveSync) debe configurarse como un " Servidor CAS de Exchange de cara al público. "

Nota: otros clientes de Exchange, como Outlook y OWA, que pueden conectarse a la infraestructura interna (o externa) de Exchange.

Cuando el cliente ActiveSync (móvil) se conecta al servidor público Exchange CAS, según las credenciales de usuario proporcionadas, el servidor público Exchange CAS descubre dónde está alojado el buzón del usuario y "enruta" (Proxy) la solicitud de comunicación al servidor interno. Infraestructura de intercambio.

El "enrutamiento interno" de la solicitud de comunicación del cliente ActiveSync (móvil) implementada mediante el uso de la dirección URL interna de ActiveSync.

Escenario 1: cliente móvil (ActiveSync) | Buzón de usuario ubicado en el sitio de Nueva York.

Cartas de escenario: Cliente móvil (ActiveSync), necesita obtener acceso a su buzón.

Tipo de usuario de Exchange: cliente de Exchange 2010 (usuario de Exchange cuyo buzón está alojado en el servidor de buzones de Exchange 2010).
Ubicación del servidor de buzones de correo de Exchange: el servidor de buzones de correo de Exchange 2010 que aloja el buzón de correo del usuario se encuentra en el sitio de Nueva York.

El flujo de conectividad del protocolo del cliente ActiveSync se implementará de la siguiente manera:

El cliente móvil (ActiveSync) conecta el “CAS Exchange público de Nueva York” utilizando el nombre del servidor: mail.o365info.com y proporciona sus credenciales de usuario.
CAS2013 utiliza las credenciales del usuario y realiza la búsqueda en Active Directory.
CAS2013 determina que:
La versión del buzón del usuario es: 2010
- El servidor de buzón de Exchange 2010 que aloja el buzón del usuario se encuentra en el sitio de Nueva York
- Hay un Exchange CAS 2010 local en el sitio (el sitio de Nueva York)
CAS2013 enviará la solicitud del cliente ActiveSync + las credenciales de usuario de ActiveSync al CAS2010 en el servidor del sitio local utilizando la dirección URL interna de Exchange 2010 CAS ActiveSync (. (Número 2).
CAS2010 aceptará la solicitud y “reenviará” (Proxy) la solicitud de conexión del cliente ActiveSync al servidor de buzón de Exchange 2010 (Número 3).
El servidor de buzones de correo de Exchange 2010 “busca” el contenido requerido del buzón del usuario y envía los datos al CAS2010 (Número 4).
El proxy CAS2010 devuelve la información/datos a CAS2013 (Número 5).
CAS2013 proporciona la información requerida al cliente ActiveSync externo (Número 6).

Escenario 2: cliente móvil (ActiveSync) | Buzón de usuario ubicado en el sitio de Los Ángeles | Sitio de destino=Sitio de intranet | Sin Exchange 2010 CAS local

Cartas de escenario: Cliente móvil (ActiveSync), necesita obtener acceso a su buzón.

Tipo de usuario de Exchange: cliente de Exchange 2010 (usuario de Exchange cuyo buzón está alojado en el servidor de buzones de Exchange 2010).
Ubicación del servidor de buzones de correo de Exchange: el servidor de buzones de correo de Exchange 2010 que aloja el buzón de correo del usuario se encuentra en el sitio de Los Ángeles.
El sitio de Nueva York no tiene un CAS Exchange 2010 “local”.

Dado que en nuestro escenario, el buzón de Exchange 2010 está alojado en el servidor de buzones de Exchange 2010 en otros sitios (sitio de Los Ángeles) y, dado que no existe un "CAS de Exchange 2010 local", el CAS de Exchange 2013 representará por sí mismo la solicitud del cliente móvil externo a el “Exchange 2010 CAS remoto” que se encuentra en el sitio de Los Ángeles (Número 2).

Nota: el resto del proceso es idéntico a los pasos que ya hemos revisado en - Escenario 1: Cliente ActiveSync | Buzón de usuario de Exchange en el mismo sitio de Active Directory.

Escenario 3: cliente móvil (ActiveSync) | Buzón de usuario ubicado en el sitio de Madrid | Sitio de destino=Sitio de intercambio público | Espacio de nombres regional

Antes de comenzar con los detalles específicos del “usuario de ActiveSync de Madrid” repasemos brevemente los estatutos de este escenario en particular.

De forma predeterminada, el cliente ActiveSync (móvil) utilizará la infraestructura de detección automática de Exchange para obtener el "nombre del servidor" que aceptará su solicitud. En un escenario de un “usuario de Madrid ActiveSync”, el nombre del servidor Exchange que debe proporcionar al cliente ActiveSync como parte del proceso de detección automática es el nombre del “servidor CAS de Exchange público de Madrid”: europa.mail.o365info.com

De forma predeterminada, el método preferido para el cliente ActiveSync es utilizar los servicios de detección automática de Exchange para obtener todas las configuraciones de perfil de ActiveSync requeridas y el nombre de host del servidor Exchange que actuará como: "servidor ActiveSync", pero, en algunos escenarios, el cliente ActiveSync es la detección automática. Los servicios no se utilizan y, en cambio, el usuario móvil utiliza un "método manual" en el que proporciona el "nombre del servidor Exchange".

Por ejemplo: cuando un “usuario de Madrid ActiveSync” quiere acceder a su buzón de correo, puede proporcionar el espacio de nombres principal: mail.o365info.com (opción A en el diagrama) como nombre de host de Exchange a1 o utilice el nombre de host del “servidor CAS de Exchange público de Madrid”: europe.mail.o365info.com (opción B en el diagrama)

En caso de que el “usuario de Madrid ActiveSync” utilice el espacio de nombres principal: mail.o365info.com, la solicitud de conexión será aceptada por el “servidor CAS de Exchange público de Nueva York”. "

El “servidor CAS de Exchange público de Nueva York” necesitará saber cómo “manejar” esta solicitud porque, en nuestro escenario, el buzón del usuario de ActiveSync está alojado en otro sitio de Exchange: el sitio de Madrid.

La suposición subyacente podría ser que en este caso, el “servidor CAS de Exchange público de Nueva York” “redirigirá al” usuario de Madrid ActiveSync ” a su servidor de Exchange, pero CAS de Exchange 2013 no utilizará el método de redirección.

En este escenario, el “servidor CAS Exchange público de Nueva York” no redirigirá la solicitud de ActiveSync, sino que enviará la solicitud de conexión al “servidor CAS Exchange de Madrid”.

Escenarios: cliente móvil (ActiveSync), necesita obtener acceso a su buzón.

Tipo de usuario de Exchange: cliente de Exchange 2010 (usuario de Exchange cuyo buzón está alojado en el servidor de buzones de Exchange 2010).
Ubicación del servidor de buzones de Exchange: el servidor de buzones de Exchange 2010 que aloja el buzón del usuario, se encuentra en el sitio de Madrid.
El sitio de Madrid se considera un sitio Exchange público y el “servidor CAS Exchange público de Madrid” se publica con un espacio de nombres regional: mail.o365info.com

La característica especial de este escenario es que el buzón de correo del usuario está ubicado en un sitio de Exchange diferente y, además, el sitio de destino es un "sitio de Exchange público".

En versiones anteriores del servidor Exchange, en un escenario en el que el cliente móvil (ActiveSync) se conecta a un servidor CAS de Exchange público y el servidor Exchange reconoce que el buzón del cliente móvil (ActiveSync) ubicado en un sitio de Exchange diferente + el "otro Exchange "sitio" considera un sitio de Exchange público, la "respuesta" del servidor CAS de Exchange de cara pública fue un: mensaje de redirección al cliente móvil (ActiveSync).

Se suponía que el cliente móvil (ActiveSync) aceptaría el “mensaje de redirección” y crearía un nuevo canal de comunicación con el “otro servidor CAS de Exchange público (el “servidor CAS de Exchange público de Madrid” en nuestro escenario).

El método de redirección del cliente móvil (ActiveSync) se implementó mediante el uso de un mensaje que se describe como: "mensaje de 451 redirecciones”.

El problema con el "mensaje de redireccionamiento 451 " era que muchos clientes móviles (ActiveSync) no sabían cómo "manejar" el mensaje de redireccionamiento y el resultado fue: falla de comunicación . En otras palabras, el cliente móvil (ActiveSync) no "entendió" el mensaje de redirección y recibió "instrucciones" para conectar "otros servidores ActiveSync Exchange".

Por esta razón, el comportamiento del servidor Exchange CAS 2013 es diferente porque el servidor Exchange CAS 2013 no implementará más el método de redirección (mensaje de redirección 451). para clientes móviles (ActiveSync). En cambio, cuando Exchange 2013 CAS reconoce que el buzón de ActiveSync está ubicado en otro sitio de Exchange, enviará la solicitud "en nombre" de ActiveSync al "servidor Exchange de destino". "

En nuestro escenario, el servidor CAS de Exchange público de Nueva York "sabe" que el buzón del usuario está ubicado en el sitio de Madrid y, además, que Madrid lo considera un sitio de Exchange público (tiene un servidor CAS de Exchange público).

En teoría, el servidor CAS de Exchange orientado al público de Nueva York puede enviar un comando de redirección al cliente móvil (ActiveSync), pero en su lugar, el CAS de Exchange 2013 de Nueva York optará por utilizar el método Proxy.

Está claro que este enfoque no es eficiente desde el punto de vista del “servidor CAS Exchange 2013 público de Nueva York” porque, en teoría, el “servidor CAS Exchange 2013 público de Madrid” debería haber servido al “cliente ActiveSync (móvil) de Madrid, pero El uso del “método Proxy” garantizará que la comunicación con el cliente móvil (ActiveSync) se complete con éxito.

El flujo de conectividad del protocolo del cliente ActiveSync se implementará de la siguiente manera:

El cliente Madrid Mobile (ActiveSync), conecta el “CAS Exchange público de Nueva York” utilizando el nombre del servidor: mail.o365info.com y proporciona sus credenciales de usuario.
CAS2013 utiliza las credenciales del usuario y realiza la búsqueda en Active Directory.
CAS2013 determina que:
- La versión del buzón del usuario es: 2010
- El servidor de buzones de Exchange 2010 que aloja el buzón del usuario se encuentra en el sitio de Madrid
CAS2013 no enviará una solicitud de redirección al cliente Madrid ActiveSync, sino que enviará la solicitud del cliente ActiveSync + las credenciales de usuario de ActiveSync al “servidor CAS de Exchange público de Madrid” utilizando la URL externa de ActiveSync del “servidor CAS de Exchange público de Madrid” dirección (Número 2).
El “servidor CAS de Exchange de cara al público de Madrid” aceptará la solicitud y “reenviará” (Proxy) la solicitud de conexión del cliente ActiveSync al “servidor interno de buzones de correo de Exchange 2010 de Madrid” (Número 3).
El “servidor interno de buzones de correo de Madrid Exchange 2010” “obtiene” el contenido requerido del buzón del usuario y envía los datos al “servidor CAS de Exchange público de Madrid” (Número 4).
El proxy del “servidor CAS de Exchange orientado al público de Madrid” devuelve la información/datos al “servidor CAS de Exchange orientado al público de Nueva York” (Número 5).
El “servidor CAS Exchange público de Nueva York” proporciona la información requerida al cliente ActiveSync externo (Número 6).

Convivencia Intercambio 2013/2010 | Flujo de conectividad del protocolo del cliente del servicio web de Exchange

El tema del flujo de conectividad de los servicios web de Exchange en el entorno de coexistencia de Exchange 2013/2010 puede resultar un poco confuso porque no está claro quién es el "elemento" que proporciona los servicios web de Exchange a los clientes de Exchange 2010.

¿El elemento es Exchange 2013 CAS que implementa el mecanismo de proxy estándar de proxy, los clientes de Exchange 2010 solicitan al Exchange 2010 CAS u otro escenario en el que el cliente de Exchange 2010 se conecta directamente al Exchange 2010 CAS y solicita un servicio web de Exchange en particular?

Sólo una nota general: el “cliente de servicios web de Exchange más importante” es el cliente Outlook. Es cierto que existen otros clientes de servicios web de Exchange, pero el cliente de Exchange que más depende del servicio web de Exchange es el cliente de correo Outlook.

Por esta razón, cuando mencionamos el tema “Servicios web de Exchange y flujo de conectividad del protocolo del cliente”, la mayoría de las veces, el cliente al que nos referimos es Outlook.

Técnicamente, el "elemento" que proporciona el servicio web de Exchange a los clientes de Exchange 2010 puede ser un servidor basado en Exchange CAS 2010 o un servidor basado en Exchange CAS 2013.

La respuesta a la pregunta: quién es el elemento que proporciona el servicio web de Exchange a los clientes de Exchange 2010 depende de la implementación particular de la infraestructura del espacio de nombres.

En caso de que el espacio de nombres de la dirección URL del servicio web de Exchange 2010 sea idéntico al espacio de nombres de la dirección URL del servicio web de Exchange 2013, el elemento del servicio web de Exchange que servirá a los clientes de Exchange 2010 es el CAS de Exchange 2013.
En caso de que el espacio de nombres de la dirección URL del servicio web de Exchange 2010 sea no idéntico al espacio de nombres de la dirección URL del servicio web de Exchange 2013, el elemento del servicio web de Exchange que servirá a Exchange 2010 clientes es Exchange 2010 CAS.

Nota: en el artículo actual, no entraremos en explicaciones detalladas de este concepto y, si desea una revisión más exhaustiva, lea los artículos:

Servicios web de Exchange en un entorno de coexistencia de Exchange 2013 | Parte 1/2
Servicios web de Exchange en un entorno de coexistencia de Exchange 2013 | Parte 2/2

Para simplificar la descripción del flujo de conectividad del protocolo del cliente de servicios web de Exchange, utilizaremos el escenario de configuración de "mejores prácticas" en el que se incluye el "elemento" que servirá como "punto focal" para el cliente de Exchange 2010 que solicita servicios web de Exchange. será el CAS de Exchange 2013.

El estatuto de este escenario es que Exchange 2013 CAS y Exchange 2010 CAS utilizarán un espacio de nombres idéntico de los servicios web de Exchange.

Por ejemplo, la dirección URL que se configuró en Exchange 2013 CAS para los servicios web de Exchange es: https://mail.o365info.com/EWS/Exchange.asmx y, la La misma dirección URL configurada en el servidor CAS de Exchange 2010 para la dirección URL de los servicios web de Exchange.

En este escenario, el cliente de Exchange 2010 dirigirá el CAS de Exchange 2013 para los servicios web de Exchange y el CAS de Exchange 2013 enviará su solicitud al CAS de Exchange 2010.

Servicio web Exchange y servicios de detección automática

Para poder comprender mejor la implementación de los servicios web de Exchange en un entorno de coexistencia de Exchange 2013, es importante que conozcamos las relaciones que existen entre la infraestructura de detección automática de Exchange y la infraestructura de servicios web de Exchange.

El servicio web de Exchange se basa en la información de detección automática proporcionada por el servidor CAS de Exchange.
Cuando el cliente de Exchange 2010 se dirige a CAS de Exchange 2013 y solicita información de detección automática, CAS de Exchange 2013 proporcionará la información de detección automática que incluye la dirección URL de los servicios web de Exchange. Por ejemplo: https://mail.o365info.com/EWS/Exchange.asmx

El cliente de Exchange 2010 utiliza esta información para localizar el servidor CAS de Exchange que le proporcionará los servicios web de Exchange necesarios. En nuestro escenario, la dirección URL incluye el nombre de host: mail.o365info.com. Este nombre de host dirigirá el cliente de Exchange 2010 al servidor CAS de Exchange 2013.

En el siguiente diagrama, podemos ver un ejemplo del flujo de conectividad del protocolo de cliente que describe el "flujo completo" de los clientes de Exchange 2010.

Fase 1/2: servicios de detección automática

Cliente de Exchange 2010, dirija el CAS de Exchange 2013 como un punto final de detección automática.
El Autodiscover responde que el “proporcionar” CAS2013 incluye la dirección URL Dirección URL de los servicios web de Exchange: https://mail.o365info.com/EWS/Exchange.asmx

Fase 2/2 - Servicios web de intercambio

Cuando el cliente de Exchange 2010 necesita un servicio web específico, como el servicio de disponibilidad
(tiempo libre/ocupado), utilizará la dirección URL que obtuvo de la respuesta de detección automática: https:// mail.o365info.com/EWS/Exchange.asmx
Esta URL incluye el nombre de host: mail.o365info.com que se “traducirá” al Dirección IP de Exchange 2013 CAS.

Cuando el CAS de Exchange 2013 recibe la solicitud de Exchange 2010 para un servicio web de Exchange, "entiende" que el cliente de correo de Exchange es un cliente de Exchange 2010 y, por esta razón, "reenviará" (Proxy) los requisitos al CAS de Exchange 2010. . Exchange 2013 CAS aborda el Exchange 2010 CAS que deberá proporcionar los servicios web de Exchange necesarios al cliente de Exchange 2010 mediante el FQDN de Exchange 2010 CAS. En nuestro escenario: Excas2010.o365info.com

Escenario 1: Cliente del servicio web Exchange interno/externo | Buzón de usuario ubicado en el sitio de Nueva York.

Cartas de escenario: cliente de servicio web de Exchange, necesita obtener un servicio web de Exchange en particular.

Tipo de usuario de Exchange: cliente de Exchange 2010 (usuario de Exchange cuyo buzón está alojado en el servidor de buzones de Exchange 2010).
Ubicación del servidor de buzones de correo de Exchange: el servidor de buzones de correo de Exchange 2010 que aloja el buzón de correo del usuario se encuentra en el sitio de Nueva York.

El cliente de servicio web de Exchange, flujo de conectividad de protocolo, se implementará de la siguiente manera:

El proceso preliminar para los servicios web de Exchange es el proceso de detección automática, en el que el cliente externo de Exchange 2010 obtiene la información de detección automática que incluye la dirección URL del servicio web de Exchange.