7 errores que no querrás cometer trabajando con Exchange


Descarga gratis el ebook y accede a material exclusivo, 
actualizaciones y novedades sobre Exchange.
 
 

Arquitectura de roles en Exchange

En esta entrada vamos a hacer foco en la arquitectura de roles en Exchange 2013 / 2016.

En Exchange 2007 y 2010 existían 5 roles, en Exchange 2013 esto se redujo a 3:

  • Client Access
  • Mailbox
  • Edge Transport

Una instalación “típica” de Exchange 2013 incluiría los roles de Client Access y Mailbox server. Esto se conoce como multirol y es el tipo de instalación recomendada.

Esto es así al punto que en Exchange 2016 solo tenemos la opción de instalar el rol de Mailbox que incluye toda la funcionalidad siendo equivalente a una instalación multirol en Exchange 2013.

En Exchange 2013 estos roles podrían estar distribuidos en varios servidores de existir algún requerimiento especifico. El punto es que para contar con una instalación funcional es necesario contar con ambos roles, sea en un mismo servidor o en servidores separados.

El rol de Mailbox incluye componentes que antes se encontraban en los roles de Client Access, Hub Transport y Mensajería Unificada de Exchange 2010.

El rol de Client Access provee autenticación, servicios de proxy y redirección en el caso mensajería unificada.

En Exchange 2013 CU4 (service pack 1) re aparece el rol de Edge Transport (ya existía en Exchange 2007 y en 2010). Este rol en particular no puede ser instalado junto a ningún otro y se recomienda que esté fuera de la red interna (DMZ por ejemplo).

A continuación un diagrama de technet sobre la arquitectura de roles en Exchange 2013:

roles en exchange 2013


Rol de Acceso de clientes

El rol de Client Access incluye componentes relacionados con SMTP, ruteo de llamadas (mensajería unificada) y protocolos de cliente. A diferencia de versiones anteriores, si se utiliza un balanceador ya no requiere afinidad de sesión.

Como se puede ver en el diagrama, las conexiones de clientes OWA, ActiveSync, Outlook (RPC/HTTPS), etc pasan por este rol:

Acceso de clientes en Exchange 2013

En Exchange 2016 se continúa simplificando la arquitectura del producto y el único rol que tenemos es el de Mailbox. Este rol consolida la funcionalidad incluida en 2013 distribuida entre los roles de CAS y Mailbox por lo que tanto acceso de clientes, bases de datos como transporte pasa por el rol de Mailbox.

En adición se mantiene el rol de Edge Transport sin grandes cambios.

Arquitectura de Exchange 2016

Independientemente de varias mejoras al producto, algo interesante para quienes consideren actualizar de Exchange 2013 a Exchange 2016 es la posibilidad de mantener publicado los servidores con el rol de CAS de 2013 y que estos hagan de proxy hacia una base de datos en Exchange 2016.

Esto es importante y agiliza el proceso de actualización. En versiones anteriores del producto o por ejemplo si actualizamos desde Exchange 2010, uno de los primeros cambios que debemos realizar es la publicación de los servicios de acceso de clientes (OWA, ActiveSync, Outlook Anywhere, etc) para que pasen por la versión más nueva. Esto se debe a que tradicionalmente la nueva versión es la que “sabe hablar” con la versión anterior en adición a la propia.

En el caso de Exchange 2016 podemos agregar un nuevo servidor a la red, mantener la publicación con servidores Exchange 2013, probar la funcionalidad y paulatinamente a medida que avanza el proceso de actualización ir reemplazando los 2013 con la nueva versión.

El rol de Client Access (CAS) incluye componentes relacionados con SMTP, ruteo de llamadas (mensajería unificada) y protocolos de cliente. A diferencia de versiones anteriores, si se utiliza un balanceador ya no es requerido mantener afinidad de la sesión.

Como se puede ver en el diagrama, las conexiones de clientes OWA, ActiveSync, Outlook (RPC/HTTPS), etc pasan por este rol:

Protocolos de acceso de cliente en Exchange 2013

El Client Access autentica y posteriormente cumple la función de proxy hacia el servidor con el rol de Mailbox, Como excepción tenemos el caso de mensajería unificada (UM) donde se hace una redirección en lugar de proxy.

En adición, encontramos el servicio de Front End Transport, este servicio es el que publicaríamos hacia Internet para recepción de correo (si no tenemos un servidor de Edge o algún otro tipo de smarthost en DMZ).

El rol de Acceso de clientes no encola mails, es decir que si el servidor de Mailbox se encuentra fuera de servicio, la recepción de correo externo (entre otras cosas) fallaría.

Dado que en general la función del CAS es la de hacer de proxy hacia el servidor con el rol de Mailbox, si este último se encuentra fuera de servicio el tener accesible el servidor con el rol de Client Access no aportaría nada.

