Fundamentos ExchangeServer V3 2

© 2 0 2 0 T o d o s l o s d e r e c h o s r e s e r v a d o s - A p r e n d i e n d o E x c h a n g e .
c o m
Contenido
Introducción .......................................................................................................................... 3
Ediciones de Exchange......................................................................................................... 4
Licencia de clientes (CAL) .................................................................................................... 5
Sistemas operativos soportados ........................................................................................ 7
Mejoras en Exchange 2013 / 2016 / 2019 ........................................................................ 8
Coexistencia......................................................................................................................... 16
Requerimientos de Hardware........................................................................................... 17
Requerimientos de Software ............................................................................................ 19
Active Directory y relación con Exchange ...................................................................... 20
Dominio ............................................................................................................................................. 21
Árbol de dominios ....................................................................................................................... 21
Bosque de Active Directory ..................................................................................................... 21
Particiones del directorio ......................................................................................................... 22
Catálogo Global ............................................................................................................................. 24
Replicación....................................................................................................................................... 25
Roles maestros (FSMO) ............................................................................................................. 26
Sitios de Active Directory ......................................................................................................... 27
DNS ....................................................................................................................................... 29
Registros DNS ................................................................................................................................ 30
Requerimientos de servicios de infraestructura............................................................ 34
Nivel funcional............................................................................................................................... 34
Preparación de Active Directory ........................................................................................... 35
Instalar Exchange en un controlador de dominio? ....................................................... 37
Arquitectura de roles ......................................................................................................... 38
Rol de Client Access..................................................................................................................... 42
Rol de Mailbox ............................................................................................................................... 44
Rol de Edge Transport................................................................................................................ 45
Sobre Exchange Híbrido .................................................................................................... 47
Beneficios de una implementación híbrida..................................................................... 47
Componentes principales en una implementación híbrida de Exchange ........ 48
© 2 0 2 0 T o d o s l o s d e r e c h o s r e s e r v a d o s P ágina |1
En qué tipo de organización es conveniente configurar Exchange híbrido? . 49
Proceso macro de configuración híbrida ......................................................................... 51
Sobre Exchange 2019 ......................................................................................................... 53
Consideraciones al planificar la implementación de Exchange 2019................. 57
Próximos pasos ................................................................................................................... 60
Introducción
Empresas de mediano y gran porte usan Active Directory y Exchange Server.
Independientemente de si utilizan el correo en la nube, entorno hibrido o
cuentan con una instalación local, el producto de correo electrónico por

excelencia es Microsoft Exchange.
Comprender cómo funciona, dónde almacena la información y cuáles son sus
dependencias es crítico para implementar o administrar la plataforma

correctamente.
Dada la similitud entre Exchange 2013, 2016 y 2019, lo mencionado en este

documento aplica a todos los casos salvo donde se indique algo diferente.
La realidad es que estas versiones son tan similares que si vemos el número de
“build” vamos a encontrar que mientras Exchange 2010 se corresponde al
número 14.xx.xxx.xxx (donde la segunda “xx” indica el Service Pack), Exchange
2013 al 15.00.xxx.xxx, en el caso de Exchange 2016 vemos 15.01.xxx.xxx (similar a
un Service Pack en Exchange 2010) y el caso de Exchange 2019 a 15.02.xxx.xxx.
Por fuera de lo anecdótico, a partir de Exchange 2013 incluyendo Exchange 2016

y 2019, las actualizaciones vienen en forma de CU (Cumulative Update) y ya no
contamos con Service Packs (SP) o Rollup Updates (RU). Estos Cumulative Update
incluyen todo el producto y las actualizaciones, esto significa que al descargar el

último CU tenemos lo necesario para realizar la instalación de Exchange y dejarlo
completamente actualizado en un solo paso.
En este ebook "Fundamentos de Exchange server" (edición enero 2020) vemos

conceptos introductorios incluyendo versiones, características, requerimientos,
arquitectura y su relación con Active Directory de tal forma de "nivelar" y generar
cimientos que habiliten a pasar a temas más avanzados a futuro.
Ediciones de Exchange
Exchange 2013 / 2016 / 2019 se encuentran disponibles en 2 ediciones; Standard
y Enterprise.
En ambos casos el medio de instalación es el mismo, la diferencia se encuentra en
la clave del producto que varía en función a la versión adquirida. Esta clave es la
que determina que edición se activa.
De forma predeterminada se comporta como si fuera Standard.
El utilizar la versión Standard o Enterprise de Exchange depende de la cantidad

de base de datos requeridas por servidor (incluyendo activas y pasivas):
• Exchange 2013 / 2016 / 2019 Standard – máximo 5 bases montadas

• Exchange 2013 / 2016 / 2019 Enterprise – máximo 100 bases montadas
Nota: La base especial de recuperación (Recovery Database) no se toma en

cuenta dentro de este límite.
Adicionalmente en el caso de Standard las bases están limitadas a un máximo de

1TB aunque con algunas limitantes es posible incrementar esto mediante la
edición del registro.
A nivel práctico podríamos decir que la única diferencia entre estas versiones y al
igual que en el caso de Exchange 2010 es la cantidad de bases de datos, desde el
punto de vista de características, clientes o alta disponibilidad ambas cuentan con

la misma funcionalidad.
Licencia de clientes (CAL)
En adición a las ediciones de servidor de Exchange tenemos 2 tipos de licencia de
cliente (CAL: Client Access License):
• Exchange Server Standard CAL
• Exchange Server Enterprise CAL
Cada usuario con buzón requiere una CAL standard, opcionalmente y de forma
adicional se puede agregar la Enterprise CAL.
La Enterprise CAL (eCAL) habilita mayor funcionalidad como por ejemplo

administración avanzada de dispositivos móviles, mensajería unificada o buzón
de archivado.
En la siguiente tabla 1se pueden ver las características incluidas dentro de la CAL
Standard y que es lo agrega la Enterprise:
1
https://products.office.com/es-es/exchange/microsoft-exchange-server-licensing-licensing-overview
La CAL que utiliza el cliente no tiene relación con la edición que utiliza el servidor,
esto se presta muchas veces a la confusión, es decir que se puede utilizar

Exchange Server Enterprise y contar únicamente con CAL Standard para los
usuarios.
Adicionalmente es posible contar con usuarios que cuentan con CAL Enterprise
(en adición a la Standard) porque requieren cierta funcionalidad que otros

usuarios no necesitan. En este caso se debe tener en cuenta el costo adicional de
esta licencia, por este motivo es usual encontrar que usuarios “VIP” tengan este
tipo de licencia mientras que usuarios “comunes” solo cuenten con la Standard.
Sistemas operativos
soportados
La versión actual de Exchange 2013 (CU23 al momento de esta revisión) corre
sobre las siguientes versiones de sistema operativo:
• Windows Server 2008 R2 SP1 (Standard o Enterprise y no soportado a
partir del 14/01/2020)

• Windows Server 2012 (Standard o Datacenter)
• Windows Server 2012 R2 (Standard o Datacenter)
En el caso de Exchange 2016 (CU15 al momento):
• Windows Server 2012 R2 (Standard o Datacenter)

En el caso de Exchange 2019 (CU4 al momento):
Más allá de las ventajas incluidas en las versiones más nuevas de Windows
podríamos decir que una de las que más aporta es la posibilidad de implementar
alta disponibilidad con la versión Standard de Windows Server (a partir de
Windows Server 2012).
En el caso de Windows Server 2008 R2 SP1 sería necesario la versión Enterprise ya

que en la Standard no se incluyen los componentes de clustering (dependencia
del DAG). Esto implica un costo muy superior cuando se implementa DAG sobre
2008 R2. De cualquier modo hace tiempo que esta versión no sería la mejor
opción para el despliegue de Exchange.
Independientemente de la versión de sistema operativo en el caso de Exchange

2013 y 2016 no es posible instalar sobre Server Core, la instalación debe ser
completa (con GUI). Esto cambia a partir de Exchange 2019, siendo la primer
versión de Exchange soportada (y recomendada) sobre Windows Server Core.
Mejoras en Exchange 2013 /

