Servicios web de Exchange en una coexistencia de Exchange 2013 | Parte 2/2 | 7#23
En el artículo anterior - Servicios web de Exchange en un entorno de coexistencia de Exchange 2013 | Parte 1/2, ya hemos revisado el concepto y la lógica del servicio web de Exchange en el entorno de coexistencia de Exchange 2013, pero en este artículo me gustaría ver más de cerca el flujo de conectividad del protocolo de cliente que se implementó en la web heredada de Exchange. Cliente de servicio: cliente Exchange 2007 y cliente Exchange 2010.
Flujo de conectividad de servicios web de Exchange en el entorno de coexistencia de Exchange 2013/2007 | Cliente interno de Exchange 2007
En un entorno de coexistencia de Exchange 2013/2007, el servidor Exchange CAS 2007 proporcionará el servicio web de Exchange para el cliente de Exchange 2007.
Es importante enfatizar que el cliente de Exchange 2007 "no sabe" que necesita abordar el servicio web Exchange CAS 2007 para Exchange. En cambio, el cliente de Exchange 2007 obtiene la información de Exchange CAS 2013 o, si queremos ser más precisos: de la información de detección automática proporcionada por Exchange CAS 2013.
La "referencia" a Exchange CAS 2007 se implementará utilizando la dirección URL de Exchange CAS 2007 basada en el espacio de nombres heredado.
Nota: en el artículo actual nos basaremos en un escenario en el que el espacio de nombres heredado de Exchange CAS 2007 es: Legacy.mail.o365info.com
En el siguiente diagrama podemos ver un ejemplo del flujo de servicios web de Exchange en el entorno de coexistencia de Exchange 2013/2007.
Fase 1: en esta fase, el cliente de Exchange 2007 está relacionado con Exchange 2013 CAS como un punto final de detección automática. El cliente de Exchange 2007 dirige Exchange 2013 CAS y solicita información de detección automática.
Fase 2: Exchange 2013 CAS proporciona la información de detección automática requerida que incluye la dirección URL del "espacio de nombres heredado de Exchange 2007" de los servicios web de Exchange.
En nuestro escenario, la dirección URL que Exchange 2013 CAS proporciona es:
https://legacy.mail.o365info.com/EWS/Exchange.asmx
Paso 3: cuando el cliente de Exchange 2007 necesite obtener un servicio web de Exchange en particular, como el servicio de disponibilidad (tiempo libre/ocupado), utilizará la información de detección automática que obtuvo en la fase anterior. En nuestro escenario, la dirección URL del servicio web Exchange es: https://legacy.mail.o365info.com/EWS/Exchange.asmx
El cliente de Exchange 2007 buscará la dirección IP del host denominado: legacy.mail.o365info.com y la dirección de este host (Exchange CAS 2007) solicitará el servicio web específico de Exchange. .
Flujo de conectividad de servicios web de Exchange en el entorno de coexistencia de Exchange 2013/2007 | Cliente externo de Exchange 2007
El flujo de conectividad del protocolo del cliente externo de Exchange 2007 que necesita obtener un servicio web de Exchange es muy similar a la lógica del cliente interno de Exchange 2007 que se describió en la sección anterior.
Lo único que vale la pena mencionar es que en un escenario de cliente externo de Exchange 2007 que necesita el servicio web de Exchange, la información de detección automática la proporcionará el servidor CAS de Exchange 2013 público e incluye información sobre el espacio de nombres heredado que "representa" Exchange. CAS 2007.
Exchange CAS 2007 también deberá configurarse como un servidor Exchange CAS público porque el cliente externo de Exchange 2007 se dirigirá a él siempre que necesite servicios web de Exchange.
En el siguiente diagrama, podemos ver que el “viaje” comienza cuando el cliente de Exchange externo 2007 se dirige al extremo público de detección automática: autodiscover.o365info.com
La "respuesta" incluye la dirección URL que "contiene" el nombre del host: legacy.mail.o365info.com
Cuando el cliente de Exchange externo 2007 necesita un servicio web de Exchange en particular, intentará obtener la dirección IP del nombre de host: legacy.mail.o365info.com y dirigirse a él.
El nombre de host: legacy.mail.o365info.com debe publicarse como un nombre público y tener una dirección IP pública.
Flujo de conectividad de servicios web de Exchange en el entorno de coexistencia de Exchange 2013/2010 | Cliente interno de Exchange 2010
En un escenario de entorno de coexistencia de Exchange 2013/2010, la mejor práctica es que el cliente de Exchange 2010 se dirija a Exchange CAS 2013 cuando necesite un servicio web de Exchange.
La implementación de esta lógica podría considerarse confusa porque la realización de este escenario requiere que usemos un espacio de nombres idéntico para el servicio web de Exchange, el servicio web de Exchange 2013 y el servicio web de Exchange 2010.
En una escena de "Espacio de nombres idéntico", utilizamos el espacio de nombres "principal" o "primario" para ambas infraestructuras: servicios web de Exchange 2013 + servicios web de Exchange 2010.
Para demostrar el concepto de servicio web de Exchange en un entorno de coexistencia de Exchange 2013/2010, utilicemos los siguientes detalles del escenario:
La infraestructura de Exchange de la organización incluye los siguientes servidores CAS de Exchange:
- Exchange CAS 2013 cuyo “nombre real” es: EXCAS2013.o365info.com
- Exchange CAS 2010 cuyo “nombre real” es: EXCAS2010.o365info.com
- El espacio de nombres principal que está “asignado” a Exchange CAS 2013 es: mail.o365info.com
La URL del servicio web de Exchange que se configurará en ambos servidores Exchange CAS (Exchange CAS 2013 y Exchange CAS 2010) será:
https://mail.o365info.com/EWS /Exchange.asmx
Como sabemos, el servicio web Exchange se basa en dos fases. El primer paso podría describirse como la fase de detección automática.
- El cliente de Exchange 2010 dirige Exchange CAS 2013 como suyo: "Punto final de detección automática" y solicita información de detección automática.
- Cuando Exchange CAS 2013 recibe la solicitud de información de detección automática, consulta Active Directory sobre el usuario y descubre que el cliente de Exchange es: cliente de Exchange 2010. Debido a que Exchange CAS 2013 no proporciona por sí solo servicios de detección automática y, debido a que el cliente es un cliente de Exchange 2010, Exchange CAS 2013 enviará la solicitud a Exchange CAS 2010.
- Exchange CAS 2010 genera la información de detección automática requerida que incluye la dirección URL del servicio web de Exchange: https://mail.o365info.com/EWS/Exchange.asmx
- Exchange CAS 2013 "entrega" la información de detección automática al cliente de Exchange 2010.
Preste atención al hecho de que la "conversación" o el canal de comunicación entre Exchange CAS 2013 y Exchange CAS 2010 se implementó mediante el uso de nombres de host "internos" o "reales". Por ejemplo, cuando Exchange CAS 2013 se dirige a Exchange CAS 2010, busca un host llamado: EXCAS2010.o365info.com y, cuando Exchange CAS 2010 envía su respuesta, se referirá a Exchange CAS. 2013 como: EXCAS2013.o365info.com
En la segunda fase del cliente de servicio web Exchange, flujo del protocolo de conectividad. El cliente de Exchange 2010 dirige la "dirección URL" que obtuvo de la fase anterior de la respuesta de detección automática.
En nuestro escenario, la dirección URL del servicio web Exchange que tiene el cliente Exchange 2010 es: https://mail.o365info.com/EWS/Exchange.asmx
Ahora, el cliente de Exchange 2010 deberá resolver el nombre de host: mail.o365info.com en una dirección IP y dirigirse al host en particular para solicitar el servicio web de Exchange requerido.
- El cliente de Exchange 2010 dirige el nombre de host: mail.o365info.com que está “asignado” al servidor Exchange CAS 2013.
- Cuando Exchange CAS 2013 recibe la solicitud de información de detección automática, consulta Active Directory sobre el usuario y descubre que el cliente de Exchange es: cliente de Exchange 2010. Debido a que el propio servicio web de Exchange no proporciona Exchange CAS 2013 y debido a que el cliente es un cliente de Exchange 2010, Exchange CAS 2013 enviará por proxy la solicitud a Exchange CAS 2010.
- El cliente de Exchange 2010 acepta la solicitud, "genera" la información requerida y la envía de regreso a Exchange CAS 2013.
- Exchange CAS 2013 proporciona la información requerida al cliente de Exchange 2010.
Tenga en cuenta que desde el punto de vista del cliente de Exchange 2010 el elemento que proporciona la información requerida es Exchange CAS 2013. El cliente de Exchange 2010 no conoce el proceso que se implementó “entre bastidores”.
Servicio web de Exchange en el entorno de coexistencia de Exchange 2013/2010, el concepto de "capa".
Un aspecto importante en el escenario del servicio web de Exchange en el entorno de coexistencia de Exchange 2013/2010 es algo que describí como: el "Concepto de capa "
El significado del término "capas" es que en el flujo de servicios web de Exchange utilizamos dos capas diferentes:
La capa lógica versus la “capa física” o la capa de comunicación CAS a CAS.
En el "nombre de host de la capa lógica" utilizamos el espacio de nombres principal para representar el nombre de host de Exchange CAS 2013. Exchange CAS 2010 será un nombre de host como elemento que puede proporcionar el servicio web de Exchange requerido.
En nuestro escenario, el cliente web de Exchange se dirigirá a Exchange CAS 2013 usando el nombre: mail.o365info.com
En realidad, Exchange CAS 2013 en realidad no proporciona el servicio web de Exchange, sino que sirve como "mensajero" o "intermediario" entre el cliente de Exchange 2010 y Exchange CAS 2010 que genera y administra el servicio web de Exchange.
Cuando Exchange CAS 2013 aborda Exchange CAS 2010, Exchange CAS 2013 utilizará el "nombre real" de Exchange CAS 2010. En nuestro escenario: EXCAS2010.o365info.com
Cuando Exchange CAS 2010 responda a la solicitud de Exchange CAS 2013, se dirigirá al servidor de Exchange CAS 2013 usando el nombre: EXCAS2013.o365info.com
Esta es la "capa física" que se utiliza para el proceso de comunicación de CAS a CAS (la comunicación entre Exchange CAS 2013 y Exchange CAS 2010).
Los clientes de Exchange 2010 no conocen esta infraestructura y podemos referirnos a esta infraestructura como una infraestructura detrás de escena.
Clientes Exchange externos versus internos y servicios web Exchange
En la siguiente sección, me gustaría revisar brevemente el concepto de cliente de servicio web Exchange externo versus interno.
En esta etapa debes estar un poco cansado por el trabajo de los diferentes aspectos de los servicios web de Exchange en un entorno de coexistencia de Exchange 2013 así que… ¡un poco de paciencia y listo!
Hagámoslo simple; Técnicamente no existe una diferencia significativa entre los clientes de Exchange externos e internos que necesitan servicios web de Exchange.
Clientes de servicios web internos y externos de Exchange 2010
En el siguiente diagrama, podemos ver que la misma lógica que revisamos en la sección anterior se implementa de la misma manera para clientes externos e internos de Exchange 2010 que necesitan el servicio web de Exchange.
La primera fase se implementó cuando el cliente de Exchange 2010 "solicita" al CAS de Exchange 2013 información de detección automática. La diferencia entre los clientes de Exchange 2010 externos e internos es la forma que utilizan para ubicar el punto final de detección automática (el CAS de Exchange 2013).
El cliente interno de Exchange 2010 consultará en el Active Directory local el nombre de los puntos finales de detección automática disponibles y el cliente externo de 2010 consultará al servidor DNS la dirección IP pública del host: autodiscover.o365info.com< /lapso>
La información de detección automática que se envía a los clientes externos e internos de Exchange 2010 incluirá la dirección URL de los servicios web de Exchange, como:
https://mail.o365info.com/EWS /Exchange.asmx
Cuando el cliente de Exchange 2010 (externo o interno) necesita obtener un servicio web específico, el cliente de Exchange 2010 utilizará la URL proporcionada en la información de detección automática.
La dirección URL incluye el nombre del host: mail.o365info.com
- Cuando el cliente externo de Exchange 2010 mira el nombre de host: mail.o365info.com, el nombre se resolverá en la dirección IP pública del servidor CAS de Exchange 2013 público.
- Cuando el cliente interno de Exchange 2010 busca el nombre de host: mail.o365info.com, el nombre se resolverá en la dirección IP privada del CAS de Exchange 2013.
Cliente externo e interno de Exchange 2007
El acceso al servicio web de Exchange por parte de los clientes de Exchange 2007 se implementa de la misma manera para los clientes de Exchange 2007 externos e internos.
La información de detección automática que se envía a los clientes internos y externos de Exchange 2007 incluirá la dirección URL de los servicios web de Exchange, como por ejemplo: https://mail.o365info.com/EWS/Exchange.asmx
Cuando el cliente de Exchange 2007 (externo o interno) necesita obtener un servicio web en particular, el cliente de Exchange 2007 utilizará la URL proporcionada en la información de detección automática.
La dirección URL incluye el nombre del host: legacy.mail.o365info.com
- Cuando el cliente externo de Exchange 2007 busca el nombre de host: legacy.mail.o365info.com, el nombre se resolverá en la dirección IP pública del servidor CAS de Exchange 2007 público. .
Tenga en cuenta que Exchange CAS 2007, además de la necesidad de implementar la disponibilidad pública para el escenario de Exchange 2007, es único porque, en este entorno, necesitaremos implementar una configuración de dos servidores Exchange CAS públicos y publicar el legado. espacio de nombres de Exchange CAS 2007. - Cuando el cliente interno de Exchange 2010 busca el nombre de host: legacy.mail.o365info.com, el nombre se resolverá en la dirección IP privada de Exchange 2007 CAS.
Servicio web de intercambio | El escenario del cliente de correo externo y el espacio de nombres regional.
El escenario adicional de: Servicio web Exchange, que no mencionamos hasta ahora, es: un escenario de cliente Exchange externo + espacio de nombres regional.
Los estatutos de este escenario son los siguientes:
Una infraestructura de Exchange que incluye dos sitios de Exchange orientados al público: el sitio de Madrid y el sitio de Nueva York. El registro público de detección automática apunta al “CAS de Exchange orientado al público de Nueva York”.
Un cliente externo de Exchange, que es su buzón alojado en el servidor de buzones de Exchange en el sitio de Madrid, comienza su "viaje" relacionándose con el "servidor CAS de Exchange público de Nueva York" como punto final de detección automática.
El “servidor CAS Exchange público de Nueva York” autenticará al usuario y realizará una búsqueda en Active Directory.
El “servidor CAS de Exchange orientado al público de Nueva York” determina que: el servidor de buzones de correo de Exchange del usuario está ubicado en un sitio AD diferente y que el “otro sitio de Active Directory” tiene un significado de “disponibilidad pública”, el “otro sitio de Exchange” está representado por un espacio de nombres diferente. En nuestro escenario: europe.mail.o365info.com
En este caso, la información de detección automática que el servidor CAS de Exchange orientado al público de Nueva York proporciona al cliente externo de Exchange incluirá la dirección URL del “CAS de Exchange orientado al público de Madrid”.
Podemos referirnos a este método como "redireccionamiento lógico" porque el servidor CAS de Exchange orientado al público de Nueva York no redirige de manera precisa al cliente de Exchange externo, sino que proporciona información de detección automática que será utilizada por el cliente de Exchange externo.
En caso de que el “cliente Exchange externo de Madrid” necesite utilizar el servicio web de Exchange, no se dirigirá al servidor CAS de Exchange público de Nueva York, sino que se dirigirá al servidor CAS de Exchange público de Madrid.
