Fundamentos ExchangeServer V3 1 PDF

© 2 0 1 7 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
Contenido
Introducción ......................................................................................................................... 3
Ediciones de Exchange ........................................................................................................ 4
Licencia de clientes (CAL) .................................................................................................... 5
Sistemas operativos soportados ....................................................................................... 7
Mejoras en Exchange 2013 / 2016 .................................................................................... 8
Coexistencia........................................................................................................................ 21
Requerimientos de Hardware.......................................................................................... 21
Requerimientos de Software ........................................................................................... 23
Active Directory .................................................................................................................. 24
Dominio ..................................................................................................................... 25
Árbol de dominios ................................................................................................... 25
Bosque de Active Directory .................................................................................... 25
Particiones del directorio ........................................................................................ 26
Catálogo Global ........................................................................................................ 28
Replicación ................................................................................................................ 30
Roles maestros (FSMO) ........................................................................................... 31
Sitios de Active Directory ........................................................................................ 32
DNS ...................................................................................................................................... 34
Registros DNS ........................................................................................................... 35
Requerimientos de servicios de infraestructura ........................................................... 39
Nivel funcional .......................................................................................................... 39
Preparación de Active Directory ............................................................................ 40
Instalar Exchange en un controlador de dominio? ....................................................... 42
Arquitectura de roles ........................................................................................................ 43
Rol de Client Access ................................................................................................. 47
Rol de Mailbox .......................................................................................................... 49
Rol de Edge Transport ............................................................................................. 50
Sobre Exchange Híbrido ................................................................................................... 52
Beneficios de una implementación híbrida ......................................................... 52
© 2 0 1 7 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
Componentes principales en una implementación híbrida de Exchange ...... 53
En qué tipo de organización es conveniente configurar Exchange híbrido? .. 54
Proceso macro de configuración híbrida ............................................................. 57
Próximos pasos .................................................................................................................. 58
Introducción
Empresas de mediano y gran porte utilizan 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 y Exchange 2016, lo mencionado en
este documento aplica a ambas versiones salvo los casos en donde se
especifique algo diferente.
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).
Por fuera de lo anecdótico, a partir de Exchange 2013 incluyendo Exchange
2016, las actualizaciones vienen en forma de CU (Cumulative Update) y ya no
contamos con Service Packs (SP) o Rollup Updates (RU).
En este ebook "Fundamentos de Exchange server" (edición noviembre 2017)
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 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 Standard – máximo 5 bases
• Exchange 2013 / 2016 Enterprise – máximo 100 bases
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 (CU18 al momento de esta revisión) corre
sobre las siguientes versiones de sistema operativo:
• Windows Server 2008 R2 SP1
• Windows Server 2012
• Windows Server 2012 R2
En el caso de Exchange 2016 (CU7 al momento):
• Windows Server 2012 R2
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.
Independientemente de la versión de sistema operativo no es posible
instalar sobre Server Core, la instalación debe ser completa (con GUI).
Mejoras en Exchange 2013 /
2016
Exchange 2013 / 2016 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 desde
Exchange 2007 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)
En adición a los cambios incluidos en Exchange 2013, en el caso de Exchange
2016 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 1 7 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
Mayor integración con Sharepoint con buzones
de sitio
En Exchange 2013 se introduce un nuevo tipo de buzón “site mailbox”. El site
mailbox habilita a que se almacene la información de correo electrónico en la
base de datos de Exchange mientras que toda la parte de documentos en
Sharepoint. Esto permite aprovechar características de versionado entre
otras cosas.
Los usuarios fácilmente pueden arrastrar documentos desde Outlook 2013 /
2016:
4
http://blogs.technet.com/b/exchange/archive/2012/08/22/site-mailboxes-in-the-new-office.aspx
Del mismo modo es posible acceder a correos relacionados a un proyecto en
contexto, desde Outlook o Sharepoint. Si bien desde el punto de vista de
interfaz de usuario el contenido está en un mismo lugar, mediante site
mailboxes es posible almacenar cada tipo de elemento en el store más
optimizado para la tarea.
En el caso específico de Exchange 2016 con Sharepoint 2016 se permite
adjuntar y compartir documentos almacenados en OneDrive for business de
5
https://blogs.office.com/2013/10/28/office-365-compliance-controls-data-loss-prevention/
manera similar a como se da en Office 365. En complemento es posible la
instalación de Office Online Server para mejorar la experiencia a nivel de
manejo de documentos desde OWA.
A pesar de lo mencionado, esta característica va camino a ser descontinuada
por lo que más allá de saber que la opción existe no recomendaría invertir
tiempo en esto. Esto es así al punto que en Office 365 ya no se permite la
creación de nuevos buzones de sitio.
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).
6
En el caso particular de Exchange 2016 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”.
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:
6
http://blogs.technet.com/b/exchange/archive/2014/08/26/public-folder-updates-in-cu6-improving-scale-and-more.aspx
7
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).
7
https://technet.microsoft.com/en-us/library/dn482056(v=exchg.150).aspx
8
En Exchange 2016 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:
8
9
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 la idea de reemplazar a futuro 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.
9
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.
En el siguiente diagrama se puede ver gráficamente este cambio:
10
En Exchange 2016 es el protocolo predeterminado aunque en estado de
coexistencia con Exchange 2013, dependiendo de la configuración podría no
estar habilitado.
10
https://blogs.technet.microsoft.com/exchange/2014/05/09/outlook-connectivity-with-mapi-over-http/
Tabla comparativa de características
A continuación una tabla comparativa entre las características de Exchange
2007, 2010 y 2013 (también aplica a 2016 aunque no incluye todo):
11
11
https://products.office.com/es-es/exchange/compare-microsoft-exchange-server-versions
Coexistencia
A nivel de coexistencia con versiones anteriores dentro de un mismo bosque
va a depender de si estamos actualizando a Exchange 2013 o 2016.
En el caso de Exchange 2013 podríamos actualizar desde Exchange 2007 o
2010 con las últimas actualizaciones.
En caso de utilizar Exchange 2003, la alternativa sería una migración entre
bosques, 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
posteriormente hacia 2013.
De cualquier modo tampoco es posible migrar desde Exchange 2003
directamente sin utilizar aplicaciones de terceros o incluir al menos un
Exchange 2010 como destino (aunque sea de forma temporal).
En el caso de Exchange 2016 es posible coexistir con Exchange 2010 o 2013
dentro de un mismo bosque teniendo en cuenta de tener las últimas
actualizaciones.
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 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.
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 excel12 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.
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 y
Windows 10.
Adicionalmente, tanto en Exchange 2013 como 2016 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.
12
http://aprendiendoexchange.com/dimensionamiento-calculadora-requerimientos-exchange
Por último, en relación al Windows Management Framework, únicamente se
soporta la versión incluida en el Sistema operativo.
Active Directory
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:
13
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.
13
https://technet.microsoft.com/en-us/library/cc756901(v=ws.10).aspx
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
• 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:
14
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í.
14
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:
15
15
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.
16
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.
16
https://technet.microsoft.com/en-us/library/ff634392(v=exchg.141).aspx
Este tipo de registro es muy utilizado para evitar el spoofing de mails, por
ejemplo cuando se recibe spam desde direcciones supuestamente internas.
17
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).
17
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.
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:
18
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.
18
http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx
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 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
En Exchange 2016 se continúa simplificando la arquitectura del producto al
punto de que 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.
Una instalación típica de Exchange 2016 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.
19
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.
19
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 diagrama20, 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).
20
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.
21
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
21
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.
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), 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 diagrama22 se puede ver la interacción:
22
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 DAG23 (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.
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.
23
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. “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 technet24.
Organización típica con Exchange 2010 / 2013 / 2016 antes de
configuración híbrida:
24 https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx
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.
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.
En adición forma parte del Día 1 del entrenamiento gratuito “Exchange
Intensivo en 10 Días”. En este sentido ya adelantaste bastante con la parte
teórica, si querés avanzar podés registrarte en la siguiente página:
• Exchange Intensivo en 10 Días
Para estar al tanto de novedades e inicio de cursos exclusivos 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 1 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Fundamentos ExchangeServer V3 1 PDF

Загружено:

Авторское право:

Доступные форматы

© 2 0 1 7 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

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

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

este documento aplica a ambas versiones salvo los casos en donde se

especifique algo diferente.

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

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

2016, las actualizaciones vienen en forma de CU (Cumulative Update) y ya no

contamos con Service Packs (SP) o Rollup Updates (RU).

En este ebook "Fundamentos de Exchange server" (edición noviembre 2017)

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

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

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

• Exchange 2013 / 2016 Enterprise – máximo 100 bases

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.

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

En la siguiente tabla 1se pueden ver las características incluidas dentro de la

CAL Standard y que es lo agrega la Enterprise:

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

solo cuenten con la Standard.

sobre las siguientes versiones de sistema operativo:

• Windows Server 2008 R2 SP1

• Windows Server 2012

• Windows Server 2012 R2

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

• Windows Server 2012

• Windows Server 2012 R2

• Windows Server 2016

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