2016 / 2019
A partir de Exchange 2013 se incluyen varias mejoras, algunas muy técnicas y que
a simple vista no tienen impacto, otras más visibles ya que interactuamos de
forma más directa, dentro de estas últimas se destacan las siguientes:
Nueva interfaz administrativa
Desaparece la Exchange Management Console (EMC) utilizada en Exchange 2007
/ 2010 y se introduce el Exchange Admin Center (EAC).
La nueva interfaz de administración es web y aunque en primera instancia esto

pueda resultar como algo negativo es cuestión de adaptarse, trabajar con el EAC
es mucho más ágil que con la EMC, en adición puede ser accedida desde
cualquier lado a diferencia de la EMC que requería instalar las herramientas

administrativas o iniciar una sesión de terminal en el servidor.
2
https://technet.microsoft.com/en-us/library/jj150562(v=exchg.150).aspx
Outlook Web App (Exchange 2013)
OWA es rediseñado y optimizado para tablets y smartphones en adición a

equipos de escritorio y laptops.
Dentro de las nuevas características una muy importante es la posibilidad de

utilizar OWA sin conexión (se debe utilizar un navegador soportado). Con
OWA fuera de línea se pueden realizar las tareas más comunes, estas
posteriormente son sincronizadas con el servidor una vez reanudada la conexión.
Si bien existen limitantes, las características principales como lectura, edición,

envío / respuesta de correo, acceso al calendario y contactos se encuentran
disponibles.
3
http://blogs.technet.com/b/exchange/archive/2012/08/02/the-new-owa-rocks-tablets-and-phones.aspx
Outlook on the Web (Exchange 2016 / 2019)
En adición a los cambios incluidos en Exchange 2013, en el caso de Exchange

2016 y 2019 se mejora la interfaz brindando una mejor experiencia para
dispositivos con Android e IOS entre otros.
Entre las principales mejoras en Outlook on the Web encontramos:
• Calendario
• Integración de contactos con linkedin
• Búsquedas mejoradas
• Nuevos temas
• Opciones de OWA (opciones no incluidas en versiones anteriores)

• Organización mejorada (Pins y banderas)
• Rendimiento
• Panel de acciones
En adición, características de embebido de videos y URLs en el cuerpo del

mensaje:
© 2 0 2 0 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 10
Carpetas públicas modernas
Desaparece la base pública de versiones anteriores y se introduce el buzón de

carpetas públicas “Public Folder Mailbox”. Esto implica que se almacene como un
buzón más dentro de la base de datos de Exchange y su información pueda ser
replicada dentro de un DAG.
Una de las grandes ventajas de esto es no tener que manejar bases públicas de
un gran tamaño sino que es posible dividir la información en varios buzones y
ubicarlos en la base de datos que tenga más sentido (por ejemplo desde el punto
de vista de proximidad).
En el caso particular de Exchange 2016 y 2019 se integran las características de

eDiscovery con las carpetas públicas de tal forma de realizar búsquedas
centralizadas y mantener información en base a tiempo u otro tipo de consultas.
En adición se agregan comandos específicos orientados al cumplimiento de
normas “*-ComplianceSearch”.
4
http://blogs.technet.com/b/exchange/archive/2014/08/26/public-folder-updates-in-cu6-improving-scale-and-more.aspx
Disponibilidad administrada (Managed Availability)
Con Managed Availability se incluye monitoreo de los componentes internos y

características de recuperación con foco en la experiencia de usuario. Este servicio
monitorea la salud de los componentes y dependiendo del caso puede reiniciar
un servicio, application pool, servidor completo o escalar a un administrador:
5
https://technet.microsoft.com/en-us/library/dn482056(v=exchg.150).aspx
Prevención de pérdida de datos (DLP)
Mediante el uso de DLP es posible reducir el riesgo de exposición de datos

confidenciales. Por ejemplo detectar si un correo incluye números de tarjetas de
crédito y advertir con un Policy Tip (similar al mailtip).
En Exchange 2016 y 2019 se incluyen nuevas condiciones, acciones y más de 80

tipos de datos para ser utilizados en políticas de DLP como por ejemplo:
• Credit Card Number

• International Banking Account Number (IBAN)
• SWIFT Code
• U.S. Bank Account Number
En adición se pueden adquirir plantillas de terceros o generar personalizadas.
Distintos patrones pueden ser identificados independientemente de si se
encuentran en el cuerpo del mensaje o dentro de algún adjunto:
6
https://blogs.office.com/2013/10/28/office-365-compliance-controls-data-loss-prevention/
7
MAPI sobre HTTP
MAPI sobre HTTP es un nuevo protocolo de transporte utilizado por Outlook para
conectarse con Exchange. Este mecanismo es introducido en Exchange 2013 SP1
(CU4) con el objetivo de reemplazar RPC sobre HTTP conocido como Outlook
Anywhere.
MAPI sobre HTTP utiliza una nueva arquitectura simplificada, diseñada para
mejorar la experiencia del usuario. La principal ventaja es a nivel de tiempos de
conexión y reconexión al cambiar de redes o por ejemplo cuando un equipo sale
de un estado de hibernación.
En Outlook Anywhere se da una doble encapsulación; MAPI dentro de RPC y este
dentro de HTTP, en el nuevo protocolo esto es más “directo” ya que hay una
encapsulación simple: MAPI dentro de HTTP.
7
https://blogs.office.com/2013/10/28/office-365-compliance-controls-data-loss-prevention/
En el siguiente diagrama se puede ver gráficamente este cambio:
En Exchange 2016 y 2019 es el protocolo predeterminado aunque en estado de
coexistencia con Exchange 2013, dependiendo de la configuración podría no

estar habilitado.
8
https://blogs.technet.microsoft.com/exchange/2014/05/09/outlook-connectivity-with-mapi-over-http/
Coexistencia
Las opciones de migración y coexistencia van a depender de los requerimientos
específicos, si partimos de la base de que la organización cuenta con un bosque
de Active Directory (con 1 o más dominios) y quiere hacer la transición a

Exchange 2013, 2016 o 2019 dentro del mismo bosque (escenario más común), la
versión de Exchange que podamos instalar va a depender de la versión que se

tenga implementada en la organización y de cuál sea la última versión estable del
producto..
Exchange soporta coexistencia con N-2 versiones del producto. Esto significa que
en el caso de Exchange 2013 podríamos migrar desde Exchange 2007 o 2010

directamente, mientras que en el caso de Exchange 2016 se podría desde
Exchange 2010 o 2013 pero no desde 2007. En cuanto a Exchange 2019, misma
situación (N-2), puede coexistir con Exchange 2016 o 2013 pero no con versiones
anteriores.
En cualquier caso, las versiones en uso de Exchange deben estar actualizadas y si

bien en la documentación oficial se plantean requerimientos mínimos a este nivel,
la recomendación es estar al día con todas las actualizaciones.
En caso de contar con una versión anterior como por ejemplo Exchange 2003, la
alternativa sería una migración entre bosques (con varias particularidades e

incluso podría requerir herramientas de terceros si no se cuenta con un Exchange
2010 en destino), este sería un escenario mucho más complejo por lo que podría
resultar más simple actualizar Exchange 2003 a 2007 o 2010 y así continuar hasta
llegar a la versión deseada.
Requerimientos de Hardware
A nivel de hardware se requiere procesador de 64 bits no Itanium, puede ser Intel
o AMD, 4GB / 8GB de memoria dependiendo del rol (en el caso de Exchange
2013 / 2016) y a nivel de disco 30GB como mínimo en la unidad de instalación
teniendo en cuenta también el archivo de paginación ya que este puede ser muy
grande dependiendo de la cantidad de memoria RAM instalada.
La recomendación en este sentido es configurar el archivo de paginación de
forma estática configurando un tamaño mínimo y máximo en la cantidad de RAM

instalada + 10 MB llegando a un máximo de 32778MB en servidores con 32GB o
más de memoria.
En el caso de Exchange 2019 encontramos importantes requerimientos a nivel de
memoria comenzando por 128GB de RAM, también cambia la recomendación a