En el caso de Exchange 2016 no es posible separar la instalación de este rol y pasa a ser a una serie de servicios incluidos en el de Mailbox, por fuera de esto la función conceptualmente es la misma e incluso si luego de instalado vemos los roles de un servidor con Exchange 2016 encontramos que también figura como Client Access.

Acceso de clientes en Exchange 2016

Como se puede observar en el diagrama, el protocolo utilizado por el cliente es el mismo que se utiliza para hacer de proxy desde los servicios de front end (CAS) a los de Backend (mailbox). Es decir que si un cliente se conecta por HTTP al CAS, este posteriormente hace proxy utilizando HTTP hacia el servidor con la base activa utilizando también HTTP. Lo mismo aplica a IMAP y POP. Claro que esto no sucede en texto plano sino que la comunicación es encriptada.

Para ofrecer alta disponibilidad podemos instalar el rol en múltiples servidores utilizando algún mecanismo de balanceo como NLB (no soportado en Exchange 2016), DNS Round Robin, HLB, etc.


Rol de Mailbox

En el rol de Mailbox se alojan las bases y es donde se realiza el procesamiento de datos.

En adición, se incluyen componentes de transporte; por un lado servicios para interactuar con la base de datos y por otro para hacerlo con el servicio de Front End del Client Access y otros servidores de Mailbox.

A diferencia de la entrada de mail, de forma predeterminada al crear un conector de envío, el rol que realiza la conexión es el de Mailbox. Esto en el caso de un servidor multirol o con Exchange 2016 no cambia la ecuación ya que siempre sería el mismo servidor.

En Exchange 2013 para utilizar al Client Access como proxy es necesario modificar las propiedades del conector (si tenemos los roles separados no sería un dato menor ya que la IP del servidor que envía debe estar habilitada en el firewall).

En el siguiente diagrama se puede ver la interacción:

Transporte en Exchange 2013

En lo que respecta a alta disponibilidad y contingencia tenemos como componente central al DAG (Database Availability Group).

Un DAG agrupa lógicamente servidores con el rol de Mailbox con la finalidad de replicar bases de datos mediante log shipping asincrónico.

Si bien se introducen varias mejoras en Exchange 2013 en relación a Exchange 2010, en el caso de 2016 no hay grandes cambios aunque se optimiza en varios aspectos la replicación y los tiempos asociados a failover y activación de bases. A tener en cuenta que como vemos en el artículo de Introducción a DAG no es posible combinar versiones de Exchange.

Por más info sobre Exchange 2013 / 2016 descargar el ebook de Fundamentos de Exchange Server

 

Consultor IT especializado en Microsoft Exchange y Active Directory.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist

6 Responses to Arquitectura de roles en Exchange

  1. Suha says:

    Buenos dias:

    Tengo una duda. En un Exchange 2013 no soy capaz de dar con el comando para saber las conexiones ActiveSync que está realizandose. En Exchange 2010 era Get-StoreUsageStatistics -database MB105LG01 |where {$_.digestcategory -like “logbytes”} | sort logrecordbytes -Descending |ft displayname,sampletime,logrecordcount,logrecordbytes -auto

    Esto me es muy util para saber quien me esta consumiendo logs delas BBDD cuando tenemos problemas de espacio

    Muchas gracias de antemano

  2. Jesus says:

    Hola Daniel, Buena Tarde.
    Quiero solicitar de tu apoyo, actualmente tengo un par de servidores de exchange 2013 los tengo en DAG, necesito actualizar los sistemas operativos, voy a mover mis bases de datos, a un solo servidor.
    Solo que no tengo los comandos para poner mi servidor de forma mantenimiento.. no se si tu tengas un procedimiento que recomiendes, para que mis actualizaciones sean exitosas

    Saludos

  3. Ivan Acosta says:

    tengo una consulta sobre los servidores front end y backend,

    Red Local: 192.168.1.0/24
    Red servidores 192.168.2.0/25
    Red DMZ 10.10.10.0/27
    tengo mi red segmentada en Red Local, Red Servidores,Red DMZ
    mi servidor de exchange 2013 backend lo tendria en mi red de servidores y el front end en la DMZ.

    mi consulta es la siguiente..

    Como implemento el front end en DMZ si el firewall bloquea todo el trafico que se genera en la DMZ hacia la red local y la red de servidores, es lo que no me queda claro.

    • Daniel Núñez Banega says:

      Hola Ivan, en Exchange 2013 tanto el rol de base de datos como el de acceso de clientes deben ir en la red interna, en tu caso en la red de servidores. La recomendación en este caso sería usar servidores multirol. En Exchange 2016 ya no tendrías la opción de separar roles.

      En cuanto a DMZ, el único rol de Exchange soportado es el de Edge.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Registrarse