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 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

Arquitectura 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.

Las conexiones de clientes OWA, ActiveSync, Outlook (RPC/HTTPS), pasan por este rol.

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.

How clients communicate with Exchange servers.

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.


Con esto llegamos al final del artículo, por más información teórica y práctica sobre roles e instalación de Exchange, ver el siguiente recurso (videos de entrenamiento):


About Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange, Active Directory y Microsoft 365.
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 | Microsoft 365 Certified: Enterprise Administrator Expert | Microsoft 365 Certified: Security Administrator Associate | Microsoft Certified: Cybersecurity Architect Expert | Comptia Pentest+ | EC-Council Certified Ethical Hacker Master

Reader Interactions

Comments

  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.

      • cesar Diaz says

        Hola Daniel, en caso del rol de acceso de clientes, como quedaria publicado hacia internet, seria hacer un NAT a la IP Publica o porque deberia de quedar sobre la red interna.

        saludos

        • Daniel Núñez Banega says

          Hola Cesar, el rol de acceso de clientes (CAS) debe estar en la red interna.
          Una publicación típica de este rol sería Internet -> IP pública en FW (NAT) -> IP Privada de ServidorCAS

          saludos

  4. Eduardo Granados says

    Hola Buenas tardes, alguien me puede decir para que se utiliza el ConversationAggregationLog. tengo Exchnage server 2016 y esa ruta esta creciendo de tamaño, requiero depurarla pero quisiera saber que es y que datos guarda.
    Espero alguien me pueda comentar al respecto.
    Saludos

  5. Eduardo Granados says

    Buenas tardes, alguien sabe que guarda este directorio: Archivos de programa \ Microsoft \ Exchange Server \ V15 \ Logging \ ConversationAggregationLog.

    Donde encuentro el archivo de configuración para modificar el período de retención de Logs a un número determinado de días.

    • Daniel Núñez Banega says

      Buenas Eduardo, respecto a tu duda sobre la carpeta ConversationAggregationLog, tenés un encabezado o alguna línea como para ver si se puede identificar el contenido?
      En cuanto a tu consulta sobre el período de retención de logs, a qué logs haces referencias? hay varios tipos y en la mayor parte de casos se controlan desde lugares diferentes.

  6. Juan Pablo Arias says

    Hola Daniel, tengo una consulta. tenís sólo un servidor Exchange Server 2016 onpremises, por un problema con la base de datos que se edsmontaba, instalé un segundo servidor y temporalmente moví todos los buzones a la segunda base de datos de este segundo servidor, luego de revisar el primer servidor con problemas, generé una nueva base de datos, al revisar que ya estaba estable, regresé todos los buzones a la base de datos del primer servidor y todo operaba correctamente; más tarde procedí a desinstalar el segundo servidor pero al hacerlo, dejé de poder enviar y recibir correos en el primero, supongo que la desinstalación no reasignó los roles correctamente. Volví a instalar el segundo servidor y la comunicación regresó de nuevo ¿Tienes algún procedimiento para realizar este proceso? sólo deseo tener un sólo servidor ya que mi organización es pequeña y no tengo uchos buzones.

    Saludos.

    • Daniel Núñez Banega says

      Hola Juan Pablo, me da la impresión de que hay algo que no está bien configurado, la organización debería poder funcionar con 1, 2 o más servidores y podría bajar la cantidad sin afectar el funcionamiento. Revisaría que la configuración esté acorde a las mejores prácticas, en el sitio tenes el manual de Exchange que te puede resultar útil.

  7. Saul says

    Buenos días Daniel.
    Actualmente tengo un Exchange 2016 CU22 Standalone y lo quiero migrar a otro Exchange 2016 CU22 santdalone, para posteriormente eliminar el primero. El caso es que ya he desplegado el segundo Exchange 2016 y me gustaria saber como actuan entre ellos dos. Por ejemplo, el segundo exchange , sin tener ningun buzón , daba problemas con el EAC y tuve que hacer unos cambios, como no había sincronización entre los dos Exchanges todos los buzones del primer servidor tenian problemas de delay en el correo interno y externo. Como es posible, si todos los buzones estan en el primer exchange?

    Muchas gracias de antemano.

    • Daniel Núñez Banega says

      Buenas Saul, en el momento que instalas un servidor adicional este ya comienza a funcionar para múltiples servicios de forma automática, ejemplo transporte y autodiscover.
      Dependiendo de la configuración de transporte si esto tendría impacto. Si querés que el segundo servidor no participe en el transporte podrías configurar los componentes como «inactivos». En el artículo de actualización de CU para Exchange se detalla como hacer esto. Saludos

Deja una respuesta

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