nivel de archivo de paginación especificando un tamaño mínimo y máximo de un
25% del total de memoria RAM instalada.
En cualquier caso también hay que tener en cuenta espacio para la cola de
correos y espacio libre en la unidad. Más info sobre esto y dimensionamiento en

general en el siguiente artículo:
• 7 errores que no querrás cometer trabajando con Exchange
En cuanto a sistema de archivos, NTFS para partición de sistema y binarios de

Exchange.
En el caso de datos como bases, logs de transacciones e índices podemos usar
NTFS o ReFS, siendo este último el recomendado teniendo en cuenta de

deshabilitar la característica de chequeo de integridad.
A nivel de formateo de las unidades de bases y logs es necesario especificar un

tamaño de bloque de 64k.
Más allá de los requerimientos mínimos de hardware que podrían ser suficientes
para un ambiente de testing, el dimensionamiento de Exchange implica

considerar:
• Arquitectura de servidores con el rol de Catálogo Global

• Utilización de servidores físicos o virtualizados
• Requerimientos de alta disponibilidad / contingencia

• Arquitectura de roles
• Aplicaciones de terceros
• Perfiles de usuario de mensajería
o Cantidad de usuarios
o Cuotas de buzón
o Requerimientos de retención
• Requerimientos de Backup
• Cantidad y tamaño de bases de datos (relacionado a la edición de
Exchange a utilizar)
Los puntos listados son algunos de los aspectos a tener en mente.
El dimensionamiento de Exchange no es tan simple como multiplicar cuota de

buzón (tamaño máximo) por cantidad de usuarios sino que hay varios factores a
tener en cuenta. Esta es una etapa fundamental en todo proyecto de
implementación de Exchange.
En este sentido es recomendable utilizar la calculadora de requerimientos de

Exchange, esta herramienta es una planilla de excel9 que cuenta con varias hojas,
incluyendo una para entrada de datos del ambiente específico y otras que
incluyen los resultados, recomendaciones, requerimientos, cantidad de

servidores, bases de datos y estrategia de respaldos entre otros.
9
http://aprendiendoexchange.com/dimensionamiento-calculadora-requerimientos-exchange
Requerimientos de Software
En cuanto a requerimientos de software, en primera instancia tenemos la versión
de sistema operativo como se detalla en la sección de Sistemas Operativos
soportados. Si solo se desea instalar herramientas administrativas es posible usar
una versión cliente como Windows 8.1 (Exchange 2013 / 2016) y Windows 10
(Exchange 2013 / 2016 / 2019).
Adicionalmente, en todos los casos se requieren otros componentes como por
ejemplo específicos de Internet Information Services, .Net Framework, UCMA,

Filter pack de office, herramientas administrativas de Active Directory y Windows
Management Framework. Dependiendo de la versión de sistema operativo que

utilicemos cuáles sean los requerimientos exactos. Si utilizamos una versión
reciente de Windows, en general con componentes de IIS y el UCMA es
suficiente.
A nivel de versión específica de .Net Framework la recomendación es utilizar la

más reciente mientras se encuentre soportada para la versión de Exchange que se
encuentre instalada. Se puede dar en algún caso, que una nueva versión no sea
compatible con Exchange hasta no liberarse alguna actualización donde se
incluya este soporte. Esto pasó por ejemplo con el .Net Framework 4.6.1.
Por último, en relación al Windows Management Framework, únicamente se

soporta la versión incluida en el Sistema operativo.
Active Directory y relación
con Exchange
A partir de Windows Server 2008 Active Directory abarca un conjunto de
productos o servicios:
• Active Directory Domain Services (ADDS)

• Active Directory Lightweight Directory Services (ADLDS)
• Active Directory Federation Services (ADFS)

• Active Directory Rights Management Services (ADRMS)
• Active Directory Certificate Services
Independientemente de esto, en general cuando se habla de Active Directory o

Directorio Activo sin especificar se hace referencia a Active Directory Domain
Services.
Servicios de dominio de Active Directory
Active Directory Domain Services es un servicio de directorio que permite

almacenar y administrar información de usuarios, computadoras, impresoras,
aplicaciones y otros objetos de la red de forma centralizada y segura.
Desde Exchange 2000 Active Directory es el servicio de directorio utilizado por
Exchange. En Active Directory se almacena información de configuración y

destinatarios de correo.
Cada vez que Exchange requiere información de configuración o sobre algún

destinatario consulta Active Directory, si este no se encuentra disponible
Exchange no va a funcionar correctamente.
Debido a la fuerte integración de Exchange con Active Directory es importante

entender los conceptos más básicos en relación a su interacción con el directorio,
donde almacena información y que componentes requiere.
Dominio
Un dominio de Active Directory es un contenedor lógico utilizado para
administrar usuarios, grupos y computadoras entre otros objetos.
Todos estos objetos son contenidos en una partición específica dentro de la base
de datos de AD DS. Cada servidor con el rol de controlador de dominio almacena

una copia de esta base.
Un dominio de Active Directory funciona como una frontera de replicación,
cuando se realizan modificaciones, los controladores de dominio replican el

cambio de tal forma de mantener sincronizada la base.
Árbol de dominios
Un árbol de dominios (tree) es una colección de uno o más dominios que
comparten un espacio de nombre contiguo. Por ejemplo si el primer dominio se
llama contoso.com y tiene un subdominio, este sería subdominio.contoso.com.
En un bosque de Active Directory pueden existir múltiples árboles de dominio.
Bosque de Active Directory

En Active Directory el bosque (forest) es una colección de uno o más dominios
que comparten una misma estructura lógica, catálogo global, esquema y
configuración.
Todos los dominios del bosque cuentan con relaciones de confianza automáticas
de 2 vías y transitivas.
El bosque representa una instancia completa del directorio y una frontera de

seguridad.
En el diagrama a continuación vemos un bosque compuesto por un árbol con un
dominio raíz y 2 subdominios. Las OU representan contenedores utilizados con el

propósito de organizar y administrar los objetos de forma eficiente:
10
Exchange tiene una relación 1:1 con el bosque de Active Directory, esto significa
que un bosque solo puede tener una organización de Exchange y una
organización no puede expandirse más allá del bosque.
Particiones del directorio

La información en la base de datos de Active Directory es almacenada en
particiones. Estas particiones almacenan distintos tipos de información y actúan
como unidades de replicación.
Partición de Dominio
En esta partición se almacena información de usuarios, grupos, computadoras,
OU. Esta partición es replicada entre todos los controladores de dominio del
dominio.
Un conjunto parcial de atributos se replica a todos los controladores de dominio

del bosque con el rol de catálogo global.
Específicamente en relación a Exchange en la partición de dominio se almacena
información de destinatarios, por ejemplo:
• Usuarios con buzón
• Usuarios habilitados para correo
10
https://technet.microsoft.com/en-us/library/cc756901(v=ws.10).aspx
• Carpetas públicas habilitadas para correo
• Contactos habilitados para correo

• Grupos de distribución (sean dinámicos, de seguridad o distribución)
Partición de Configuración
En la partición de configuración se almacena información global de

configuración, por ejemplo configuración de sitios de Active Directory, PKI y
Exchange entre otros. Esta partición es replicada entre todos los controladores de
dominio del bosque.
En relación a Exchange encontramos prácticamente toda la configuración;

información de base de datos, conectores, servidores, protocolos, etc.
Esto no quiere decir que acá se almacenen datos de correos de usuario,

únicamente información de configuración, por ejemplo tenemos “X” cantidad de
base de datos, se llaman “X1”, “X2”, etc y se encuentran ubicadas en las unidades
“H” y “J”.
Esta información puede ser de utilidad en una variedad de escenarios,
especialmente frente a una eventualidad que nos lleve a reconstruir un servidor o

en caso de tener que eliminar algo a bajo nivel (por ejemplo con ADSIEDIT).
Partición de Esquema
En el esquema es donde se definen las clases y atributos de los objetos que
podemos tener en el directorio. Este esquema es extensible y es lo primero que

debemos preparar antes de instalar Exchange. El esquema es único por bosque y
es replicado entre todos los controladores de dominio.
Partición de Aplicación
En adición tenemos particiones de aplicación. Si bien Exchange no almacena
información en este tipo de partición, en general se utilizan a nivel de DNS,

servicio en el cual Active Directory depende y en consecuencia Exchange.
Catálogo Global
El Global Catalog (GC) incluye una copia parcial de solo lectura que contiene
información de los atributos más utilizados de todos los objetos del bosque.
Entre otras cosas en lugar de tener que consultar DC por DC de cada dominio (de
contar con más de uno) permite acelerar las búsquedas en el bosque consultando
directamente al GC ya que tiene información de todos los objetos (funcionando
como un índice).
En adición, la membresía de grupos universales se almacena en el Catálogo

Global. Exchange desde la versión 2007 no permite la creación de grupos no
universales para correo. Durante el período de coexistencia con una versión
anterior sería posible la utilización de este tipo de grupos pero una vez finalizada
esta etapa, estos grupos deben ser modificados para ser administrados por la
nueva versión.
Independientemente de si se utiliza un bosque con un único dominio o con

múltiples dominios, Exchange consulta al GC.
Todo Catálogo Global es controlador de dominio, mientras que no todo

controlador de dominio es GC. Dependiendo de la cantidad de servidores,
dominios, etc cuál sería la recomendación respecto a la ubicación de los
controladores con rol de GC.
En el escenario más usual, donde encontramos un bosque compuesto por un

único dominio, la recomendación en general es que todos los controladores de
dominio sean Catálogo Global.
En el siguiente diagrama tenemos un bosque compuesto por 4 dominios; el

dominio raíz y 3 subdominios. Si por ejemplo examinamos la base de datos
(ntds.dit) de un controlador de dominio del dominio “A” encontramos la partición
de dominio (A), configuración y esquema, si el controlador de dominio es además

catálogo global tendría las mismas 3 particiones más una réplica parcial de las
particiones de los dominios B, C y D:
11
En adición a Exchange, el catálogo global es crítico para otro tipo de escenarios,

quizás el más básico sea el inicio de sesión de los usuarios.
Dada la criticidad de este servicio se recomienda que existan al menos 2 DC con
el rol de GC y que al menos exista 1 GC en cada sitio donde se encuentre un

servidor con Exchange instalado.
Replicación
Los controladores de dominio utilizan un modelo de replicación multimaster, es
decir que podemos realizar cambios en cualquier controlador de dominio y estos
posteriormente serán sincronizados entre sí.
11
https://technet.microsoft.com/en-us/library/how-global-catalog-servers-work(v=ws.10).aspx
A partir de 2008 se incluye un tipo de controlador de dominio de solo lectura:
RODC (Read Only Domain Controller), el cual a su vez puede funcionar como
catálogo global.
En lo referente a Exchange lo que se debe tener en cuenta es que este tipo de

controlador de dominio no está soportado, puede existir en la red pero al menos
un controlador de dominio de lectura y escritura debe estar funcionando.
Roles maestros (FSMO)

Si bien Active Directory utiliza un modelo multimaster de replicación, existen
operaciones específicas que dependen de un controlador de dominio con un rol
específico. De forma predeterminada estos roles son asignados al primer DC del
bosque.
En Active Directory tenemos 5 roles maestros (FSMO: Flexible Single Master

Operations); 2 globales a nivel de bosque (en el primer dominio del bosque) y 3
por cada uno de los dominio del bosque:
• FSMO por bosque
o Schema Master
o Domain Naming Master
• FSMO por dominio
o PDC Emulator
o RID Master
o Infrastructure Master
De forma predeterminada, si tenemos un único dominio, los 5 roles estarían

alojados en el primer controlador. Si tenemos dominios adicionales, en cada uno
el primer controlador va a contar con los 3 específicos. Por distintos motivos es

posible separar o distribuir estos roles.
La mayoría de estos roles se utilizan para tareas puntuales y en algunos casos

hasta podrían encontrarse fuera de línea sin derivar en demasiado impacto, pero
si por ejemplo al preparar Active Directory para Exchange, el rol del esquema no
se encuentra disponible, el proceso va a fallar.
Sitios de Active Directory

Un sitio de Active Directory representa la topología física de la red en el
directorio. Un sitio podría ser definido como un conjunto de subredes bien

conectadas.
Exchange utiliza sitios de Active Directory para localizar los DC/GC más cercanos
y para el ruteo de mensajes, esto es importante cuando tenemos más de un sitio

con servidores de Exchange instalados.
De forma predeterminada se crea el Default-First-Site-Name sin subredes

definidas lo que básicamente indicaría que toda la red está asociado a este sitio.
Si se cuenta con un único sitio esto podría ser suficiente.
De haber más de un sitio físico, por ejemplo un edificio principal y una oficina
remota conectada por un enlace lento sería posible definir un sitio de Active
Directory asociado a cada ubicación física y así los clientes o servicios que
dependen de Active Directory podrían encontrar los controladores de dominio

más cercanos.
Mediante la configuración de sitios de Active Directory es posible optimizar los

procesos de replicación, autenticación y localización de servicios en la red.
La cantidad de sitios no tiene relación con la de dominios; un sitio podría abarcar
varios dominios (dentro de un mismo bosque) así como se podrían utilizar

múltiples sitios para un único dominio. El sitio tiene relación con la estructura
física de Active Directory mientras que el dominio con la estructura lógica:
12
12
https://technet.microsoft.com/en-us/library/cc782048(v=ws.10).aspx
DNS
DNS (Domain Name System) es un sistema de resolución de nombres. Si bien
este servicio aplica a una variedad de escenarios, como por ejemplo navegación
web, en esta oportunidad vamos a ver lo más pertinente en relación a Active

Directory y Exchange.
Active Directory depende de DNS y lo utiliza para todo lo referente a registro de
nombres, localización de servicios y resolución. Al día de hoy DNS es un

requerimiento básico, sin DNS no hay Active Directory y sin este no hay
Exchange.
DNS provee una base de datos jerárquica y escalable donde hosts (equipos con
TCP/IP) pueden consultar y actualizar sus registros
En un entorno con Active Directory se recomienda instalar el servicio de DNS en

un controlador de dominio. Esto es una excepción ya que en general la
recomendación es no instalar nada en un DC, pero el caso puntual de DNS ofrece
varias ventajas:
• Integración de información de zonas dentro de Active Directory (esto

implica que utilizaría el mismo mecanismo de replicación que el de AD)
• No es necesario utilizar zonas primarias y secundarias. Las zonas primarias
son de lectura y escritura, las secundarias de solo lectura, si hay un

problema con la zona primaria no sería posible actualizar registros
• Actualización dinámica y segura de registros en DNS
Cuando se instala un controlador de dominio se configuran una serie de registros

en DNS. Estos registros van más allá del típico registro A (que resuelve nombre a
IP), incluyendo registros SRV (Service Locator) utilizados para localizar servicios en
la red, por ejemplo para LDAP, Kerberos e información específica de sitios entre
otros.
Exchange utiliza estos servicios para localizar controladores de dominio /
catálogo global, información de sitios para ruteo de mail, autenticación, etc.
Algo fundamental en este aspecto es que tanto los controladores de dominio

como los servidores de Exchange deben estar configurados con las IP de los DNS
internos, en ningún caso se debe configurar un DNS externo (error común
cuando se intenta configurar resolución de nombres hacia Internet).
Registros DNS
Exchange utiliza varios tipos de registros en DNS, algunos son utilizados
internamente, otros se utilizan a nivel externo por ejemplo para intercambiar
correo con otras organizaciones:
Registro A
El registro A se utiliza para resolver un nombre de host a su dirección IPv4.

Internamente en general los equipos registran automáticamente su nombre
dentro de la zona de dominio.
En el caso de Exchange puede ser necesario crear registros A explícitos en la zona

interna por cuestiones de configuración de certificados y servicios específicos.
Este tipo de registro también es necesario en la zona externa de la organización,

por ejemplo para incluir un registro “mail.empresa.com” apuntando a una IP
pública.
Registro PTR
El registro PTR (Pointer) resuelve una dirección IP a un registro A (ej:

mail.dominio.com), a nivel de correo electrónico este podría ser chequeado
externamente cuando enviamos mail fuera de nuestra organización.
Por ejemplo, si el servidor de correo destino hace un consulta reversa al nombre

con el que se presentó nuestro servidor de envío (smarthost o Exchange), este
debería coincidir con la dirección IP utilizada, de lo contrario podría derivar en el

rechazo de correos de la organización.
Registro SRV
El registro SRV identifica servidores que proveen servicios específicos en la red,

por ejemplo los clientes utilizan registros SRV para localizar controladores de
dominio, GCs y en muchos casos configuración de aplicaciones como Outlook o
Activesync.
Registro MX
Para que una organización externa pueda enviarnos mail esta debe ser capaz de
localizarnos, para esto se utilizan registros MX (Mail Exchanger). Esto es
independiente a si usamos Exchange u otro tipo de servidor de correo.
Este registro MX es utilizado por organizaciones externas y no lo precisamos

internamente. Del mismo modo cuando nuestra organización envía correo
debemos ser capaces de localizar un registro MX del dominio destino.
El registro MX debe apuntar a un registro de tipo “A” que a su vez apunta a una
dirección IP (se pueden usar alias o cname pero esto no es recomendado).
En adición, los registros MX utilizan lo que se conoce como “preferencia”, cuanto

más bajo sea el número de preferencia, mayor prioridad tiene el registro.
La preferencia puede ser utilizada para obtener balanceo y alta disponibilidad a

nivel de recepción de correo, por ejemplo se podría tener un registro MX
dedicado para un sitio principal y otro con menor prioridad apuntando a una IP
de contingencia como “backup”.
Si tenemos una pequeña organización con un único sitio y sin alta disponibilidad,
con un registro MX sería suficiente.
13
En general, en producción vamos a encontrar que los registros MX apuntan a un

registro A asociado a una IP pública en un firewall de frontera que
posteriormente hace NAT a un servidor corriendo software de antivirus
/antispam y configurado para reenviar todo mail entrante a nuestro Exchange.
Como alternativa, en caso de no tener un servidor adicional para higiene de

transporte, el NAT podría estar configurado directo hacia el Exchange.
Registro SPF
El registro SPF (Sender Policy Framework) es utilizado para indicar desde qué
hosts nuestra organización podría enviar correo. De este modo una organización
destino podría verificar la IP desde la que se conecta nuestro servidor de envío y
en base a si existe un registro SPF y coincide o no con nuestra IP que acción
tomar.
Este tipo de registro es muy utilizado para evitar el spoofing de mails, por
ejemplo cuando se recibe spam desde direcciones supuestamente internas.
13
https://technet.microsoft.com/en-us/library/ff634392(v=exchg.141).aspx
14
De tener un registro SPF configurado, cuando el servidor recibe este tipo de

correo, chequearía que la IP desde la que proviene no coincide con las indicadas
en el registro SPF y en base a esto dependiendo de la configuración del filtro si lo
rechaza o simplemente estampa el resultado para posterior análisis.
Por último, a tener en cuenta que si bien en la documentación general se trata

este tipo de registro como SPF, técnicamente a nivel de configuración de DNS es
un registro de tipo TXT (se puede encontrar más información sobre su evolución
en Wikipedia).
14
https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
Requerimientos de servicios
de infraestructura
Active Directory es el principal requerimiento para Exchange, lo que deriva en que
se dependa de DNS para la resolución de nombres, localización de servicios, etc.
Nivel funcional
En Exchange 2013 como mínimo se debe contar con nivel funcional de dominio y
bosque en Windows Server 2003.
Los controladores de dominio en Windows Server 2003 deben estar actualizados

con Service Pack 2. Pueden existir distintas versiones de sistema operativo en los
DC, como por ejemplo DCs en 2003 y otros en 2008 R2, esto no afecta a
Exchange.
En caso de Exchange 2016, a partir del CU7, el nivel funcional del bosque y
dominio deben ser Windows Server 2008 R2, lo que indica que no podríamos
tener DCs con una versión anterior a 2008 R2.
En el caso de Exchange 2019 tanto el nivel funcional de bosque y dominio deben

ser Windows Server 2012 R2 o superior.
A tener en consideración que no es posible utilizar RODC/GC (controlador de

dominio de solo lectura) para Exchange, es decir que requiere controladores de
dominio de lectura y escritura.
El nivel funcional de dominio y bosque no tiene relación con la versión de sistema
operativo soportado en los servidores de Exchange. Por ejemplo, nivel funcional

de dominio y bosque en 2003 indicaría que no se pueden tener controladores de
dominio con una versión anterior a 2003, pero si se podría con una versión
superior (solo aplica a la versión de sistema operativo de los controladores de
dominio).
El nivel funcional asegura que la funcionalidad del directorio se adecue al nivel
más compatible, es decir que si el nivel funcional se encuentra en 2003, y se

incluyen controladores de dominio en Windows Server 2012, características como
por ejemplo papelera de reciclaje de Active Directory no podrían ser habilitadas
ya que no se encuentran soportadas en controladores de dominio anteriores a
2008 R2.
Incluso si todos los controladores de dominio corren una versión reciente de
sistema operativo pero el nivel funcional no fue elevado, las nuevas características
no van a estar disponibles.
Preparación de Active Directory

El primer paso antes de instalar Exchange es extender el esquema de Active
Directory. El usuario que ejecute esta tarea debe ser miembro del grupo de
administradores del esquema.
La preparación de Active Directory abarca más que solo extender el esquema y

puede ser ejecutada de forma separada a la instalación de Exchange (por línea de
comando) o puede ser incluida como tarea inicial dentro del proceso de
instalación (de forma automática si se cuenta con los permisos necesarios).
A nivel macro, la preparación consiste en lo siguiente:
1. Extensión de esquema. En este paso extendemos el esquema de Active
Directory para agregar clases y atributos específicos de Exchange.

2. Creación de contenedores en partición de configuración, asignación de
permisos, OU con grupos de seguridad, etc.
3. Preparación de cada dominio adicional que vaya a tener servidores de
Exchange u objetos habilitados para correo.
A nivel de permisos es requerido pertenecer a los grupos de Schema y Enterprise
Admin. Estos permisos se requieren únicamente para realizar la preparación, una

vez ejecutado el proceso, estos no serían requeridos para administrar la
plataforma.
Independientemente de esto, muchas actualizaciones (CU) requieren preparar de
algún modo el directorio por lo que podrían volver a ser necesarios. En cualquier
caso, cuando se requiera preparar el directorio el proceso se ejecuta solo una vez.
Instalar Exchange en un
controlador de dominio?
Instalar Exchange en un controlador de dominio tiene muchas limitantes,
principalmente desde el punto de vista de seguridad y rendimiento.
Exchange requiere Active Directory pero este requerimiento no implica que se
deba instalar en un servidor con el rol de controlador de dominio.
La recomendación es instalar Exchange en un servidor miembro del dominio.
En adición, suponiendo el escenario donde Exchange ya se encuentra instalado

en un servidor miembro, no es soportado promover este servidor a controlador
de dominio y lo mismo a la inversa, es decir, si se instala Exchange sobre un
controlador de dominio no estaría soportado que posteriormente se

despromueva el rol de DC (demote).
En caso de ser necesario cambiar el rol de un servidor con Exchange instalado, el

mecanismo soportado sería generar un nuevo servidor de Exchange, mover toda
la funcionalidad, información de buzones, etc y por último desinstalar Exchange

en el servidor original.
Arquitectura de roles
En Exchange 2007 y 2010 existían 5 roles, en Exchange 2013 esto se redujo a los
siguientes 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 la configuración recomendada.
Estos roles podrían estar distribuidos en varios servidores de existir algún
requerimiento especifico. Lo importante a tener en consideración es que para

tener una instalación funcional es necesario contar con ambos roles, sea en un
mismo servidor o en servidores separados.
Una pequeña organización podría contar con un único servidor con ambos roles
instalados mientras que organizaciones que cuenten con requerimientos de alta
disponibilidad necesitarían como mínimo 2. Actualmente la recomendación es
utilizar servidores multirol siempre que sea posible.
En adición tenemos el rol de Edge Transport el cual 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:
15
En el diagrama tenemos del lado derecho la red interna. Acá encontramos Active
Directory, Central telefónica o PBX, servidores con aplicaciones del negocio y

clientes como por ejemplo Outlook.
A nivel de Exchange tenemos servidores de base de datos y con el rol de acceso

de clientes (estos roles los podemos encontrar en un mismo servidor o en
servidores separados). Delante del Client Access tenemos un balanceador, en este
caso de capa 4 al cual se conectan los clientes.
Los clientes se conectan al nombre asociado al correo y este se resuelve a una IP

virtual configurada en el balanceador, luego en base al algoritmo configurado se
realiza la distribución de las conexiones entre los distintos servidores de Client
Access.
En Exchange 2013 ya no existe un objeto denominado CAS Array por lo que en

este caso hace referencia a la agrupación lógica de múltiples servidores con el rol
de acceso de clientes.
A su vez los servidores de base de datos están dentro de lo que se denomina

DAG lo que proporciona la posibilidad de replicar base de datos con la finalidad
de lograr alta disponibilidad a este nivel.
Teniendo esta imagen en mente y desde un punto de vista práctico podríamos
eliminar el DAG, el CAS Array, dejar ambos roles en un único servidor, no utilizar
15
http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx
un balanceador y conectar los clientes directamente a este equipo. Esto sería
válido si no es requerido que el servicio cuente con alta disponibilidad.
En este caso vemos el rol de Edge Transport en DMZ funcionando como

smarthost y haciendo de antivirus y antispam. En este rol se configuraría la
recepción de correo externo. A su vez en escenarios híbridos podría estar
conectado con Exchange Online Protection.
Por otro lado vemos un firewall donde se publican los servicios web los cuales se
terminan conectando con el balanceador en caso de contar con uno o
directamente con el rol de Client Access.
Arquitectura en Exchange 2016 / 2019
En Exchange 2016 y 2019 se simplifica la arquitectura del producto al punto de

que el único rol que tenemos es el de Mailbox (esto en relación a lo que
instalaríamos en la red interna).
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.
Una instalación típica de Exchange 2016 / 2019 sería equivalente a un servidor

multirol en Exchange 2013 (arquitectura recomendada en esta versión).
En adición se mantiene el rol de Edge Transporte sin grandes cambios.
16
Uno de los cambios importantes que encontramos a nivel de acceso de clientes

es que se soporta que Exchange 2013 haga de proxy hacia Exchange 2016.
Tradicionalmente al instalar una nueva versión de Exchange, uno de los primeros

cambios que debemos realizar es la publicación de servicios. La idea es que las
conexiones pasen por la versión más nueva y esta posteriormente, dependiendo
de donde se encuentre alojado el buzón maneje la conexión de la forma más

apropiada. La versión más nueva sabe “hablar” con la versión anterior pero no a
la inversa.
A partir de Exchange 2016 esto es posible, lo que es importante para cualquier
organización que se encuentre en proceso de actualización desde Exchange 2013

ya que esta es la primer versión en soportar proxy desde una versión anterior del
producto.
16
Esto significa que si instalamos Exchange 2016 en una organización con Exchange
2013, no es necesario hacer cambios a nivel de firewall o registros en DNS ya que

se puede dejar todo apuntando a 2013 y hacer los cambios necesarios en
cualquier punto de la migración.
Rol de Client Access

El rol de Client Access (CAS) en Exchange 2013 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 diagrama17, las conexiones de clientes OWA, ActiveSync,
Outlook (RPC/HTTPS), etc pasan por este rol:
El rol de Client Access de Exchange 2013 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).
17
http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx
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 vemos que también figura como Client
Access.
18
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,
18
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.
En el caso particular de mensajería unificada se realiza una redirección en lugar

de proxy.
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 / 2019), 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 / 2019 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 diagrama19 se puede ver la interacción:
19
https://technet.microsoft.com/en-us/library/aa996349(v=exchg.150).aspx
En lo que respecta a alta disponibilidad y contingencia tenemos como
componente central al DAG20 (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 / 2019 no hay grandes cambios aunque se optimiza en

varios aspectos la replicación y los tiempos asociados a failover y activación de
bases.
Rol de Edge Transport

Este es un rol opcional e incluso puede utilizarse alguna alternativa para cumplir
la función. El rol está diseñado para trabajar en DMZ y manejar lo referente a

ruteo de correo externo e higiene de mensajes.
20
http://aprendiendoexchange.com/dag-en-exchange-introduccion
En este rol se incluyen las mismas características antispam que en el rol de
Mailbox de Exchange así como algunas adicionales como agentes de filtrado de

conexiones y adjuntos. En adición, cuenta con agente de reescritura de
direcciones de correo para el caso que aplique. Este es el único rol de Exchange
que no requiere Active Directory.
El objetivo del rol de Edge Transport es incrementar el nivel de seguridad del

correo, en primera instancia cumpliendo con algo muy requerido como es el
hecho de que un servidor externo no se conecte directamente con uno interno

sino que realice una conexión a nuestra zona perimetral y posteriormente el
servidor de Edge se conecte a nuestros servidores con el rol de Mailbox.
A simple vista podríamos decir que el rol de Edge Transport es un simple

smarthost pero entre otras cosas nos habilita a sincronizar información de
configuración interna como por ejemplo dominios de correo de la organización,
información de destinatarios como remitentes seguros (safe senders) mediante
safelist aggregation y de este modo disminuir la chance de falsos positivos.
Sobre Exchange Híbrido
Una implementación híbrida de Exchange habilita la integración entre una
organización de Exchange On Premises (Exchange local) con Exchange Online
(Office 365).
En este escenario se comienza con 2 entornos completamente desconectados.

Con la configuración apropiada estos pueden trabajar en conjunto casi como si
fueran una misma organización.
De esta forma es posible tener buzones en los 2 ambientes (entre otras cosas),
por ejemplo los buzones de los usuarios que trabajan dentro de las oficinas de la
empresa en los servidores On Premises, mientras que los usuarios remotos con
buzones en la nube.
Beneficios de una implementación híbrida

La configuración híbrida puede ser completa o mínima. El caso de configuración
mínima habilita lo necesario para poder migrar buzones a la nube, pero no
incluye características para coexistencia.
En el caso de la configuración completa, cuentas ubicadas On Premises como en

Exchange Online comparten las siguientes características:
• Ruteo seguro de correo
• Dominio de correo compartido

• Lista global de direcciones unificada
• Información de disponibilidad
• Calendarios compartidos
• Mailtips
• URL única para acceder a OWA
• Redirección automática de Activesync
En adición, incluye la posibilidad de que usuarios on-premises tengan archivado

en la nube (archive mailbox)
Desde el punto de vista administrativo, aparte de una rica coexistencia entre
usuarios on premises y usuarios en la nube habilita a:
• Mover buzones entre Exchange Server y Exchange Online

• Administración centralizada usando el Centro de Administración de
Exchange (on-premises)
• Tracking de mensajes
• Búsquedas multi-mailbox
Componentes principales en una implementación

híbrida de Exchange
Algunos conceptos importantes dentro de una implementación híbrida:
• Servidor Exchange “Híbrido”. Este es un servidor con Exchange 2010 o

superior On Premises. La versión de Exchange recomendada para este
servidor es 2016 o 2019 dependiendo del caso. “Exchange Híbrido” no es
un rol en particular sino que un servidor común que se usa para ofrecer
algunos servicios híbridos como información de autodiscover para
usuarios en la nube, migración de buzones, flujo de correo e información
de disponibilidad (free/busy). La configuración asociada a este servidor es
realizada siguiendo el asistente de configuración híbrida (HCW).

• Exchange Online (Office 365). Exchange Online es uno de los servicios
dentro de Office 365. Este es en base a suscripción y para que un usuario

tenga un buzón en Exchange Online se debe adquirir la licencia
correspondiente. Más información sobre este tema en el siguiente
artículo: Introducción a Office 365
• Federación. Esto habilita por ejemplo a ver información de

disponibilidad entre usuarios on-premises y en Office 365. Dependiendo
de la versión de Exchange cómo se maneja la autenticación. En Exchange
2010 se usa el sistema de autenticación de Azure AD y este funciona

como intermediario entre la organización on-premises y Exchange Online.
En organizaciones con Exchange 2013 o 2016 (sin versiones anteriores) se
usa en cambio OAuth como sistema de autenticación cross premises.

• Azure Active Directory Connect (AAD Connect). Este componente es el
que sincroniza objetos del Active Directory local con el de Azure AD. En
particular en el caso de Exchange, esto habilita una lista global de
direcciones unificada.
En qué tipo de organización es conveniente

configurar Exchange híbrido?
Para un usuario final trabajar en un entorno híbrido es simple, no tiene que saber
nada en particular. Esto no es así para quien administra o implementa la solución.

En este último caso varias cosas tienen que suceder para que todo funcione
correctamente.
Existen varios caminos para llevar el correo a Exchange Online y dependiendo de

los requerimientos de la organización cual sea el más conveniente.
Si por ejemplo se cuenta con pocos buzones y se desea migrar rápidamente en

cuestión de un fin de semana sin requerir pasar por una etapa de coexistencia, la
configuración híbrida probablemente no sea la opción más simple.
Organizaciones con alguno de los siguientes requerimientos deben considerar la
opción híbrida (completa de ahora en más):
• Requerimientos de coexistencia a largo plazo

• Requerimientos de archivado en la nube
• Organizaciones que superan los 2000 buzones a migrar
Ejemplo de organización antes y después de híbrido obtenido de technet21.
21 https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx
Organización típica con Exchange 2010 / 2013 / 2016 antes de configuración
híbrida:
Organización típica luego de configuración híbrida:
En este caso tenemos por un lado Office 365 y por otro la organización on
premises.
En la organización on-premises se agrega AADConnect para manejar la

sincronización con Azure AD.
La organización en este escenario podría tener buzones on-premises y en la nube

e independientemente desde donde se consulte se accede a una lista global de
direcciones unificada.
En caso de clientes Outlook en modo cache estos mantienen el OST una vez
migrado el buzón, es decir que no requiere re sincronizar el cache local de cliente.

En adición se puede compartir información de disponibilidad y se mantiene una
coexistencia rica en general.
Los usuarios acceden a OWA usando la misma URL que usaban antes del cambio
y con la misma cuenta de usuario y contraseña.
Proceso macro de configuración híbrida

A nivel macro, la implementación híbrida de Exchange abarca las siguientes
actividades:
• Actualización de Exchange según la versión (Service Pack, Rollup Update,

Cumulative Update)
• Preparación del directorio para la sincronización

• Ajustes de UPNs y atributos no válidos
• Configuración de AAD Connect

• Sincronización del directorio con Azure AD
• Configuración de certificados
• Configuración de servicios web y registros en DNS
• Ejecución del asistente de configuración híbrida (HCW) en servidor
Exchange On Premises
En este punto la organización se encuentra funcionando en un modo híbrido, a
partir de este momento es posible migrar buzones hacia o desde la nube y

opcionalmente migrar todos los buzones.
Por último, independientemente de que no queden buzones en los servidores

con Exchange On premises, la recomendación de Microsoft es mantener al menos
un servidor con fines administrativos. Si bien este servidor podría ser

desinstalado, esto incrementaría la complejidad a nivel de administración del
servicio.
Sobre Exchange 2019
Exchange 2019 es la versión más reciente del producto y al momento de esta
revisión se encuentra en el Cumulative Update 4.
Esta versión es muy similar a Exchange 2013 o 2016 con algunas mejoras
orientadas a seguridad y rendimiento. En este sentido se destaca la posibilidad de

instalación de Exchange 2019 sobre Server Core, siendo esta la opción
recomendada.
Desde el punto de vista administrativo, pocos cambios se incluyen en esta
versión, siendo la administración general del producto similar al caso de

Exchange 2013 o 2016.
Tenemos las mismas interfaces administrativas:
• Exchange Admin Center (EAC, Centro de Administración de Exchange)

• Exchange Management Shell (EMS)
• Exchange Toolbox (Incluye visor de colas)
Para el administrador de correo que ya maneja Exchange 2013 o 2016 trabajar

con Exchange 2019 resultaría muy similar.
Claro que si se instala el producto sobre Server Core, es decir sin interfaz gráfica
o desktop experience en este caso, hay actividades específicas (iniciales) que
deben ser realizadas por línea de comando o mediante algún utilitario, por
ejemplo en relación a configuración de red o unidades de disco.
Una vez instalado Exchange 2019 (en caso de Server Core), para administrar el
correo usando el Centro de Administración de Exchange (EAC) sería necesario
conectarse desde el navegador de algún otro equipo, como por ejemplo una
estación administrativa, esta podría ser un equipo con Windows 10 y
las herramientas administrativas de Exchange instaladas. Si bien el EAC en

principio es accesible desde cualquier equipo con navegador, para contar con el
Exchange Management Shell y el Exchange Toolbox que incluye el visor de colas
es necesario instalar las herramientas en el equipo.
Exchange Management Shell en Server Core con Exchange 2019
Por fuera de adaptarse a la posibilidad de que el producto corra sobre Server
Core (lo que en muchos casos lleve al uso de una estación administrativa para
herramientas gráficas), todo lo relacionado a la administración de destinatarios
como buzones o configuración general como conectores, bases de datos,
certificados, etc, es “prácticamente” idéntico (o idéntico) a hacerlo con Exchange
2013 / 2016.
Centro de Administración (EAC) de Exchange 2019
Exchange Toolbox y Exchange Management Shell en estación con las herramientas administrativas
de Exchange 2019 instaladas
Desde la perspectiva del usuario la implementación de Exchange 2019 tampoco

implicaría un cambio radical, el foco no es introducir nuevas características (en
este caso Office 365 sería una mejor opción) sino que cuestiones más asociadas a
otros elementos que quizás no sean tan “vistosos” para el usuario final, como por
ejemplo seguridad, escalabilidad y rendimiento.
En el gráfico a continuación obtenido de technet se manejan 3 pilares y en el

relacionado a usuarios se destaca la inclusión de mejoras al manejo de calendario
y soporte para direcciones de correo EAI (Email Address Internationalization) lo
que la realidad es que salvo casos particulares podrían ser características que en
muchos casos pasarían desapercibidas.
https://blogs.technet.microsoft.com/exchange/2018/10/22/exchange-server-2019-now-available/
En cuanto al pilar de seguridad, como se mencionó anteriormente se destaca el
soporte para Windows Server Core. Otra característica interesante es la

posibilidad de restringir el acceso externo al Centro de Administración de
Exchange y al Exchange Management Shell.
A nivel de rendimiento hay varias mejoras, lo que comienza con una actualización
de los requerimientos mínimos a nivel de hardware, donde se especifica 128GB

de RAM como mínimo recomendado para el rol de Mailbox con un máximo
soportado de 256GB y hasta 48 cores.
En cuanto a características destacadas encontramos las siguientes:
• Búsquedas mejoradas (similar a Exchange Online)
• Failovers más rápidos

• Base de Metacache. Esta característica requiere la utilización de discos
SSD y acelera el acceso al correo de forma significativa.

• Cache de base de datos dinámico (optimiza el manejo de memoria en
escenarios en alta disponibilidad).
Consideraciones al planificar la implementación de
Exchange 2019
Como se mencionó en una sección anterior, en Exchange 2019 se mantiene la
misma arquitectura que en Exchange 2016, al punto que hasta el momento el
diagrama de arquitectura del sitio de Microsoft sigue diciendo “Exchange 2016”:
https://docs.microsoft.com/en-us/exchange/architecture/architecture?view=exchserver-2019
Por fuera del diagrama desactualizado, se incluye una nota en relación a
Mensajería unificada en Exchange 2019 y es que esta es una característica

descontinuada. La recomendación de Microsoft en este sentido es hacer la
transición a Skype For Business Cloud Voice Mail.
En definitiva, si al día de hoy se utiliza UM con Exchange es un elemento nada
menor a tener en cuenta.
Otros temas a considerar al evaluar Exchange 2019:
• Disponible únicamente para clientes Volume License (de contar con una
suscripción MSDN es posible también su descarga, por el momento no
hay otra forma de descargar el producto)
• Solo se puede instalar sobre Windows Server 2019 y se recomienda

hacerlo sobre Server Core
• Requiere nivel funcional de bosque y dominio en Windows Server 2012 R2
o superior
• Soporta coexistencia con Exchange 2013 y Exchange 2016 (no con
Exchange 2010)
En relación a estos puntos, por el momento, algo que puede desalentar la

implementación de Exchange 2019, es el hecho de que para acceder al producto
es necesario tener un acuerdo Volume License con Microsoft. Esto puede limitar
la posibilidad de instalación de Exchange 2019 en muchos clientes que por
variedad de motivos quizás no tengan un acuerdo con Microsoft. En el caso de
este tipo de clientes (si nada cambia), las opciones incluyen instalar / mantener
Exchange 2016 (soportado hasta el 2025) o migrar a la nube.
En este sentido, uno podría pensar que el próximo salto para la organización es la
nube y en ese caso no sería necesario tener en cuenta Exchange, pero la realidad
es que al momento no funciona así. Si bien cada vez son más las organizaciones
que hacen la transición a Office 365, en el caso de ambientes empresariales
usualmente el camino implica una implementación híbrida (más adelante se

brinda más detalle en la sección específica). Esto en principio incluye
sincronización de las cuentas del directorio (Active Directory) con Azure. Esta
sincronización entre otras cosas y a un nivel básico habilita a que un usuario
maneje la misma contraseña para acceder a recursos On Premises así como a

recursos en la nube.
En estos entornos híbridos la fuente autoritativa para la mayor parte de los
cambios es el directorio On Premises (Active Directory) por lo que si por ejemplo

deseamos ocultar un usuario de las listas de direcciones o modificar alguna
propiedad de un destinatario, al final esto implicaría modificar algún atributo en
Active Directory que posteriormente debería ser sincronizado con Azure. En este
escenario si hubiera que realizar algún cambio en un buzón incluso ya migrado,
sería necesario hacer la modificación con las herramientas On Premises para que
luego de la sincronización el cambio se vea reflejado en la nube.
Para hacer cambios en destinatarios de correo en ambientes híbridos, la opción
soportada por Microsoft es mediante Exchange On Premises. Por este motivo

incluso luego de haber migrado todos los usuarios a Office 365 es necesario
mantener un servidor con Exchange. Por lo que si pensamos en el corto y
mediano plazo, las organizaciones que mantengan este esquema híbrido deben
mantener al menos un servidor con Exchange On Premises con una versión
soportada del producto, esto implica que la mayor parte de estos clientes deban
instalar en algún punto ya sea Exchange 2016 o Exchange 2019 (mientras
Microsoft no libere algún otro tipo de alternativa).
Próximos pasos
Este ebook introductorio es 100% teórico y está basado en parte en la primer
lección del curso exclusivo de Administrador de Exchange del sitio. El acceso a
completo a este curso requiere membresía al sitio, tenés más info en la página
principal:
• Membresía al sitio
Para estar al tanto de novedades, cursos exclusivos y talleres en vivo podés

sumarte también a la página del sitio en Facebook:
• AprendiendoExchange.com en Facebook
Para quedar en contacto conmigo podés agregarme en linkedin:
• Daniel Núñez Banega en Linkedin
Por último, por feedback sobre el ebook o el sitio en general podés escribir a
admin@aprendiendoexchange.com.

Fundamentos ExchangeServer V3 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fundamentos ExchangeServer V3 2

Cargado por

Copyright:

Formatos disponibles

© 2 0 2 0 T o d o s l o s d e r e c h o s r e s e r v a d o s - A p r e n d i e n d o E x c h a n g e .

cuentan con una instalación local, el producto de correo electrónico por

Comprender cómo funciona, dónde almacena la información y cuáles son sus

dependencias es crítico para implementar o administrar la plataforma

Dada la similitud entre Exchange 2013, 2016 y 2019, lo mencionado en este

un Service Pack en Exchange 2010) y el caso de Exchange 2019 a 15.02.xxx.xxx.

Por fuera de lo anecdótico, a partir de Exchange 2013 incluyendo Exchange 2016

incluyen todo el producto y las actualizaciones, esto significa que al descargar el

En este ebook "Fundamentos de Exchange server" (edición enero 2020) vemos

En ambos casos el medio de instalación es el mismo, la diferencia se encuentra en

De forma predeterminada se comporta como si fuera Standard.

El utilizar la versión Standard o Enterprise de Exchange depende de la cantidad

• Exchange 2013 / 2016 / 2019 Standard – máximo 5 bases montadas

Nota: La base especial de recuperación (Recovery Database) no se toma en

Adicionalmente en el caso de Standard las bases están limitadas a un máximo de

punto de vista de características, clientes o alta disponibilidad ambas cuentan con

• Exchange Server Standard CAL

• Exchange Server Enterprise CAL

La Enterprise CAL (eCAL) habilita mayor funcionalidad como por ejemplo

esto se presta muchas veces a la confusión, es decir que se puede utilizar

(en adición a la Standard) porque requieren cierta funcionalidad que otros

sobre las siguientes versiones de sistema operativo:

• Windows Server 2008 R2 SP1 (Standard o Enterprise y no soportado a

partir del 14/01/2020)

• Windows Server 2012 R2 (Standard o Datacenter)

En el caso de Exchange 2016 (CU15 al momento):

• Windows Server 2012 (Standard o Datacenter)

• Windows Server 2012 R2 (Standard o Datacenter)

En el caso de Exchange 2019 (CU4 al momento):

• Windows Server 2019 (Standard o Datacenter)

En el caso de Windows Server 2008 R2 SP1 sería necesario la versión Enterprise ya

Independientemente de la versión de sistema operativo en el caso de Exchange

versión de Exchange soportada (y recomendada) sobre Windows Server Core.

Mejoras en Exchange 2013 /

Nueva interfaz administrativa

Desaparece la Exchange Management Console (EMC) utilizada en Exchange 2007

/ 2010 y se introduce el Exchange Admin Center (EAC).

La nueva interfaz de administración es web y aunque en primera instancia esto

cualquier lado a diferencia de la EMC que requería instalar las herramientas

OWA es rediseñado y optimizado para tablets y smartphones en adición a

Dentro de las nuevas características una muy importante es la posibilidad de

Si bien existen limitantes, las características principales como lectura, edición,

En adición a los cambios incluidos en Exchange 2013, en el caso de Exchange

Entre las principales mejoras en Outlook on the Web encontramos:

• Opciones de OWA (opciones no incluidas en versiones anteriores)

En adición, características de embebido de videos y URLs en el cuerpo del

Desaparece la base pública de versiones anteriores y se introduce el buzón de

replicada dentro de un DAG.

En el caso particular de Exchange 2016 y 2019 se integran las características de

En adición se agregan comandos específicos orientados al cumplimiento de

Con Managed Availability se incluye monitoreo de los componentes internos y

un servicio, application pool, servidor completo o escalar a un administrador:

Mediante el uso de DLP es posible reducir el riesgo de exposición de datos

En Exchange 2016 y 2019 se incluyen nuevas condiciones, acciones y más de 80

• Credit Card Number

• U.S. Bank Account Number

En adición se pueden adquirir plantillas de terceros o generar personalizadas.

Distintos patrones pueden ser identificados independientemente de si se

encuentran en el cuerpo del mensaje o dentro de algún adjunto:

MAPI sobre HTTP

En Outlook Anywhere se da una doble encapsulación; MAPI dentro de RPC y este

En Exchange 2016 y 2019 es el protocolo predeterminado aunque en estado de

coexistencia con Exchange 2013, dependiendo de la configuración podría no