Unidad 1: Diseño de un sistema de mensajería de Exchange Server 2003

Introducción
1.Consideraciones sobre el diseño de Exchange 2003
2.Diseño de la ruta de implementación
3.Diseño de la infraestructura de Exchange

Unidad 1: Diseño de un sistema de mensajería de Exchange Server 2003

Introducción

Cada vez son más los negocios que reconocen la enorme importancia de los
sistemas de mensajería. Por esto, las distintas compañías fijan estrictos requisitos
de disponibilidad y confiabilidad para los sistemas de correo electrónico. Igualmente importante es
la fuerte demanda de nuevas características en los sistemas de mensajería; y es que la cada vez
más obligada movilidad en el trabajo y la dispersión geográfica de los negocios indican que los
requisitos del usuario están en constante evolución. Todos estos factores suponen una demanda
tanto para los administradores de tecnologías de la información como para los arquitectos de
sistemas, que se ven obligados a diseñar sistemas de mensajería de gran confiabilidad y
disponibilidad constante para cubrir las necesidades de los usuarios.
Para diseñar un sistema de mensajería de Microsoft® Exchange Server 2003 apropiado, es preciso
conocer las capacidades y las limitaciones del software y del hardware en los que este sistema se
va a integrar. Ya sea para desarrollar un sistema de mensajería de Exchange Server 2003 nuevo o
para actualizar la implementación de uno ya existente, será necesario sopesar las limitaciones de
la infraestructura de la red y la capacidad del sistema de mensajería, del sistema operativo y del
software de usuario.
Este curso le ayudará a afrontar estos retos y servirá como guía en los procesos de evaluación del
entorno existente y de reconocimiento de las consideraciones técnicas que inciden en la elección
del diseño. Del mismo modo, en él encontrará consejos acerca del diseño de un sistema de
mensajería de Exchange 2003, además de información detallada sobre las mejoras en
Exchange 2003, Microsoft Windows Server™ 2003 y Microsoft Office Outlook® 2003. También
identifica la infraestructura de la red, el hardware, el servicio de directorio
Microsoft Active Directory® y otros asuntos de carácter administrativo. Por último, en este módulo
se tratan las consideraciones que ayudan a diseñar un sistema de mensajería enormemente
confiable y en constante disponibilidad, sin olvidar las tecnologías de almacenamiento, la
organización por clusteres, el ajuste del servidor y la configuración de los equipos cliente.

Este curso en general le ayudará a adquirir los conocimientos básicos para Administrar,
Implementar y Migrar una infraestructura de correo electrónico basada en Microsoft Exchange
Server 2003.
 1. Consideraciones sobre el diseño de Exchange 2003

Antes de comenzar con el diseño de un sistema de mensajería de Microsoft® Exchange

Server 2003, es imperativo recabar una gran cantidad de información comercial y técnica. Muchas
compañías poseen sus propios métodos de desarrollo de sistemas en los que se basan a la hora de
diseñar o actualizar sistemas. Por lo general, el primer paso de estos métodos consiste en reunir
requisitos y evaluar el entorno actual. Así, aún cuando su compañía no siga una metodología
formal, la mejor forma de empezar con la fase de diseño es dando este primer paso.
El proceso habitual en el diseño del sistema de mensajería de Exchange Server 2003
es el que sigue:
En primer lugar, se evalúan los requisitos de negocio, administrativos, de usuario
y de seguridad y se realiza una valoración técnica del entorno en el que está previsto
implementar el sistema.
En segundo lugar, se evalúan las soluciones de carácter técnico y se establece
el diseño del sistema de mensajería de Exchange de destino.
Por último, se lleva a cabo un análisis de vacío para determinar los elementos necesarios
para pasar del entorno existente al diseño de destino.
En el inicio de este capítulo se da por hecho que ya se han reunido todos los requisitos de negocio,
administrativos, de usuario y de seguridad relativos al sistema de mensajería. Tras esto, se pasa a
evaluarlos destacando algunos de los aspectos en cada una de las categorías y describiendo la
importancia de estos requisitos en el diseño del sistema de mensajería. Asimismo, este capítulo sirve de
orientación a la hora de realizar una valoración técnica del entorno actual. El capítulo finaliza con una
visión general de las características específicas
de Microsoft Windows Server™ 2003, Exchange 2003 y Microsoft Office Outlook® 2003 que inciden en las
decisiones de diseño que vayan a tomarse.

Evaluación de los requisitos

Los requisitos de negocio, administrativos, de usuario y de seguridad influyen de forma directa en
el diseño del sistema de mensajería de Exchange. Dado que las compañías hacen uso de diferentes
metodologías para reunir y documentar requisitos exclusivos
a la situación de cada una de ellas, esta sección no incluye un listado pormenorizado
de todos los requisitos posibles, sino que se centra en los tipos de requisitos de manera global y en
los aspectos relacionados con ellos que pueden incidir en el diseño.

Requisitos de negocio
Entre los requisitos de negocio que han de identificarse antes de comenzar el diseño
del sistema de mensajería de Exchange se incluyen:
Acuerdos de nivel de servicio (SLA)
Limitaciones económicas para el hardware y la red
Limitaciones económicas para el software
Los requisitos de negocio (más concretamente, las limitaciones de carácter económico) determinan
hasta dónde se debe trabajar dentro de la infraestructura existente o si la actualización del
hardware, del software y de la infraestructura de la red es viable.

Acuerdos de nivel de servicio

Los requisitos del Acuerdo de nivel de servicio (SLA) determinan el modo en que elementos como
el almacenamiento, la organización por clusteres, y la copia de seguridad y la recuperación
influyen en el sistema. A la hora de evaluar los SLA, determine las expectativas de su empresa con
respecto a la disponibilidad y la capacidad de recuperación, incluyendo el tiempo de entrega de los
mensajes, el porcentaje de tiempo de actividad del servidor, la cantidad de almacenamiento
por usuario y el tiempo necesario para recuperar una base de datos de Exchange. Identifique las
horas de funcionamiento regular y las expectativas sobre el tiempo
de inactividad previsto. Identifique asimismo el costo estimado de la compañía en concepto de
tiempo de inactividad no previsto para que, de este modo, sea posible diseñar la cantidad
adecuada de tolerancia a errores en el sistema de mensajería.
Existen nuevas características en Exchange 2003 y Windows Server 2003 que pueden afectar el
modo de diseñar el sistema para que se adecue a los requisitos de acuerdos de nivel de servicio.
En concreto, es posible que el nuevo servicio de instantáneas de volumen obligue a un
replanteamiento de los límites anteriormente impuestos por estos requisitos. Antes, posiblemente
tuviera que restringir el número de usuarios alojados en un buzón para respetar las limitaciones
SLA de tiempo de funcionamiento, ya que la realización de copias de seguridad precisa una gran
inversión de tiempo. Sin embargo, con el servicio de instantáneas de volumen, las copias de
seguridad se crean a partir de una instantánea, con lo cual la base de datos que las aplicaciones
utilizan no se ve afectada. El servicio Volume Shadow Copy le permite hacer copia de seguridad de
los datos de Exchange (o de cualquier aplicación) rápidamente y con un impacto mínimo sobre los
clientes de correo electrónico. Esto le ayuda a tener bases de datos mayores y más usuarios por
servidor. Si se utiliza junto con software y hardware que admita el servicio volume Shadow Copy
de Windows Server 2003, podrá crear copias de seguridad o restaurar rápidamente bases de datos
de Exchange de cualquier tamaño, desde 100 GB a varios terabytes. También podrá configurar
clusteres en distintas ubicaciones físicas. Todas estas características ofrecen mejores niveles de
servicio de lo que nunca había sido posible anteriormente.

Limitaciones económicas para el hardware y la red

Las limitaciones económicas en torno a la actualización de la red o el hardware existentes influyen de
forma directa en el diseño del sistema de mensajería de Exchange. Así, según sea la integridad de la
red, es posible que necesite realizar algunas actualizaciones para poder cumplir los requisitos de
negocio y de usuario. En algunos casos en los que las probabilidades de actualización son limitadas,
puede que no disfrute de algunas de las características de mensajería en Exchange, como RPC a través
de HTTP. Esta función puede mejorar la experiencia de mensajería en conexiones de red poco
confiables y de baja velocidad.
Si parte de su estrategia empresarial consiste en reducir el costo global de la propiedad mediante la
consolidación o centralización del hardware del servidor, algunas de las características de
Exchange 2003, Windows Server 2003 y Outlook 2003 pueden ser de gran utilidad. Así,
Exchange 2003 está menos expuesto a la fragmentación de memoria,
lo que significa que los servidores de Exchange 2003 con procesadores rápidos pueden administrar a
más usuarios por servidor antes de que se llegue al límite de fragmentación de memoria. Esto ocurre
igualmente con Windows Server 2003, que realiza una mejor administración con el propósito de que se
pueda alojar a más usuarios en un servidor antes de encontrarse con algún elemento relacionado con
la fragmentación de memoria. Una mejor administración de la memoria no tiene por qué traducirse en
un rendimiento y escalabilidad de la CPU significativamente mejores, pero sí le permitirá alojar un
número de usuarios mayor en el servidor.
Para obtener más información acerca de las nuevas características, consulte "Conocimiento de las
versiones de Exchange, Windows y Outlook" más adelante en este capítulo.

Limitaciones económicas para el software

Tal y como sucede con la actualización del hardware y la red, las limitaciones económicas en torno a la
actualización de sistemas operativos, aplicaciones del servidor y aplicaciones de equipos cliente influyen
de forma directa en el diseño del sistema de mensajería de Exchange. Por ejemplo, si puede actualizar
los equipos cliente con Outlook 2003, la función de modo de intercambio en caché será de gran ayuda
en conexiones de ancho de banda de bajas o lentas.

Requisitos administrativos
Los requisitos administrativos de una compañía tienen un impacto notable en el diseño de
sistemas, especialmente en el caso de evolucionar a un modelo más centralizado para reducir los
costos administrativos.
En general, las empresas ponen en práctica modelos de carácter administrativo basados en dos
categorías:
 Administración centralizada: un único grupo mantiene el control total del
sistema de Exchange. En este modelo se implementa un número reducido de grupos
administrativos, dependiendo de si se tiene un solo centro de datos o una gran cantidad de
sucursales. Un solo grupo de tecnologías de la información es responsable de las tareas
administrativas. Este modelo es habitual en compañías pequeñas o medianas, pero también puede
utilizarse en compañías más grandes que tengan un ancho de banda alto para conectar con todas
las oficinas regionales.
Administración distribuida: el control completo sobre la administración del sistema de
Exchange se distribuye a las regiones o divisiones de la organización.
La compañía crea al menos un grupo administrativo por cada región o división.
Cada grupo administrativo contiene grupos de enrutamiento, directivas, servidores, jerarquías
de directorio de carpetas públicas y otros objetos particulares de cada división. Un grupo
central de tecnologías de información puede ser responsable de administrar normas y pautas,
pero no de la administración diaria del sistema. Generalmente, cada región o división controla
sus propiedades y desarrolla su propio sistema de administración.

Nota: en Exchange 5.5, un sitio establece los límites administrativos y de enrutamiento.

En Exchange 2000, el sitio se divide en grupos de enrutamiento y grupos administrativos
para conseguir una flexibilidad mayor. En Exchange 2000 y Exchange 2003, un grupo de
enrutamiento hace referencia a un conjunto de servidores confiables a tiempo completo en
el que los mensajes pasan directamente de servidor a servidor. Por grupo administrativo
se entiende el conjunto de usuarios con autoridad administrativa que no está restringido a
los límites del grupo de enrutamiento.

Requisitos de usuario
Entre los requisitos de usuario que influyen en el modo de diseñar el sistema de mensajería de
Exchange se incluyen:
Acceso remoto: en compañías que cuentan con oficinas dispersas geográficamente y con
conexiones de red de ancho de banda bajas y de velocidad lenta, es muy probable que los usuarios
requieran una mejor experiencia sin conexión. La valoración de este requisito junto con los
requisitos de negocio y las limitaciones económicas ayuda a determinar si se puede disfrutar de
características como el modo de intercambio en caché de Outlook 2003 y, así, conseguir una mejor
experiencia sin conexión.
Acceso a Web: es posible que los usuarios precisen saber el modo de tener acceso
a la información de Exchange desde Internet. A tal efecto, se han efectuado algunos cambios en
las áreas de interfaz y rendimiento de Microsoft Office Outlook Web Access 2003 para mejorar la
experiencia de usuarios de oficinas remotas. No obstante, es posible que sea necesario realizar una
serie de inversiones para actualizar el sistema operativo; así, las ganancias de rendimiento
derivadas de la nueva tecnología de compresión se basan en Windows Server 2003 como el
sistema operativo.
Acceso móvil: es posible que lo usuarios precisen saber cómo tener acceso a la
información de Exchange desde dispositivos móviles, por ejemplo un dispositivo Microsoft
Pocket PC 2002 Phone Edition.

Conocimiento del entorno actual

Antes de diseñar el sistema de mensajería de Exchange, es importante que conozca los aspectos
físicos y lógicos del entorno actual. Desde un punto de vista físico, el diseño depende del tipo y de
la integridad de la infraestructura de la red, ya que estos dos factores afectan a la implementación
de Exchange, a la colocación de los servidores y a la experiencia de usuario prevista. Desde un
punto de vista lógico, Exchange 2003 depende del servicio de directorios de Active Directory para
sus servicios, de manera que la estructura de Active Directory que tenga ha de ser sólida. De
hecho, es más que recomendable que diseñe la estructura de Active Directory con vistas a
Exchange.
 Importante: antes de implementar Exchange 2003, deberá contar con una infraestructura de
Active Directory. Al diseñar Active Directory, se aconseja conocer el modo en que Exchange
influye en el diseño.

Infraestructura de la red
Una de las primeras cosas que debe hacer es construirse una imagen global de la red
física existente para, de este modo, poder determinar hasta qué punto la infraestructura existente
admite Exchange. Durante este proceso podrá reconocer la necesidad de actualizar la red de área local
o de área extensa existentes. Comience con una sencilla representación de toda la red que le permita
identificar las ubicaciones de las oficinas
y las conexiones establecidas entre ellas y, a continuación, agregue más detalles (figura 1.1).

Figura 1.1 Comience con una sencilla representación de la infraestructura

de la red

Para obtener una imagen detallada de la configuración de las redes de área local y de área
extensa, haga un diagrama de todas las ubicaciones de sitios, tipos de conexión y topologías de
red (como bus, token ring o en estrella). Incluya las ubicaciones de los servidores de seguridad y
de las redes perimetrales. La evaluación también debería incluir un inventario exhaustivo del
hardware que actualmente compone la infraestructura de la red, incluidos los servidores, routers y
conmutadores tanto independientes como agrupados por clusteres. Anote asimismo toda la
logística del centro de datos, incluidos el espacio entre armarios, el cableado y los sistemas de
alimentación.
En general, la infraestructura de la red debería analizarse desde las siguientes perspectivas:
Consideraciones geográficas
Ancho de banda y latencia
Uso actual
Sistema de mensajería actual

Sistema de mensajería actual

Durante el diseño, debería plantear las siguientes preguntas sobre su sistema
de mensajería actual:
• ¿Qué impacto tiene el sistema actual en la red?
• Actualmente, ¿tiene una versión anterior de Exchange en ejecución? De ser así, ¿está
ejecutando Exchange 5.5, Exchange 2000, o ambas versiones en modo combinado?
Durante el diseño, debe determinar el impacto del sistema de mensajería actual en la red. Para
simular el uso del sistema de mensajería actual, haga uso de herramientas
de simulación de carga como Microsoft Exchange Server Load Simulation Tool (LoadSim.exe) y la
herramienta Exchange Stress and Performance (ESP). LoadSim imita el efecto de un uso elevado
de clientes MAPI de Outlook y ayuda a personalizar los perfiles de Outlook que desee utilizar
durante la comprobación. En cuanto a ESP, simula el efecto de un uso elevado de clientes no MAPI
como el Protocolo de oficina
de correos (POP), el Protocolo de acceso a mensajes de Internet (IMAP), el Protocolo simple de
transferencia de correo (SMTP) y Outlook Web Access 2003. También puede usar ESP para simular
la carga en una arquitectura que incorpora servidores para el usuario.
El método que se utiliza en la actualización de un sistema de mensajería existente
de Exchange a uno de Exchange 2003 depende de si la versión en ejecución es Exchange 5.5 o
Exchange 2000. Si actualmente ejecuta Exchange 5.5 en Windows NT® Server versión 4.0, deberá
pensar en mover las cuentas de usuario a Active Directory y en sincronizar la información de
directorios, ya que Exchange 5.5 posee un servicio de directorios propio, mientras que
Exchange 2003 se basa en Active Directory para tener este servicio. En el diseño de proyecto,
necesitará incorporar un método para la sincronización de ambos directorios, además de prever un
período de convivencia hasta que pueda migrar completamente a Exchange 2003 y Active Directory.
En caso de estar ejecutando Exchange 2000 o un entorno combinado con Exchange 5.5 y
Exchange 2000, la actualización a Exchange 2003 es directa siempre que Active Directory ya se haya
actualizado con la información de directorios actual. Es por este motivo por el que ha de examinar
detenidamente el estado de la información de directorios. Para obtener más información acerca del
modo de diseñar la ruta de implementación de Exchange 5.5 a Exchange 2003, consulte el capítulo 3,
"Diseño de la ruta de implementación".
Si actualmente ejecuta Exchange 5.5, otro factor que hay que tener presente es el uso de
Exchange 2003 con la función de modo de intercambio en caché de Outlook 2003, a fin de
alojar un mayor número de usuarios por servidor y, en consecuencia, reducir el número de
servidores de Exchange.

Conocimiento de las versiones de Exchange, Windows y Outlook

Tras haber evaluado los requisitos de negocio y haberse documentado sobre el entorno existente,
ponga en práctica los conocimientos adquiridos sobre las capacidades del software de mensajería y
de sistema operativo para elegir el diseño más conveniente según las necesidades de la compañía.
Uno de los mayores retos en el diseño de un sistema de mensajería de Exchange consiste en sopesar
los requisitos de negocio y de usuario y las capacidades del sistema actual.
Para cumplir con algunos de los requisitos de usuario, es posible que tenga que recomendar
actualizaciones para la red troncal, el hardware del servidor o el software del sistema operativo. En las
siguientes secciones se explica brevemente las características de las versiones más recientes de
Exchange, de Windows Server y de Outlook que influyen en la toma de decisión del diseño. Además, le
ayudarán a saber si hacen falta actualizaciones de carácter técnico.

Comparación de las versiones de Windows Server

En muchos casos, la combinación de Exchange Server 2003, Windows Server 2003 y Outlook 2003
supone un apoyo para que las compañías fusionen sus sitios y reduzcan el número de servidores
en ubicaciones remotas.

Windows Server 2003

Los cambios y características en Windows Server 2003 descriptos a continuación pueden afectar el
diseño de Active Directory y de Exchange:
• Aumento del número de sitios por Forest: gracias a las mejoras de Windows Server 2003
en el comprobador de coherencia de la información (KCC)
y en el generador de topología entre sitios (ISTG), los bosques pueden incluir un mayor
número de sitios que con Microsoft Windows 2000 Server. Así, mientras en
Windows 2000 Server el límite eran 300 sitios por dominio, en Windows Server 2003 un
dominio puede contener 3000 o más. Estas mejoras
de escalabilidad pueden tener repercusión en la estructura del bosque.
• Servicio Volume Shadow Copy: Windows Server 2003 contiene capacidades
del servicio Volume Shadow Copy que le permiten realizar rápidamente copias
de seguridad en línea de volúmenes de datos de aplicaciones, con un impacto mínimo sobre los
clientes de correo electrónico. Este servicio funciona con aplicaciones, sistemas operativos,
programas de copia de seguridad y hardware de almacenamiento para crear una instantánea
coherente de los datos. Gracias a esta función se pueden recuperar copias de seguridad y extraer
datos de manera confiable y sin repercusión perceptible en el rendimiento.
• Admisión de redes de área de almacenamiento: Windows Server 2003 se ha mejorado
para que admita redes de área de almacenamiento; entre estas mejoras se incluyen la
conexión a volúmenes, la administración de redes de área de almacenamiento de canales de
fibra y la posibilidad de iniciar directamente desde una red de área de almacenamiento.
• Inicio de sesión sin necesidad de un servidor de catálogo global local: en
Windows Server 2003 los usuarios pueden conectarse sin que sea necesario un servidor de
catálogo global local para ello. Esta función almacena credenciales de usuario y reduce de
forma significativa las solicitudes al servidor de catálogo global. No obstante, la posibilidad de
iniciar sesión sin un servidor de este tipo está pensada para sitios de Windows que no
contienen usuarios de Exchange.
Importante: en los sitios de Windows que sí contienen usuarios de Exchange, es
aconsejable instalar un servidor de catálogo global local.

Windows 2000 Server

Si continúa usando Windows 2000 Server como sistema operativo, o bien si actualiza algunos servidores
a Windows Server 2003, no podrá disponer de algunas de las características de Windows Server 2003
hasta que actualice a un bosque de Windows Server 2003 puro.
La función RPC a través de HTTP de Outlook en concreto requiere que tanto el servidor de
Exchange como un servidor de catálogo global ejecuten Windows Server 2003 y que el esquema
de Active Directory se actualice a este mismo sistema.
En cambio, otras características de Exchange 2003, como el servicio Volume Shadow Copy, están
disponibles al ejecutar Exchange 2003 en Windows Server 2003, pero no es necesario actualizar el
esquema de Active Directory a Windows Server 2003.

Mejoras en Exchange 2003

Exchange 2003 ofrece una funcionalidad más precisa en las siguientes áreas:
Enrutamiento
Compatibilidad con el servicio de instantáneas de volumen
Compatibilidad con el modo de intercambio en caché de Outlook 2003
Outlook Web Access para Exchange 2003
Compatibilidad de dispositivos móviles para Exchange 2003
Outlook 2003
Algunas de las mejoras de estas áreas dependen de si se está ejecutando Windows Server 2003 o
Outlook 2003. En las siguientes secciones se explican
tanto estas mejoras como las dependencias correspondientes.

Mejoras de enrutamiento
En Exchange 2000, las mejoras en el enrutamiento con respecto a Exchange 5.5 han servido para
dejar de usar arquitecturas de enrutamiento radial. Por ejemplo, puede que tuviera que establecer
una arquitectura de este tipo en Exchange 5.5 para poder admitir rutas con cable, para lo cual es
muy probable que implementara una serie de servidores destinados al enrutamiento de mensajes
en el sitio central.
La inclusión del enrutamiento de estado de los vínculos en Exchange 2000 hizo posible que los servidores
de envío establecieran la mejor ruta de enrutamiento de acuerdo al estado del vínculo. Este cambio
supuso un avance hacia las redes de igual a igual entre grupos de enrutamiento, ya que los mensajes
provenientes de cualquiera de estos grupos encontraban una ruta directa hacia el grupo receptor a través
de la red troncal.
Con Exchange 2003 se va más allá y se mejoran las características de enrutamiento de estado de
los vínculos reduciendo el tráfico de estado de los enlaces de dos maneras.
Se mejora el rendimiento con relación a lo que habitualmente se conoce como vínculo
oscilante, o enlaces de disponibilidad discontinua. En Exchange 2003 se reduce el tráfico de
estado de los vínculos determinando si el conector es oscilante. Si hay varios cambios de
estado que producen un conflicto en la cola de estado de los vínculos para un conector, éste se
considera como un vínculo oscilante y el estado de los vínculos se mantendrá como activo (en
servicio o disponible durante ese período). Si un conector oscilante se mantiene activo en lugar
de ir cambiando su estado permanentemente, se reducirá el tráfico de estado de los vínculos
que se replica entre los servidores.
Se mejora el rendimiento en los sitios para los que sólo existe una ruta. En esta situación,
Exchange 2003 reduce el tráfico de estado de los vínculos estableciendo que no existe una
ruta alternativa y suprimiendo la información de estado de los vínculos. Si no existe una ruta
alternativa para un vínculo, su estado se marca siempre como activo (en servicio). Exchange
deja el correo en la cola para su entrega y lo envía cuando la ruta se encuentre disponible.
Con estos dos cambios mejora el rendimiento porque se reduce la propagación de la información
sobre el estado de los vínculos.

Servicio de Volume Shadow Copy

Uno de los límites prácticos en cuanto al número de usuarios que un único servidor admite es el
tiempo que tarda en realizar copia de seguridad del almacenamiento de correo. Para reducir este
límite de forma significativa, es necesario poder realizar una copia de seguridad y restaurar
rápidamente los almacenes del buzón y los almacenes de carpetas públicas. Exchange 2003
funciona con el servicio de Volume Shadow Copy de Windows Server 2003 para ayudarle a crear
rápidamente copias de seguridad de los datos de Exchange en un momento determinado.
Este servicio pone fin a los problemas que tenían lugar con los métodos de copia de seguridad
anteriores. Cuando una base de datos de Exchange se conecta, las transacciones por correo electrónico
continúan produciéndose en cualquier momento. De este modo, si intenta hacer una copia de
seguridad rápida (una instantánea) de los datos en un momento determinado, estas transacciones
seguirán llevándose a cabo mientras la copia se realiza, con lo que se corre el riesgo de que, una vez
acabada la copia de seguridad, contenga datos poco coherentes. Además, debido a que se recomienda
almacenar en volúmenes independientes los archivos de base de datos de Exchange (archivos .edb),
los archivos
de registro de transacciones y el contenido de las extensiones multipropósito de correo Internet (MIME)
(archivos .stm), los datos pueden ser poco coherentes. Así, si hace una instantánea de unos datos en
proceso de cambio, y aún no se ha escrito en el archivo de registro, los archivos no coincidirán.
Sin el servicio de Volume Shadow Copy, la forma de solucionar este problema consiste en realizar
copias de seguridad con la base de datos fuera de conexión, es decir, en tiempo de inactividad. En
otras palabras, deberá cerrar Exchange para poder llevar a cabo una copia de seguridad
coherente. Sin embargo, este enfoque presenta problemas de organización y anula cualquier
ventaja de las instantáneas. Asimismo, dificulta realizar las copias de seguridad completas, dada la
creciente demanda para que los sistemas estén disponibles 24 horas al día, 7 días a la semana.
El servicio de Volume Shadow Copy, por el contrario, crea instantáneas puntuales coherentes
mientras el sistema está conectado. Así, cuando recibe una solicitud de copia de seguridad, este
servicio avisa al resto de servicios de Exchange de que va a realizarse una copia de seguridad. A
continuación, Exchange se prepara para la copia
de seguridad limpiando las estructuras de disco y vaciando los archivos de registro
y en caché.
Importante: Exchange es compatible con el servicio de instantáneas de volumen para las
copias de seguridad normales y de copia, pero no para las copias de seguridad incrementales o
diferenciales.

Compatibilidad con el modo de intercambio en caché de Outlook 2003

Exchange 2003 es compatible con el modo de intercambio en caché de Outlook 2003, mediante el
cual el usuario tiene acceso a la información de Exchange desde la caché local en forma de archivo
.ost. Exchange garantiza la sincronización entre el buzón del servidor y el archivo .ost del equipo
cliente siempre y cuando la conexión de red esté disponible; así, en caso de que la conexión sea
discontinua o se pierda por completo, el usuario podrá continuar con su trabajo obteniendo los
datos de correo electrónico desde la información almacenada en el archivo .ost. Las
actualizaciones que el equipo cliente solicita al servidor de Exchange se eliminan, de manera que
los usuarios de Outlook 2003 no volverán a ver el mensaje que indica tal solicitud de datos del
servidor de Exchange en períodos de intermitencia o no conectividad. Con esta eliminación de
solicitudes de actualización del equipo cliente se reduce también el tráfico de datos del equipo
cliente al servidor.
Para obtener más información acerca del modo de intercambio en caché, consulte "Mejoras en
Outlook 2003", más adelante en este capítulo.

Mejoras de Outlook Web Access 2003

La nueva versión de Outlook Web Access en Exchange Server 2003 aporta mejoras como la
autenticación basada en formularios, reglas, corrector ortográfico y la capacidad de enviar y recibir
mensajes de correo electrónico firmados digitalmente y cifrados. La interfaz de usuario también se ha
rediseñado de manera considerable a fin de proporcionar al usuario la misma experiencia que con
Outlook 2003, incluidos un panel de vista previa situado a la derecha y un panel de navegación
mejorado.
Con Outlook Web Access para Exchange, el rendimiento es aún más rápido, en especial con
conexiones bajas, con lo que será al mismo tiempo más receptivo a las interacciones del usuario.
A continuación se detallan las nuevas características más destacables en Outlook Web Access para
Exchange 2003:
Bytes enviados: al reducir la cantidad de información que se transmite desde
el servidor al explorador, se ha aumentado la velocidad de Outlook Web Access.
Se ha reducido el número de bytes que se envían desde el servidor al explorador. No obstante,
recuerde que el proceso de inicio de sesión precisa de una mayor cantidad de bytes que el
proceso en Outlook 2003.
Admite compresión: los administradores pueden configurar la compatibilidad
con compresión para Outlook Web Access y mejorar el rendimiento en casi un 50 por ciento para la
mayoría de las acciones en redes de baja velocidad. El rendimiento del usuario en Outlook Web
Access se ha mejorado para las conexiones de red de baja velocidad gracias a que admite la
compresión de datos. La compresión en Outlook Web Access funciona comprimiendo páginas Web
estáticas, dinámicas, o ambas, según la configuración de la que se haga uso. Mediante la
compresión de datos, es posible apreciar cómo se produce un incremento del rendimiento de hasta
un 50 por ciento en conexiones de red lentas como, por ejemplo, las conexiones de acceso
telefónico tradicionales. Puede habilitar la compresión desde el Administrador del sistema de
Exchange.
Autenticación basada en formularios: es posible habilitar una página de inicio de sesión
nueva para Outlook Web Access que almacenará el nombre y la contraseña del usuario en una
cookie, en lugar de hacerlo en el explorador. Cuando un usuario cierre su explorador, la cookie se
borrará. Además, tras un período de inactividad, la cookie se borrará automáticamente. La nueva
página de inicio de sesión requiere que el usuario introduzca su dominio, nombre de usuario y
contraseña, o bien su dirección de correo UPN completa y contraseña. Para habilitar la página de
 inicio de sesión de Outlook Web Access, es necesario habilitar la autenticación basada en
formularios en el servidor.
Las mejoras de las características, de la funcionalidad y del rendimiento pueden afectar a las
decisiones acerca de cómo los usuarios deben tener acceso principalmente a su información de
Exchange. Por ejemplo, en sitios remotos es posible que Outlook Web Access sea la opción
principal, algo que hay que tener en cuenta al diseñar conexiones WAN y la ubicación del servidor.

Compatibilidad de dispositivos móviles para Exchange Server 2003

Exchange 2003 permite utilizar dispositivos móviles a través de dos aplicaciones que admiten
tanto dispositivos para Microsoft Windows Mobile™ 2003 como otros tipos
de dispositivos móviles. Puede implementar el soporte para dispositivos móviles en Exchange con
el fin de facilitar a los usuarios el acceso a la información de Exchange desde diversos dispositivos
móviles. La implementación del servidor de Exchange para usar Exchange ActiveSync® y Outlook
Mobile Access es la misma que para usar Outlook Web Access 2003. De manera predeterminada,
cuando se instala Exchange, todos los usuarios pueden realizar sincronizaciones y tener acceso
para explorar con Outlook Mobile Access.
Sincronización: mediante la sincronización de un dispositivo con un servidor de
Exchange, es posible tener acceso a la información de Exchange sin tener que estar
continuamente conectado a una red móvil. Los usuarios pueden utilizar la conexión de
operador móvil de que disponen para sincronizar la información de Exchange con su dispositivo
Pocket PC 2002 Phone Edition o Smartphone y llegar después a esta información cuando no se
encuentren conectados.
Notificaciones actualizadas: las notificaciones actualizadas son mensajes SMS
generados de manera automática que se envían a un dispositivo móvil de Windows del usuario
cuando un mensaje de correo electrónico, una cita del calendario o un contacto llega al buzón.
Los usuarios deben configurar sus dispositivos para poder recibir este tipo de notificaciones.
Acceso desde el explorador móvil: Exchange Server 2003 incluye la aplicación Outlook
Mobile Access, que permite a los usuarios utilizar dispositivos móviles para tener acceso a las
carpetas de correo, contactos, calendario y tareas.

Mejoras en Outlook 2003

Outlook 2003 ofrece una funcionalidad más precisa en las siguientes áreas:
Modo de intercambio en caché
RPC a través de HTTP
autenticación Kerberos
Algunas de las mejoras de estas áreas dependen de si se está ejecutando Windows Server 2003 o
Outlook 2003. A continuación se detalla tanto estas mejoras como las dependencias
correspondientes.

Modo de intercambio en caché

El modo de intercambio en caché en Outlook 2003 mejora considerablemente la experiencia de los
usuarios en oficinas con conexiones de ancho de banda de velocidad baja y latencia alta, ya que facilita el
acceso al correo tanto desde una caché local (archivo .ost) como desde el servidor de Exchange 2003.
Exchange 2003 proporciona una compatibilidad mayor con
el modo de intercambio en caché que las versiones anteriores, ya que sincroniza de forma eficaz el buzón
del servidor y el archivo .ost del equipo cliente. Se eliminan las solicitudes
de actualización del equipo cliente al servidor de Exchange.
El modo de intercambio en caché es particularmente útil en sucursales, donde las oficinas remotas
tienen conexiones poco confiables o de baja velocidad. Los usuarios pueden trabajar desde la caché
con o sin una conexión de red, y Exchange sincroniza la caché local y el buzón del servidor cuando hay
una conexión disponible. Además, el modo de intercambio en caché requiere menos solicitudes al
servidor, lo que reduce la cara del servidor por usuario y, al mismo tiempo, ayuda a admitir más
usuarios por servidor.
Nota: cuando los usuarios de Outlook utilizan el modo de intercambio en caché
y se produce un cambio importante en el directorio, cada equipo cliente de Outlook recibe una
 descarga completa de la libreta de direcciones sin conexión. Esta descarga completa tiene lugar no
sólo para los equipos cliente del sitio que se está consolidando, sino en todos los sitios remotos.
Esta descarga completa se produce por ejemplo durante la consolidación de sitios.

Aspectos de implementación para el modo de intercambio en caché

Al implementar Outlook 2003 en el entorno de mensajería, puede permitir que
los usuarios utilicen la función de modo de intercambio en caché para Outlook.
No obstante, cuando implemente esta función, deberá asegurarse de estructurarla
en turnos. Un archivo .ost se crea en el equipo cuando el usuario intenta sincronizar con un
servidor de Exchange. Esto quiere decir que toda la información contenida en
el buzón del usuario en cuestión va a transferirse del servidor al equipo. Por este motivo, debe
estructurar esta función en turnos para reducir el número de usuarios
que intentan realizar una sincronización inicial entre su servidor de Exchange y su equipo donde se
ejecuta Outlook 2003. La estructura en turnos del modo de intercambio en caché es necesaria porque
los usuarios descargarán sin problemas una copia completa de su buzón desde el servidor de Exchange
y podrán utilizarlo en su equipo local. Esta descarga inicial puede afectar negativamente al rendimiento
del servidor de Exchange en caso de que muchos usuarios descarguen sus buzones de correo de
manera simultánea.
La cantidad de datos tiene una relevancia especial cuando la conexión es de baja velocidad y son
varios los usuarios conectados al mismo tiempo. En caso de que
los buzones de correo sean muy grandes (más de 2 GB cada uno, por ejemplo),
la sincronización con el archivo .ost podría tener una repercusión importante en
la conexión de red. Esta situación ocurre especialmente en organizaciones que
no limitan el tamaño del buzón.
Observe asimismo que el archivo .ost se halla en el directorio de perfil de manera predeterminada,
de modo que si un usuario tiene perfiles móviles (en diferentes sucursales, por ejemplo), la caché
estará disponible sólo en uno de los perfiles.

RPC a través de HTTP

La función de RPC a través de HTTP en Windows Server 2003 elimina la necesidad
de que los usuarios remotos de una oficina utilicen una red privada virtual (VPN)
para conectarse a los servidores de Exchange. Los usuarios que utilicen Outlook 2003 pueden
conectarse directamente a un servidor de Exchange 2003 en un entorno corporativo a través de Internet.
Para que Exchange sea compatible con la función RPC a través de HTTP, todos los servidores de
Exchange a los que los usuarios con Outlook 2003 tienen acceso deberán utilizar Exchange Server 2003.
Asimismo, RPC a través de HTTP es compatible sólo con Outlook 2003. Por último, todos los equipos en el
entorno de mensajería que los usuarios necesitarán usar con la comunicación RPC a través de HTTP han
de utilizar Windows Server 2003. Esto abarca los siguientes equipos:
Todos los servidores de catálogo global
Todos los servidores de Exchange a los que los usuarios de Outlook 2003 tienen acceso
Una vez que haya configurado la arquitectura de los servidores de aplicaciones para el usuario y
de servicios de fondo de Exchange recomendada con Internet Security and Acceleration (ISA)
Server, los usuarios podrán utilizar RPC a través de HTTP para conectarse a los servidores de
Exchange 2003.
Importante: para utilizar RPC a través de HTTP, el esquema de Active Directory debe
actualizarse a Windows Server 2003.

El método aconsejado para implementar RPC a través de HTTP consiste en instalar ISA Server con
Feature Pack 1 en la red perimetral y colocar el servidor proxy RPC dentro
de la red corporativa. El servidor proxy RPC puede ser tanto el servidor de aplicaciones para el usuario
de Exchange como cualquier otro servidor Web al que los usuarios pueden conectarse desde Internet.
Para habilitar RPC a través de HTTP para su organización, deberá seguir los pasos siguientes:
Configurar un servidor como servidor proxy RPC: si tiene un servidor al que los
usuarios pueden tener acceso desde Internet (como un servidor de aplicaciones para el usuario
de Exchange), puede configurarlo para que sea el servidor proxy RPC. Este servidor se encarga
 de especificar los puertos que se comunican con los servidores de catálogo global y todos los
servidores de Exchange 2003 con los que el cliente de Outlook 2003 ha de comunicarse.
Configurar la red interna para que utilice RPC a través de http: aquellos equipos a los que
los usuarios de Outlook 2003 tienen acceso, incluidos cualquier equipo de Exchange Server 2003 y
los servidores de catálogo global, deben configurarse para la comunicación RPC a través de HTTP.
Adicionalmente, se ha de configurar la red perimetral para permitir las comunicaciones RPC a través
de HTTP.

Autenticación Kerberos
Exchange 2003 y Outlook 2003 pueden utilizar ahora Kerberos para autenticar usuarios de
servidores de Exchange. Si la red utiliza controladores de dominio de Windows Server 2003, los
usuarios pueden autenticar entre bosques a los controladores de dominios en bosques confiables,
de modo que las cuentas de usuario, así como los servidores de Exchange, puedan existir en
distintos bosques.
Exchange 2003 utiliza Kerberos cuando envía credenciales de usuario entre un servidor de
aplicaciones para el usuario de Exchange y un servidor de servicios de fondo de Exchange. En
anteriores versiones de Exchange, se utilizaba la autenticación básica para aplicaciones como
Outlook Web Access para enviar las credenciales del usuario entre un servidor de aplicaciones para
el usuario de Exchange y servidores de servicios de fondo de Exchange. Como consecuencia, las
compañías tenían que utilizar un mecanismo de seguridad como seguridad de Protocolo Internet
(IPSec) para codificar
la información desde un servidor de aplicaciones para el usuario de Exchange a los servidores de
servicios de fondo de Exchange.

Todo en conjunto
Al plantearse la colocación de los servidores de Exchange y la administración de
los directorios y de los servidores, lo habitual es que se empiece con un modelo centralizado y se
vayan agregando servidores, grupos de enrutamiento y grupos administrativos a medida que sea
necesario. Con las características disponibles en Exchange 2003, Windows Server 2003 y
Outlook 2003, se incita a que los negocios establezcan más sistemas de mensajería centralizados
de lo que antes era posible. Además, ante la proliferación de conexiones de mayor velocidad y
mayor ancho
de banda, las compañías formadas por oficinas dispersas geográficamente han de considerar la
posibilidad de centralizar el hardware y la administración a fin de reducir el número de servidores
en ubicaciones remotas. Los factores que controlan la centralización se dividen en tres categorías:
Centralización del hardware de las oficinas remotas: la comunicación entre el equipo
cliente y el servidor se comprime, y el tráfico se reduce notablemente gracias a las mejoras en
las comunicaciones RPC de Outlook y la compresión de Outlook Web Access 2003.
Exchange 2003 presenta una serie de características que ayudan a fusionar los sitios y los
grupos administrativos. Además, con el modo de intercambio en caché en Outlook 2003 se
reduce el número de servidores de ubicaciones remotas que se conectan con una latencia
elevada.
Reducción del número de servidores: para reducir el costo total de propiedad, las
compañías intentan por lo general disminuir el número de servidores necesarios para cubrir las
necesidades de mensajería de sus usuarios. Puede que su compañía decida reducir el número
de servidores realizando inversiones en servidores de aplicaciones para el usuario superiores,
incluidos procesadores de alto rendimiento y servidores con procesadores múltiples.
Windows Server 2003 y Exchange 2003 admiten igualmente la tecnología de subproceso, en la
que un solo procesador puede ejecutar varios subprocesos (y aparece como dos procesadores
en lugar de uno). El procesador debe estar habilitado para subprocesos y deberá usar
Windows Server 2003 y Exchange 2003.
Centralización de la administración de servidores y directorios: es posible que las compañías
quieran combinar y centralizar su plantilla en aras de reducir los gastos administrativos. Una
función que simplifica la administración es el método mejorado para mover buzones de correo en
el Administrador del sistema de Exchange, que permite a los administradores mover los buzones
de forma más eficaz y, además, recuperarse de los fallos sin dificultad cuando encuentren
elementos corruptos. Asimismo, los administradores podrán programar movimientos de buzones
de correo y acabar en un momento determinado.
2. Diseño de la ruta de implementación
La ruta más adecuada para implementar Microsoft® Exchange Server 2003 depende de si
en la organización hay una versión anterior de Exchange en ejecución. La actualización
desde una organización con Exchange 2000 constituye un proceso relativamente sencillo.
Sin embargo, la migración desde una organización con Exchange 5.5 a Exchange 2003 conlleva una
mayor planeación, por cuanto la información de directorio ha de migrarse
al servicio de directorio Microsoft Active Directory® y los datos del sistema de mensajería
a Exchange 2003. Normalmente, el tiempo que ha de invertirse en implementar Exchange 2003 y en
migrar los datos de directorio y del sistema de mensajería a servidores nuevos no supone un
inconveniente para compañías pequeñas, pero en compañías de
gran tamaño, donde la actualización simultánea de todas las ubicaciones es inviable, esta implementación
puede tardar desde varias semanas a incluso años. En cualquier caso,
debe utilizar la versión de Exchange del Conector de Active Directory (ADC) para que la coexistencia
entre organizaciones se mantenga hasta que todas las ubicaciones se hayan actualizado desde Exchange
5.5.
Además, necesitará decidir cuál es la ruta de implementación más adecuada de acuerdo
a las respuestas a las siguientes preguntas:
¿Funciona actualmente la organización con Exchange 5.5, con Exchange 2000,
o con una combinación de ambas versiones?
¿Debe migrar los datos de mensajería desde otros sistemas de mensajería que
no sea Exchange?
En caso de migrar desde una organización con Exchange 5.5, ¿es factible cambiar
a Exchange 2003 poco después del proceso de migración o coexistencia, o bien precisa de un
mayor período de coexistencia?
¿Cuánto tiempo ha de pasar hasta que cambie al modo nativo de Exchange 2003? Hasta
ese momento, ¿se resentiría el negocio por la falta de ciertas características?
Este capítulo se centra en las distintas rutas para implementar Exchange 2003 de acuerdo a estas
preguntas cruciales. Asimismo, recomienda rutas de implementación
en cada situación.

Objetivo: ejecución de Exchange 2003 en modo nativo

Las organizaciones de Exchange 2003 pueden funcionar en dos modos diferentes:
modo nativo y modo mixto. El modo nativo ofrece la funcionalidad completa
de Exchange 2003, mientras que el modo mixto ofrece interoperabilidad entre Exchange 5.5. Al
instalar Exchange 2003, la organización de Exchange se ejecuta
de forma predeterminada en modo mixto. Esta configuración predeterminada asegura la
interoperabilidad futura con Exchange 5.5.
El modo nativo en Exchange 2003 es en esencia el mismo que el modo nativo en Exchange 2000
(aunque con ciertas excepciones, tal y como queda plasmado en la tabla 3.1). El factor
determinante para la ejecución en modo nativo es la presencia
de servidores de Exchange 5.5. Así, podrá pasar a modo nativo si la organización contiene una
mezcla de servidores de Exchange 2000 y de Exchange 2003, pero
no de Exchange 5.5.
Nota: no existe ninguna relación directa entre el modo del dominio de Microsoft Windows® y el
modo de una organización de Exchange. Estos conceptos sólo se parecen en la nomenclatura y
en las restricciones de las versiones anteriores.

Razones para realizar la ejecución en modo nativo

Al ejecutar una organización de Exchange en modo nativo tendrá la flexibilidad completa de
Exchange 2003 para administrar el sistema de mensajería.
Los servidores de Exchange 2003 que se ejecutan en modo nativo le permiten llevar
a cabo las siguientes acciones:
Eliminar el ADC y el Servicio de replicación de sitios.
 Cambiar el nombre de los grupos administrativos.
Consolidar grupos administrativos, y definir grupos de enrutamiento y grupos
administrativos con mayor flexibilidad.
Mover buzones entre servidores en distintos grupos administrativos.
Algunas de las características específicas de Exchange 2003 sólo estarán disponibles cuando la
organización de Exchange se ejecute en modo nativo:
Grupos de distribución basados en consultas: un grupo de distribución basado
en consultas ofrece la misma funcionalidad que un grupo de distribución estándar, pero, en lugar
de especificar pertenencias de usuario estáticas, un grupo de distribución basado en consultas
permite utilizar una consulta de Protocolo ligero de acceso
a directorios (LDAP) para crear pertenencias dinámicamente. La distribución basada
en consultas funciona de forma confiable en implementaciones de Exchange 2003 puro o en una
implementación nativa de Microsoft Exchange 2000 y Exchange 2003 en la que todos los
servidores de Exchange 2000 ejecutan Service Pack 3 (SP3) con los servidores de catálogo global
de Microsoft Windows Server™ 2003. Si bien los grupos de distribución basados en consultas
funcionan con Microsoft Windows 2000 Server,
su rendimiento es notablemente mejor con Windows Server 2003.
InetOrgPerson: la clase de objeto InetOrgPerson se utiliza en diversos servicios de
directorio LDAP distintos de Microsoft y X.500 para representar a los miembros de una
organización. La compatibilidad de Exchange 2003 con InetOrgPerson permite realizar
migraciones desde otros directorios LDAP a Active Directory de una forma mucho más eficaz.
Sólo se pueden crear objetos InetOrgPerson si se ejecuta un controlador de dominio de
Windows Server 2003. Los objetos InetOrgPerson pueden tener el correo o el buzón
habilitados sólo cuando la organización es una organización de Exchange 2003 pura que se
ejecuta en modo nativo.
La tabla 3.1 contempla las características disponibles en el modo nativo y en el modo mixto.

Tabla 3.1 Características disponibles en el modo nativo y en el modo mixto

Característica ¿Disponible en una ¿Disponible en modo ¿Disponible en una

organización mixta nativo de organización de
de Exchange 5.5, Exchange 2003 o Exchange 2003 pura
Exchange 2000 Exchange 2000? que funciona en
y Exchange 2003? modo nativo?

Mover buzones entre Sí Sí Sí

servidores en el
mismo grupo
administrativo

Mover buzones entre No Sí Sí

servidores en distintos
grupos administrativos

Crear un grupo No Sí Sí
administrativo que
abarca diversos
grupos de
enrutamiento

Usar grupos de No Sí Sí
distribución basados
en consultas

Posibilidad de habilitar No No Sí
objetos InetOrgPerson
para buzón o correo
Ejecución en modo mixto
Para que Exchange 5.5, Exchange 2000 y Exchange 2003 coexistan y repliquen información de
directorio, la configuración de Exchange 2000 y de Exchange 2003 debe permanecer en un estado
que Exchange 5.5 pueda reconocer. Si ejecuta la organización de Exchange en modo mixto, la
interoperabilidad entre estas versiones de Exchange será posible. ADC también es importante para
asegurar la coexistencia entre el directorio de Exchange 5.y Active Directory.
Nota: a causa de las limitaciones del funcionamiento en modo mixto, no debe utilizarlo si la
organización usa estrictamente servidores de Exchange 2000 y de Exchange 2003, ni cuando
tenga total certeza de que no va a instalar un servidor
de Exchange 5.5 en la organización.

El modo mixto está diseñado únicamente para la interoperabilidad de servidores de Exchange 2003
y de Exchange 5.5, de modo que tenga previsto cambiar al modo
nativo en cuanto sea posible. El funcionamiento de la organización de Exchange
en modo mixto presenta las siguientes limitaciones y consideraciones:
Los sitios de Exchange 5.5 se asignan directamente a los grupos administrativos
y viceversa.
Sólo puede mover buzones entre servidores que estén en el mismo grupo administrativo.
La pertenencia a un grupo de enrutamiento sólo debe constar de los servidores instalados
en el grupo administrativo definido con el grupo de enrutamiento.
Nota: cuando una organización de Exchange 2003 está en modo mixto y los sitios de
Exchange 5.5 se asignan uno a uno con grupos administrativos, puede subdividir la
estructura de enrutamiento para los servidores de Exchange 2003 del conjunto mediante
grupos de enrutamiento. Dado que en modo mixto un grupo de enrutamiento concreto
pertenece exclusivamente a un grupo administrativo, un servidor no podrá pertenecer a un
grupo de enrutamiento contenido en un grupo administrativo diferente. Los servidores de
Exchange 5.5 no hacen distinción alguna entre grupos de enrutamiento y siguen utilizando
el límite de sitio con fines de enrutamiento.

Planeando el cambio a modo nativo

Su objetivo debe ser reducir al mínimo el período de coexistencia entre los servidores de
Exchange 5.5 y de Exchange 2003 para que, de este modo, saque el mayor partido de las
características de Exchange 2003. No olvide que tras pasar una organización de Exchange 2003
del modo mixto al modo nativo, la organización ya no podrá interactuar con sistemas
Exchange 5.5. Las organizaciones de Exchange que funcionan en modo nativo pueden contener
servidores de Exchange 2003 y Microsoft Exchange 2000.
Sólo podrá cambiar una organización de Exchange a modo nativo cuando todos los servidores de
Exchange de la organización ejecuten Exchange 2003 o Exchange 2000.
Especifique el momento en que todas las condiciones que se indican a continuación
se cumplen en la planeación del proyecto y, cuando esto ocurra, planee cambiar
la organización de Exchange a modo nativo:
Ya no tiene servidores de Exchange 5.5 en la organización.
No va a agregar servidores de Exchange 5.5 a la organización en el futuro; por ejemplo,
como resultado de una fusión o la adquisición de una compañía que tiene servidores de
Exchange 5.5.
La compañía no requerirá nunca interoperabilidad entre los servidores de Exchange 2003 o
Exchange 2000 y Exchange 5.5. (Puede usar conectores para proporcionar conectividad a
versiones anteriores de Exchange, si bien estos servidores son externos a la organización de
Exchange.)
La organización no utiliza aplicaciones para conectores o puertas de enlace que sólo se
ejecutan en Exchange 5.5.
Importante: tras cambiar del modo mixto al modo nativo, no podrá revertir
el cambio y la organización ya no podrá interoperar con sistemas Exchange 5.5.
Instalación de una organización de Exchange 2003 nueva
La implementación de Exchange 2003 en una organización donde no hay versiones anteriores de
Exchange en funcionamiento es bastante sencilla. Las consideraciones esenciales son si la organización
funciona con Windows 2000 Server o Windows Server
2003 y, al mismo tiempo, si Active Directory está implementado de forma que sea posible acomodar a
Exchange. Otro aspecto importante es si necesita conectarse a sistemas de mensajería que no son de
Exchange (como puedan ser Lotus Notes o Novell GroupWise)
o migrar de ellos. Si es así, deberá plantear la instalación y ejecución de conectores.

Este tema será tratado en profundidad en el Capítulo 1 “Instalación”.

Actualización desde Exchange 2000

Si el entorno de Exchange actual consiste en una organización de Exchange 2000
pura en modo nativo, quiere decir que Active Directory ya está implementado
y que es compatible con Exchange.
Algo que debe tenerse en cuenta es que, en caso de actualizar un servidor de Exchange 2000 a
Exchange 2003, deberá eliminar antes los siguientes componentes, por no ser compatibles con
Exchange 2003:
Fuente de sucesos de Exchange de Microsoft Mobile Information Server. Este componente
se sustituye en Exchange 2003 por el componente Exchange Mobile Browse.
Servidor de mensajería instantánea, servicio Charla de Microsoft Exchange 2000, Microsoft
Exchange 2000 Conferencing Server, Servidor de administrador de claves, Conector de Microsoft
Exchange para Lotus cc:Mail y Conector de Microsoft Exchange para MS Mail. Si desea conservar
estos servicios en su organización, se recomienda no instalar Exchange 2003 en servidores que
ejecuten dichos componentes. Destine un servidor de Exchange 2000 para la ejecución de tales
componentes.
Asimismo, debería comprobar los servicios de terceras partes que dependen de Exchange 2000 o
interoperan con él para asegurar que son compatibles con Exchange 2003. Ejemplos de estos
servicios son los sistemas de copia de seguridad, aplicaciones antivirus y otros conectores (como
los conectores de fax).

Este tema será tratado en profundidad en el Capítulo 4 “Migración”.

Migración de Exchange 5.5 a Exchange 2003

Si la organización actual funciona con Exchange 5.5, Exchange 2000 o una combinación de ambos
en modo mixto, cuenta con distintas opciones para cambiar a Exchange 2003. Tal y como se ha
señalado antes, deberá tener un entorno de Active Directory estable antes de proceder a la
implementación de Exchange 2003.
No obstante, no es absolutamente imprescindible finalizar la implementación de Active Directory para
implementar Exchange 2003. Así, es posible que aún no pueda mover todas las cuentas de Microsoft
Windows NT® a Active Directory, pero desee definir un dominio de Active Directory donde alojar buzones
de Exchange 2003. En tal caso, puede permitir que ADC cree marcadores de posición en Active Directory
para las cuentas de Windows NT. Exchange 2003 utilizará estos marcadores para asegurar la
funcionalidad de correo electrónico con los sitios de Exchange 5.5 que no están implementados en un
dominio de Active Directory. A continuación, podrá mover todos los buzones correspondientes a estas
cuentas a los servidores de Exchange 2003 implementados en un dominio de Active Directory. Una vez
que esté listo para pasar las cuentas de Windows NT a Active Directory (ya sea actualizando el dominio
de Windows NT o usando las herramientas de migración de Active Directory), puede unir el marcador de
posición de buzón con la cuenta de Windows.
Dependiendo de su situación, puede elegir una de dos rutas posibles para migrar de Exchange 5.5
a Exchange 2000:
 Ruta estándar (recomendada): implementar Exchange 2003 en la organización de
Exchange 5.5.
Ruta de migración externa: migrar los datos de Exchange 5.5 a una organización
independiente de Exchange 2003.
Independientemente de cuál sea el entorno actual, la ruta de implementación recomendada es la
estándar, que implica instalar Exchange 2003 en una organización de Exchange 5.5 existente. Siguiendo
esta ruta, puede utilizar las nuevas Herramientas de implementación
de Exchange en Exchange 2003, que incluyen todos los pasos aconsejados, herramientas
de diagnóstico y vínculos de configuración que son de ayuda para instalar Exchange 2003.
Si no puede instalar Exchange 2003 en su organización existente de Exchange 5.5, la otra opción
consiste en migrar los datos de Exchange 5.5 a una organización diferente de Exchange 2003.
En esta sección se describen estas dos rutas de implementación.

Ruta estándar: implementación de Exchange 2003 en la organización de Exchange 5.5

(recomendado)
Este método es recomendable en el sentido de que puede sacar partido de las Herramientas de
implementación de Exchange Server, que servirán de guía durante el proceso completo. Estas
herramientas facilitan los pasos aconsejados, las herramientas de diagnóstico y los vínculos de
configuración necesarios para instalar Exchange 2003.
En este método, se instala ADC y se utilizan las herramientas de ADC para configurar los acuerdos
de conexión que sincronizan la información de directorio de Exchange 5.5 con Active Directory. A
continuación, se conecta el hardware del servidor nuevo que ejecuta Exchange 2003 a la
organización de Exchange 5.5 existente. Por último, se mueven los buzones y las réplicas de
carpetas públicas al nuevo servidor.
Esta estrategia es enormemente conveniente para la organización en caso de que
no esté previsto realizar cambios significativos en la arquitectura o la topología. Active Directory
debería haberse implementado ya en la organización, si bien no es necesario actualizar todos los
dominios y cuentas de usuario de Microsoft Windows
NT Server versión 4.0 a Windows 2000 Server o Windows Server 2003. Cada sitio
de Exchange 5.5 habrá de incluir al menos un servidor que ejecute Exchange 5.5
con SP3. Asimismo, sería pertinente que la organización existente contuviera al menos un dominio
de Active Directory en modo nativo.

Ruta de migración externa: migración de datos

de Exchange 5.5 a una organización de Exchange 2003 independiente
Un plan alternativo a la adición de un servidor de Exchange 2003 nuevo a la organización de
Exchange 5.5 consiste en crear una organización de Exchange 2003 nueva y migrar
la información de directorio y los buzones a ella. Con este método se instala una nueva organización de
Exchange 2003, y se migran los datos de directorio y de mensajería
a la nueva organización. En este caso es necesario tener Active Directory instalado
en la organización de destino.
Esta opción precisa una combinación de herramientas de migración, cuyo uso dependerá del tamaño
de la migración y de si es necesario que los sistemas coexistan. Los dos modos recomendados para
implementar Exchange 2003 por medio de este método son:
Herramienta de migración para Active Directory Asistente para la migración
Herramienta de migración para Active Directory (o actualización del dominio
de cuentas) ADC Asistente para la migración
Si las cuentas residen en un bosque diferente que los buzones, debe establecer una confianza
entre los dos bosques para que los usuarios puedan tener acceso a sus buzones.
Todavía se hace uso de las Herramientas de implementación de Exchange Server para llevar a
cabo los distintos pasos de implementación estándar, pero durante el programa de configuración
de Exchange, se opta por no unir una organización de Exchange 5.5.
Herramienta de migración para Active Directory Asistente para la migración
El uso de la Herramienta de migración para Active Directory (ADMT) seguido del Asistente para la
migración de Exchange Server es el mejor método para las empresas pequeñas que no tienen que
migrar muchos buzones.
En primer lugar, ejecute ADMT para crear cuentas de usuario activas en Active Directory. Debe
seleccionar la opción para migrar los identificadores de seguridad (SID) para asegurarse de que ADMT
agregue el SID de la cuenta de origen al nuevo atributo de historial de SID de la cuenta de destino
(SIDHistory). (En el próximo paso, el Asistente para la migración utiliza el SID para hacer coincidir
buzones con cuentas.) Sin embargo, para migrar los SID, el dominio de Exchange 2003 de destino
debe estar en modo nativo.
Importante: para migrar los SID, el dominio de Windows de destino debe estar en modo
nativo. El atributo SIDHistory existe en el esquema de dominio únicamente si el dominio de
Windows está en modo nativo.
Después de migrar las cuentas, utilice el Asistente para la migración con el fin de migrar buzones.
Si migró los SID cuando ejecutó ADMT, el Asistente para la migración utilizará el SID para hacer
coincidir buzones con las nuevas cuentas y convertirá las cuentas en cuentas de usuario
habilitadas para buzones. Si no migró los SID en el primer paso, el Asistente para la migración no
podrá hacer coincidir un buzón con
una cuenta y en su lugar creará una cuenta de usuario deshabilitada para asociarla
al buzón.
Nota: como alternativa al uso de ADMT puede seguir el proceso estándar de actualización de
Windows NT Server versión 4.0 a Windows Server 2003. Con
este proceso el SID se mantiene.

Herramienta de migración para Active Directory

(o actualización del dominio de Windows) ADC Asistente para la migración
En las organizaciones grandes puede utilizar el Conector de Active Directory (ADC)
para permitir que los usuarios envíen y reciban mensajes de correo electrónico durante el proceso
de migración. Antes de configurar el ADC, puede utilizar dos métodos para crear cuentas de
usuario en el directorio de destino de forma que se conserven sus SID:
Puede actualizar el dominio de Windows NT a Windows Server 2003, con lo que
conserva el SID de cada cuenta.
Puede utilizar ADMT, siempre y cuando seleccione la opción para migrar el SID
de la cuenta de origen al atributo SIDHistory de la cuenta de destino.
Si se conserva el SID para cada cuenta del nuevo bosque (mediante una actualización
o migrando el SID al atributo SIDHistory), el ADC puede crear cuentas habilitadas para correo.
Después de instalar el ADC puede ejecutar el Asistente para la migración con el fin de mover
buzones.
Importante: para migrar los SID, el dominio de Windows de destino debe estar
en modo nativo. El atributo SIDHistory existe en el esquema de dominio únicamente si el
dominio de Windows está en modo nativo.
Los pasos de este tipo de migración son los siguientes:
Se crean cuentas nuevas en el bosque de destino mediante uno de dos métodos posibles:
Una actualización de dominio de Windows NT a Windows 2000 o Windows Server 2003
crea cuentas en las que se conservan los SID.
ADMT migra a Active Directory las cuentas de Windows NT asociadas a buzones de
Exchange 5.5 y, después, crea nuevos usuarios de Active Directory. ADMT llena entonces
el atributo SIDHistory para cada usuario nuevo.
ADC busca los nuevos usuarios de Active Directory y les asigna direcciones
de correo electrónico, haciendo que los usuarios estén habilitados para correo.
El Asistente para la migración busca los usuarios de Active Directory buscando
el SID. El Asistente para la migración crea buzones (haciendo que los usuarios
estén habilitados para buzones) y después migra los datos de buzones.
Si prevé que va a invertir una gran cantidad de tiempo en el proceso de creación de cuentas con las
Herramientas de migración de Active Directory, como alternativa quizás desee configurar primero el
ADC para crear contactos en Active Directory. La configuración de ADC hace posible en primer lugar
que los usuarios de Active Directory intercambien mensajes de correo electrónico con usuarios de
Exchange 5.5 en períodos prolongados
de coexistencia. Tal y como sucedía en el método anterior, a continuación se utilizan las Herramientas
de migración de Active Directory para conservar los permisos de cuenta
(por ejemplo, los concernientes a impresoras, recursos compartidos y otros buzones).

Migración de Exchange 2000 y Exchange 5.5

en modo mixto
En caso de que Exchange 5.5 y Exchange 2000 ya coexistan, quiere decir que Active Directory ya
se ha implementado y es compatible con Exchange. El Conector
de Active Directory se ejecuta para mantener la sincronización entre el directorio
de Exchange 5.5 y Active Directory.
En tal caso, son estas las posibilidades de implementación de Exchange 2003:
Actualizar uno de los servidores de Exchange 2000
Implementar un servidor de Exchange 2003 nuevo
En ambas situaciones, primero deberá actualizar ADC en todos los servidores donde
se ejecute a la versión de ADC facilitada con Exchange Server 2003. Asimismo, es conveniente
comprobar que los acuerdos de conexión están configurados en la forma adecuada. Para ello,
utilice las herramientas de ADC proporcionadas en la versión
de Exchange 2003 de ADC.
Importante: las herramientas de ADC proporcionan recomendaciones de acuerdos de conexión
basadas en la configuración del directorio. Para evitar problemas de replicación del directorio,
es muy conveniente aceptar estas recomendaciones.

Una vez que haya actualizado todas las instancias de ADC y haya ejecutado las herramientas de
ADC, puede proceder a la instalación del primer servidor de Exchange 2003, o bien actualizar un
servidor de Microsoft Exchange 2000 a Exchange 2003.
Es importante tener en cuenta que, en caso de actualizar un servidor de Exchange 2000 a
Exchange 2003, deberá eliminar antes los siguientes componentes, por no ser compatibles con
Exchange 2003:
Receptor de sucesos de Exchange de Microsoft Mobile Information Server. Este
componente se sustituye en Exchange 2003 por el componente Exchange Mobile Browse.
Servidor de mensajería instantánea, servicio Chat de Exchange 2000, Microsoft Exchange
2000 Conferencing Server, Servidor de administrador de claves, Conector de Microsoft
Exchange para Lotus cc:Mail y Conector de Microsoft Exchange para MS Mail. Si desea
conservar estos servicios en su organización, se recomienda no instalar los servidores de
Exchange 2003 que ejecuten dichos componentes.

Este tema será tratado en profundidad en el Capítulo 4 “Migración”.

 3. Diseño de la infraestructura de Exchange

En el punto 1, evaluó los requisitos tanto desde una perspectiva de negocio como de usuario y, al
mismo tiempo, determinó el estado del entorno actual. Este capítulo ayuda a identificar los
requisitos técnicos para el sistema de mensajería de Microsoft® Exchange. Una vez que haya
asimilado los requisitos de carácter técnico, puede realizar un análisis de vacío con el fin de
establecer los cambios que el entorno actual necesita, incluidas las actualizaciones de la
infraestructura de la red, del hardware y del software. Este capítulo, igualmente, versa sobre los
conceptos que han de considerarse al diseñar la infraestructura de Exchange. Se tratan las
siguientes áreas:
Restricciones y limitaciones topológicas
Sistemas de mensajería centralizados y sistemas de mensajería distribuidos
Diseño del enrutamiento
Colocación del servidor
Tamaño y ajuste del servidor

Restricciones y limitaciones topológicas

Antes de empezar con el diseño de la organización de Exchange, es importante que sea consciente
de las restricciones y limitaciones de carácter topológico, así como de los límites ya conocidos para
una sola organización de Exchange. Cuanto más básico sea el diseño, más fácil será mantener la
topología. Como pauta general, cree tantos grupos administrativos, grupos de enrutamiento u
dominios como sea posible.
Algunos de los límites están integrados en Exchange. Una organización de Exchange
no puede sobrepasar los siguientes límites:
1000 servidores de Exchange
1000 grupos administrativos
100 dominios
De igual modo, es recomendable no poseer más de 150 grupos de enrutamiento.

Sistemas de mensajería centralizados

y sistemas de mensajería distribuidos
Si la compañía está formada por oficinas, y todas ellas están conectadas con conexiones de red
confiables de ancho de banda de alta velocidad, la distancia entre estas oficinas no supondrá un
problema a la hora de implementar un sistema de mensajería centralizado.
Un sistema de mensajería centralizado quiere decir que los servidores de Exchange se ubican y
administran en un centro de datos central y que, además, sólo se tiene un grupo de enrutamiento. Al
diseñar el sistema de mensajería, lo mejor es comenzar con este modelo en mente, ya que es el más
rentable y el más sencillo de administrar.
En caso de que la compañía contenga oficinas remotas con conexiones de red poco confiables, de
ancho de banda de baja velocidad y latencia alta, podrá agregar grupos de enrutamiento para
controlar el modo en que el tráfico de mensajería se enruta de una ubicación a otra. No obstante,
tal y como habrá percibido en los dos capítulos anteriores, las ubicaciones remotas y los grupos de
enrutamiento múltiples no suponen un impedimento para centralizar el modelo administrativo.
Además, con las características de Microsoft Windows Server™ 2003, Exchange 2003 y Microsoft
Office Outlook® 2003, contará también con la posibilidad de consolidar el hardware del servidor
quitando servidores de Exchange de los sitios remotos. Con estos cambios, los usuarios podrán
iniciar sesión de manera remota en los distintos servicios de Microsoft Windows® y en
Exchange 2003, y enfrentarse a un menor número de problemas de degradación del rendimiento o
de conectividad.
En esta sección se explican las características de los sistemas de mensajería centralizados y
distribuidos y, al mismo tiempo, se ofrecen una serie de directrices para el diseño de cada modelo.
Características de un sistema de mensajería centralizado
Un sistema de mensajería centralizado consiste en un gran centro de datos que aloja todos los
recursos de los servidores, incluidos los servidores de catálogo global del servicio de directorio
Microsoft Active Directory®, los controladores de dominio y los servidores de Exchange. Este
centro de datos admite a todos los usuarios del sistema de mensajería, se conecten ya sea local o
remotamente. A continuación se enumeran las características de un sistema de mensajería
centralizado:
Los datos se alojan y administran en una ubicación centralizada, aún cuando la conexión
con los usuarios sea remota. Esto presenta una diferencia con respecto
al sistema distribuido, donde los usuarios tienen acceso local a los buzones, si bien la
administración de los servidores es más complicada.
Las actualizaciones del software pueden realizarse desde una ubicación centralizada.
El centro de datos incorpora dispositivos de aislamiento de la alimentación, como los sistemas
de alimentación ininterrumpida (SAI) y las contingencias de "sitio caliente" o "sitio frío". Un sitio
caliente es un sitio comercial de servicios completos que proporciona todo el equipamiento
necesario para que una compañía continúe funcionando en caso de que un desastre tenga lugar,
mientras que un sitio frío es un servicio que facilita espacio, pero que la compañía ha de
proporcionar y configurar. Un sitio caliente hace que la compañía funcione más fluidamente, pero el
sitio frío constituye una opción menos costosa.
Los requisitos de negocio con relación a la reducción de costos, así como los requisitos
de seguridad, constituyen la rueda giratoria de los sistemas centralizados. Los requisitos giran en torno
a la centralización de las ubicaciones (disminuyendo el número de sitios que ofrecen recursos de
servidor), a la consolidación tanto física (sustituyendo servidores más pequeños por otros de
aplicaciones para el usuario superiores) como administrativa, así como en torno a la consolidación de
datos (centralizando las soluciones de almacenamiento que proporcionan capacidades de copias de
seguridad y de recuperación de desastres).

Consideraciones importantes
Plantéese un diseño centralizado sólo si los requisitos previos de las siguientes áreas
se cumplen en el plan del proyecto o se incluyen en él:
Actualizaciones de clientes: si tiene previsto implementar Exchange 2003,
pero no así Outlook 2003, no podrá disponer del modo de intercambio en caché y,
en consecuencia, la experiencia no será mejor. De hecho, si tanto las conexiones
de red entre equipos cliente como el sitio de centro de datos propuesto son de velocidad baja y
poco confiables, deberá pensar en un diseño distribuido.
Costos del hardware del centro de datos: contraste el costo derivado de
la instalación de los servidores de aplicaciones para el usuario superiores y de clusteres en el
centro de datos con el ahorro en el costo administrativo de la centralización de los servidores.
Es recomendable que agrupe los servidores
de servicios de fondo para contar con una gran disponibilidad y redundancia
en el sistema, si bien esto conlleva un costo mayor. No obstante, estos costos
se compensan enormemente con la disminución de costos operacionales y de infraestructura,
un tiempo de inactividad reducido y una escalabilidad mayor.
Plan de contingencias: al centralizar los recursos de servidores y de datos
en toda la organización, las posibilidades de que se produzcan fallos puntuales aumenta. Por lo
tanto, debe formular planes de contingencias para aquellos
casos en los que el centro de datos sufre una catástrofe.
Cortes en la red: considere el impacto que un corte en la red podría causar en
los usuarios de ubicaciones remotas. Esta situación es puramente anecdótica si los usuarios
tienen el modo de intercambio en caché habilitado.
Reducción de los costos operacionales y administrativos: la centralización
de los recursos de servidor reduce los costos operacionales, ya que la capacidad
y el aumento de los servicios se consigue gracias a un mejor uso de los recursos. Asimismo, se
reducen los costos de infraestructura asociados a los requisitos de almacenamiento y copia de
seguridad.
 Almacenamiento de datos: a mayor volumen de datos centralizados, más numerosos
han de ser los sistemas de almacenamiento confiables que han de utilizarse para, así, mejorar
la integridad de los datos. De igual modo, si se reduce la complejidad de la infraestructura del
servidor, estará más preparado para restaurar los servicios y los datos en caso de que un error
se produzca.
Conectividad de LAN y WAN: si la red actual no proporciona el tipo de ancho
de banda y la velocidad necesarias para los servidores centralizados, debería incluir una
actualización de la red en los planes de proyecto.
Seguridad: un modelo centralizado tiene como resultado una administración de la
seguridad más sencilla y, en consecuencia, un mayor control. Gracias a este control, el
personal de seguridad mantiene firmas contra virus actualizadas y reacciona ante incidentes
relacionados con la seguridad a tiempo y de forma más sencilla. Otra ventaja del diseño
centralizado reside en que los servidores se ubican en un centro de datos que se puede
asegurar físicamente.

Características de un sistema de mensajería distribuido

La implementación de un sistema de mensajería distribuido o de sucursales se lleva
a cabo en el caso de varias sucursales o pequeños sitios distribuidos con conexiones
de poca velocidad a un hub o un centro de datos. Cada sucursal contiene los servidores de
Exchange, los controladores de dominio y los servidores de catálogo global propios. Normalmente,
un sistema de mensajería distribuido se adopta cuando una red no puede controlar el tráfico a un
hub central para los servicios, de modo que el sistema operativo y los servidores de mensajería se
ubican localmente. Los requisitos de usuario pueden constituir otro factor determinante, ya que si
los requisitos de experiencia y disponibilidad del usuario no se alcanzan mediante la conexión a un
centro de datos, no le quedará alternativa alguna y deberá colocar servidores en los sitios
remotos.
Una implementación de sucursales de Exchange se caracteriza por los siguientes aspectos:
El sistema de mensajería consiste en un gran número de ubicaciones (sucursales), en cada
una de las cuales existe un servidor de Exchange, controladores de dominio y, al menos, un
servidor de catálogo global.
Por lo general, la ubicación de las sucursales incluye un número reducido o variado de
usuarios.
La estructura habitual de la red es como una topología radial.
Las conexiones de red entre las ubicaciones de sucursales y el hub o el centro
de datos central son normalmente de ancho de banda de velocidad baja, de gran latencia y de
escasa confiabilidad.
Entre los motivos principales para implementar un sistema de mensajería distribuido
se encuentran los siguientes:
Los usuarios de la compañía están dispersos en diversos sitios.
La infraestructura de red de la compañía no puede controlar el tráfico a un hub central
para los servicios.
Los requisitos de usuario obligan a colocar un servidor localmente para proporcionar la
mejor experiencia y disponibilidad al usuario.

Consideraciones importantes
Tenga en cuenta los siguientes aspectos cuando tome una decisión sobre un diseño distribuido:
Actualizaciones de software: la implementación de actualizaciones y revisiones
cruciales puede constituir un gran desafío en sistemas de mensajería distribuida.
Si desea utilizar RPC a través de HTTP, todos los equipos del entorno de mensajería que
necesitarán los usuarios para el uso de RPC a través de HTTP deben ejecutarse con
Windows Server 2003, donde se incluyen todos los servidores de catálogo global y todos los
servidores de Exchange a los que tendrán acceso los usuarios
de Outlook 2003.
 Costos administrativos y operativos: los sistemas de mensajería distribuida necesitan
más servidores y generan mayores costos administrativos y operativos.
Almacenamiento de datos: con los servidores distribuidos, la infraestructura
del servicio es más compleja, lo que hace más difícil la restauración de los servicios y los datos
cuando se produce un error.
Conexiones de red: para las oficinas remotas resulta recomendable que la velocidad de
conexión de la red al sitio del concentrador o al centro de datos no sea inferior a 56 Kbps entre los
servidores. No obstante, se recomienda una velocidad de conexión más alta entre un concentrador
y una oficina.
Seguridad: un aspecto importante a tener en cuenta es la seguridad física
de los servidores en las sucursales. En el diseño de las sucursales, debe tomar precauciones
para que los servidores no estén ubicados en zonas abiertas y estén asegurados de forma
física.

Diseño de enrutamiento
La topología de enrutamiento es la base del sistema de mensajería. La topología de enrutamiento
se debe diseñar tomando en consideración la red, el ancho de banda
y los aspectos geográficos. En este capítulo se explica cómo funciona el enrutamiento en Microsoft
Exchange 2003 Server a la hora de crear una topología de enrutamiento que funcione con la red y
los sistemas existentes, y se indica cómo diseñar conectores para la comunicación con
destinatarios externos a la organización.
El enrutamiento define el modo en que Exchange transfiere los mensajes entre servidores. Al
diseñar la topología de enrutamiento, es necesario comprender cómo
se transfieren los mensajes dentro de Exchange y diseñar una topología que permita
la transferencia más eficaz de los mensajes. Asimismo, es necesario considerar las ubicaciones de
los conectores en los sistemas de mensajería externos a la organización de Exchange. Un diseño
cuidadoso puede contribuir a reducir el volumen del tráfico en la red y a optimizar los servicios de
Exchange y de Windows.

Cuándo debe crearse un grupo de enrutamiento

Si se cumple alguno de los siguientes factores, es posible que sean necesarios varios grupos de
enrutamiento:
Las conexiones de red no proporcionan la conectividad necesaria.
Se producen errores con frecuencia en la red subyacente.
Existen múltiples sitios con Exchange 5.5.
La transmisión de mensajes debe programarse y controlarse entre las distintas
ubicaciones.
Es necesario configurar restricciones administrativas en el flujo de mensajes.
En el capítulo 1, ha realizado una valoración exhaustiva de la infraestructura de red existente.
Antes de planear el diseño de enrutamiento, utilice la información obtenida tras responder a las
siguientes preguntas:
¿Cuál es la topología de red actual?
¿Cuáles son las conexiones entre las ubicaciones, incluida la latencia y el ancho
de banda disponible?
¿Qué otras aplicaciones utilizan ancho de bada y qué aplicaciones se esperan en el futuro?
¿Cuántos usuarios hay en cada ubicación?
¿Dónde se ubican los usuarios y cuáles son sus patrones de uso? ¿Con qué grupos se
comunican?
¿Qué tipo de negocio lleva a cabo su empresa? Tenga en cuenta las herramientas que ya
utilizan el ancho de banda (por ejemplo, los sistemas de puntos de venta).
¿Dónde están los centros de datos?
¿Dónde están los puntos de acceso a Internet?
 ¿Necesita tener acceso a carpetas públicas en distintas ubicaciones? ¿Utiliza aplicaciones o
carpetas públicas en diferentes ubicaciones?
¿Necesita compartir información de disponibilidad entre las ubicaciones? (Recuerde que la
información de disponibilidad se controla del mismo modo que las referencias a carpetas
públicas.)
¿Cuál es el diseño actual de Active Directory y dónde están ubicados los controladores de
dominio y los servidores de catálogo global? ¿Cómo están diseñados los sitios de Windows? En
otras palabras, ¿se relacionan con grupos
de enrutamiento?

Consideraciones importantes
Los conectores entre los grupos de enrutamiento constituyen un embudo en la canalización del correo;
por tanto, un exceso de conectores puede tener un impacto negativo en el flujo de mensajes. Por este
motivo, resulta recomendable que evite crear demasiados grupos
de enrutamiento; no conviene sobrepasar los 150. Sin embargo, cuando disponga de
varias conexiones hacia un posible destino, puede definir conectores entre los grupos de enrutamiento
para controlar el flujo de mensajes. Dentro de un grupo de enrutamiento,
la comunicación entre servidores se establece punto por punto, por lo que no es posible definir rutas de
acceso ni costos para garantizar que se selecciona la ruta menos costosa entre dos servidores. Sin
embargo, al crear grupos de enrutamiento, puede asignar costos a varias rutas de acceso para
garantizar que se utiliza la ruta más eficaz.
Además de diseñar los grupos de enrutamiento internos de su organización, necesita planear las
ubicaciones de los conectores para los sistemas de mensajería externos
a su organización de Exchange.

Localización de los servidores

Como Exchange utiliza Active Directory, es muy importante tener en cuenta la topología
de la red de Windows Server a la hora de diseñar la distribución de Exchange. En general, para obtener
el mejor rendimiento, debe comprobar que dispone al menos de un servidor de catálogo global en cada
sitio de Windows en el que está instalado Exchange. Aunque Windows Server 2003 permite a los
usuarios iniciar sesión sin un servidor de catálogo global, Exchange sigue necesitando un servidor de
catálogo global local. Además, el uso
de varios controladores dentro de un dominio distribuye el tráfico en la red y proporciona redundancia
si se producen errores en un controlador de dominio. Para obtener más información acerca del diseño
de los controladores de dominio, los dominios y los sitios
de Windows, consulte la documentación de Windows Server.

Localización de los servidores de Active Directory

En el capítulo 1, ha examinado la estructura actual de Active Directory. En la lista siguiente se
resumen las recomendaciones sobre la ubicación de los servidores de catálogo global y de los
controladores de dominio de Active Directory que van a respaldar la organización de Exchange:
Compruebe que DNS se ha configurado correctamente en el sitio del concentrador
y en todas las sucursales. Asegúrese de que la resolución de nombres y la funcionalidad de DNS
funcionan correctamente.
Compruebe que el servidor al que se le ha asignado la función de maestro en la
infraestructura no es un servidor de catálogo global.
En las sucursales que cuentan con más de diez usuarios, debe instalarse un servidor
de catálogo global en cada ubicación que contenga servidores de Exchange. Conviene instalar dos
servidores de catálogo global para conseguir redundancia. Si un sitio físico no dispone de dos
servidores de catálogo global, puede configurar los controladores
de dominio existentes como servidores de catálogo global.
Exchange requiere WINS.
En las siguientes secciones se incluye más información sobre la ubicación de los controladores de
dominio y los servidores de catálogo global.
Controladores de dominio
En la mayoría de los escenarios de implementación no resulta recomendable ejecutar
Exchange 2003 en equipos que funcionan también como controladores de dominio de Windows. En
su lugar, debe configurar los servidores de Exchange y los controladores de dominio de Windows
como equipos diferentes ya que si Exchange se ejecuta en un controlador de dominio, sólo usará
ese controlador de dominio. Si el controlador de dominio tiene un error, Exchange no puede
conmutar por error a otro controlador de dominio. Además, si los servidores que ejecutan
Exchange no tienen que realizar tareas propias de los controladores de dominio además de dar
servicio a equipos cliente de Exchange, el rendimiento de estos servidores mejora al trabajar con
un gran número
de usuarios.
Para garantizar la seguridad de la información de Active Directory, guarde esta información en
varios controladores de dominio. En el caso de que se produzcan problemas en uno de los
servidores, deberá tener al menos dos controladores de dominio que le ayuden a proteger la
información de Active Directory.
Compruebe además que dispone de un plan de copia de seguridad sólido para los controladores de
dominio. En Exchange 5.5, al realizar una copia de seguridad del archivo Dir.edb, estará haciendo
también una copia de seguridad de la información
del directorio del servidor. Por el contrario, con Exchange 2000 y Exchange 2003, la información
de Exchange se mantiene en Active Directory, y las copias de seguridad
del controlador de dominio constituyen una cuestión crucial. Compruebe que la infraestructura de
Windows admite la copia de seguridad y la confiabilidad de esta información.

Servidores de catálogo global

Los servidores de catálogo global resultan necesarios para iniciar sesión, ya que contienen
información sobre la pertenencia a grupos universales. Esta pertenencia concede o niega a los
usuarios el acceso a los recursos. Si no se puede establecer contacto con un servidor de catálogo
global, no se puede determinar la pertenencia universal de un usuario y se deniega el acceso de
inicio de sesión.
Nota: aunque Windows Server 2003 proporciona características que no requieren un servidor
de catálogo global local, necesitará un servidor de catálogo global local para el uso de
Exchange y Outlook. El servidor de catálogo global es crucial para
los servicios de Exchange (incluidos los servicios de almacén, inicio de sesión y pertenencia a
grupos) y para el acceso a la lista global de direcciones (GAL). La implementación local de
servidores de catálogo global para usuarios y servidores hace que la búsqueda de direcciones
sea más eficaz. Al contactar con un servidor
de catálogo global a través de una conexión lenta, aumenta el tráfico de la red y
se perjudica la experiencia del usuario.

Tenga en cuenta lo siguiente a la hora de ubicar servidores de catálogo global:

Todos los usuarios y los servidores de Exchange deben disponer de un acceso rápido al
servidor de catálogo global.
Debe haber al menos un servidor de catálogo global instalado en cada dominio
que contenga servidores de Exchange.
Debe haber una relación de 4:1 entre los procesadores de Exchange y los procesadores de
servidores de catálogo global, considerando que los modelos
y las velocidades de los procesadores sean similares. Sin embargo, en función
de la situación, de una mayor utilización del servidor de catálogo global, de un mayor volumen
de Active Directory o del uso de grandes listas de distribución,
es posible que sean necesarios más servidores de catálogo global.

Servidores de Exchange
La localización de los servidores de Exchange depende de si el sistema de mensajería está
centralizado o distribuido. Utilice la información recopilada sobre los acuerdos de nivel de servicio,
los requisitos de los usuarios y las versiones de software que va a implementar en la organización
para determinar si los usuarios necesitan tener acceso
a un servidor local de Exchange.

Servidores de buzones
En las ubicaciones remotas que están conectadas mediante redes lentas o no confiables, debe
determinar de qué forma afectan las interrupciones del servicio al negocio y hasta qué punto son
aceptables estas interrupciones. Si el acceso a los datos actualizados de Exchange constituye un
aspecto crucial en todo momento, debe situar los servidores de Exchange en ubicaciones remotas.
Si, tras ponderar los costos derivados de la implantación de servidores adicionales frente al ahorro
que supone un modelo más centralizado, decide que resulta aceptable un cierto grado de
interrupción en el servicio, podrá implementar todos los servidores de Exchange en un centro de
datos. Recuerde que, en este caso, si desea sacar provecho de algunas características, como Modo
de intercambio en caché y RPC a través de http, para mejorar la experiencia de los usuarios remotos,
deberá considerar también la posibilidad de actualizar
a Windows Server 2003 y Outlook 2003.

Servidores de carpetas públicas

Como se ha mencionado anteriormente, si la organización está constituida por
varias ubicaciones remotas, puede almacenar duplicados de las carpetas públicas en servidores
locales de Exchange para que cada ubicación disponga de un duplicado de las carpetas públicas de
las demás ubicaciones. También puede considerar la posibilidad de almacenar toda la información
de las carpetas públicas en un servidor central del centro de datos o del concentrador para que
sólo exista un único origen de datos. Esta decisión se basa en el equilibrio entre precisión y
comodidad, y depende de los patrones de uso y de los requisitos de los usuarios.

Servidores de disponibilidad
Uno de los principales aspectos a tener en cuenta es el acceso a la información de disponibilidad.
Sin una copia local de los datos de las carpetas de disponibilidad, los usuarios pueden recibir con
retraso la información de disponibilidad de otros usuarios
a la hora de programar reuniones. Tenga en cuenta el modo en que los usuarios de la organización
programan las reuniones. Los requisitos acerca del acceso a la información de programación
actualizada pueden variar entre las empresas. Si es importante que los usuarios tengan siempre
acceso a la información de programación más actualizada, debe alojar las carpetas de
disponibilidad en una ubicación centralizada. Si el disponer de la información más actualizada no
es tan importante como la necesidad de un
acceso rápido, puede instalar servidores locales de Exchange en los que se guarde la información
de disponibilidad, teniendo en cuenta que pueden producirse demoras al recibir la información de
disponibilidad actualizada a través de la red. Debe determinar qué nivel de retraso resulta
aceptable para su negocio.
Si decide almacenar la información de disponibilidad en servidores locales de
Exchange, otro aspecto a tener en cuenta es si va a guardar copias de la información
de disponibilidad de otras ubicaciones en el servidor local. Si los usuarios de diferentes ubicaciones
no suelen programar reuniones entre ellos con frecuencia, no es necesario que se mantengan
duplicados locales de la información de disponibilidad de otras ubicaciones. Sin embargo, si decide
mantener copias locales de las carpetas públicas
de otras ubicaciones, tenga en cuenta que el programa de réplica de una carpeta pública
determina cuándo se van a difundir los cambios. Si los duplicados de la información de
disponibilidad están guardados entre varias ubicaciones, puede llevar algún tiempo difundir los
datos de una ubicación a otra. Por ello, un usuario debe consultar los datos locales de
disponibilidad al programar una reunión, por si los datos de disponibilidad están obsoletos debido a
que los cambios de programación efectuados en otra ubicación todavía no se han copiado.

Servidores de listas de direcciones sin conexión

Exchange 2003 utiliza Active Directory para proporcionar servicios de listas de direcciones sin
conexión. Los archivos de listas de direcciones que crea Exchange se guardan en una carpeta
pública. Los usuarios externos pueden conectarse a Exchange
y descargar de forma remota las listas de direcciones sin conexión para recuperar información
acerca de otros usuarios de la organización.
Al generar una lista de direcciones sin conexión, las listas de direcciones especificadas para la lista
de direcciones sin conexión se convierten en un único archivo de datos que se almacena en una
carpeta pública del sistema. Cuando los usuarios descargan la lista de direcciones sin conexión,
este archivo de datos se utiliza como origen de información.
Debe seleccionar un servidor adecuado para crear y actualizar las listas de direcciones sin
conexión. Cuantas más listas de direcciones contenga la lista de direcciones sin conexión, más
ocupado estará el servidor seleccionado para dicha lista.
Si utiliza el Modo de intercambio en caché, debe sopesar el modo en que se verá afectado el
servidor cuando los usuarios descarguen las listas de direcciones sin conexión. El impacto puede
ser importante, no sólo la primera vez que los usuarios descargan las listas de direcciones sin
conexión, sino que el servidor puede verse afectado a diario. Quizás desee considerar la posibilidad
de configurar uno o dos servidores que administren las libretas de direcciones sin conexión.

Ajustes y tamaño del servidor

Para determinar el número de servidores de Exchange que necesita para administrar
la carga de usuarios, utilice las siguientes herramientas de diseño de capacidad:
Capacity Planning and Topology Calculator
Herramienta Microsoft Exchange Server Load Simulation (LoadSim.exe)
Herramienta Exchange Stress and Performance (ESP)
Jetstress
Importante: puesto que algunas de estas herramientas crean cuentas que tienen contraseñas
que no son seguras, su uso está destinado a entornos de prueba, y no a entornos de
producción.

Capacity Planning and Topology Calculator

Capacity Planning and Topology Calculator le ayuda a determinar el tamaño de los servidores que
necesita para la topología de Exchange 2000 o Exchange 2003. Puede encontrar Capacity Planning
and Topology Calculator en http://go.microsoft.com/fwlink/?LinkId=1716

Herramienta Microsoft Exchange Server Load Simulation

Con Microsoft Exchange LoadSim, puede simular la carga de clientes MAPI en Exchange. Para
simular la carga, ejecute las pruebas de LoadSim en equipos cliente. Estas pruebas envían
solicitudes de mensajería al servidor de Exchange, lo que genera una carga en el servidor.
Utilice el resultado de estas pruebas de la forma siguiente:
Para calcular el tiempo de respuesta del equipo cliente para la configuración del servidor
con la carga del cliente
Para estimar el número de usuarios por servidor
Para identificar los cuellos de botella del servidor
Para obtener más información acerca de la herramienta LoadSim o para descargar
dicha herramienta, consulte la sección "Load Simulator" del Kit de recursos de Microsoft
Exchange 2000 Server (http://go.microsoft.com/fwlink/?LinkId=1710).

Herramienta Exchange Stress and Performance

Exchange Stress and Performance (ESP) es una herramienta de rendimiento y aceleración
altamente escalable de Exchange. Simula un gran número de sesiones
de cliente al obtener acceso simultáneamente a uno o varios servicios del protocolo.
Las secuencias de comandos controlan las acciones que realiza cada usuario simulado. Las
secuencias de comandos contienen la lógica necesaria para la comunicación con
el servidor. A continuación, los módulos de prueba (DLL) ejecutan estas secuencias de comandos.
Los módulos de prueba conectan un servidor a través de los protocolos de Internet, de llamadas a
las interfaces de programación de aplicaciones (API), o a través de interfaces como OLE DB.
ESP es modular y extensible, y actualmente cuenta con módulos para la mayoría de los protocolos
de Internet, incluidos los siguientes:
Creación y control de versiones distribuidas en Web (WebDAV, Web Distributed Authoring
and Versioning)
Protocolo de acceso a mensajes de Internet versión 4rev1 (IMAP4)
Protocolo ligero de acceso a directorios (LDAP)
OLE DB
Protocolo de oficina de correo versión 3 (POP3)
Protocolo simple de transferencia de correo (SMTP)
Para obtener más información acerca de la herramienta ESP o para descargar dicha herramienta,
consulte el sitio Web de herramientas y actualizaciones de Microsoft Exchange 2003
(http://go.microsoft.com/fwlink/?LinkId=21316).

Jetstress
Exchange 2003 es una aplicación que utiliza muchos recursos y que requiere un subsistema de
disco confiable y rápido para su perfecto funcionamiento. Jetstress (Jetstress.exe) es una
herramienta de Exchange que ayuda a los administradores
a comprobar el rendimiento y la estabilidad del subsistema de disco antes de utilizar
el servidor de Exchange.

Optimizar el uso de la memoria

El uso de espacio de las direcciones virtuales de un servidor determina la escalabilidad y el
rendimiento general de un servidor de buzones. Cuando se empieza a agotar la memoria virtual, el
rendimiento disminuye de manera espectacular. Aunque Exchange 2003 optimiza de manera
automática el uso de servidores de tamaño pequeño a medio, es necesario realizar ajustes
adicionales para servidores con más de 1 GB de memoria física.

Protocolos admitidos en Exchange 2003

Si tiene pensado admitir usuarios MAPI, HTTP, POP, o IMAP, debe especificar algunas
recomendaciones sobre el diseño de la topología y la configuración de la red. En este capítulo se
explican las recomendaciones asociadas con el uso de servidores de aplicaciones para el usuario y
la configuración de RPC a través de HTTP.

Uso de servidores de aplicaciones para el usuario

En lo que respecta a la compatibilidad de los protocolos individuales en el entorno
de mensajería, la implementación de Exchange comienza con la definición de la arquitectura de
servidores. Si la organización tiene varios servidores de Exchange,
la arquitectura de servidores recomendada para el acceso de los clientes es la arquitectura de
aplicaciones para el usuario y servicios de fondo de Exchange.
Este diseño aborda algunas consideraciones sobre el acceso de los clientes en la implementación
de Exchange. Si desea que haya compatibilidad con MAPI, HTTP,
POP3 o IMAP4, puede utilizar la arquitectura de aplicaciones para el usuario
y servicios de fondo para obtener las siguientes ventajas:
Espacio de nombre único: la primera ventaja de una arquitectura de aplicaciones para el
usuario y servicios de fondo es la capacidad de mostrar un espacio de nombres único y consistente
que los usuarios pueden utilizar para obtener acceso a sus buzones. Sin un servidor de aplicaciones
para el usuario, todos los usuarios deben conocer
el nombre del servidor en el que está almacenado su buzón. Esto dificulta la administración y
compromete la flexibilidad, ya que cada vez que la organización aumenta o cambia, o se trasladan
algunos o todos los buzones a otro servidor, hay
que comunicárselo a los usuarios. Con un espacio de nombres único los usuarios pueden utilizar la
misma configuración de cliente URL o POP e IMAP, incluso si se agregan o se eliminan buzones
entre los servidores. Además, si se crea un espacio
 de nombres único, se garantiza la escalabilidad del acceso POP, IMAP
u Outlook Web Access según va creciendo la organización.
Capacidad del servidor de aplicaciones para el usuario para equilibrar
el procesamiento de tareas entre los servidores: puede configurar los servidores que
ejecutan Exchange 2003 para que admitan el tráfico de Secure Sockets Layer (SSL) entre el
equipo cliente y el servidor, de manera que se proteja el tráfico de la interceptación de un
tercero. Sin embargo, al cifrar y descifrar
el tráfico de mensajes, el procesador invierte tiempo. Cuando se utiliza el cifrado SSL, la
arquitectura de aplicaciones para el usuario y servicios de fondo ofrece una ventaja, ya que los
servidores de aplicaciones para el usuario pueden administrar todos los procesos de cifrado y
descifrado. Además, puede utilizar un acelerador SSL para atenuar el impacto que el cifrado y
el descifrado tienen en el servidor. Un acelerador SSL mejora el rendimiento al eliminar el
procesamiento de tareas de los servidores de servicios de fondo, mientras que permite que se
cifren los datos entre el equipo cliente y el servidor en el que se ejecuta Exchange.
Seguridad: puede establecer el servidor de aplicaciones para el usuario como un único
punto de acceso delante o detrás de un servidor de seguridad de Internet que está configurado
para permitir exclusivamente el tráfico al servidor de aplicaciones para el usuario desde
Internet. Como el servidor de aplicaciones para el usuario no almacena información del
usuario, este servidor proporciona un nivel de seguridad adicional para la organización.
Además, puede configurar el servidor de aplicaciones para el usuario para autenticar
solicitudes antes de que el proxy las procese, lo que ayuda a proteger a los servidores de
servicios de fondo de ataques de denegación de servicio.
Aumento del acceso de IMAP a carpetas públicas: el protocolo IMAP permite que un
servidor remita un cliente a otro servidor. Exchange 2000 admite esta funcionalidad de
referencia en los casos en que las carpetas públicas almacenadas en un determinado servidor
no disponen del contenido solicitado y el cliente debe ser enviado a otro servidor. Sin
embargo, esta funcionalidad requiere un cliente
que admita referencias de IMAP, y la mayoría de los clientes no admiten referencias.
(El kit de herramientas y clientes Pine de la Universidad de Washington es un ejemplo de
cliente que admite referencias.) Cuando un cliente IMAP que no tiene habilitadas referencias se
conecta a través de un servidor de aplicaciones para el usuario, el cliente tiene acceso a toda
la jerarquía de carpetas públicas. Cuando
un servidor de aplicaciones para el usuario envía a través del proxy un comando
a un servidor de servicios de fondo, éste administra automáticamente cualquier respuesta de
referencia que se devuelva al intentar obtener acceso a una carpeta que no está disponible en
el servidor de servicios de fondo. Este proceso hace que la referencia sea transparente para el
cliente. Para obtener más información sobre los clientes IMAP sin referencias habilitadas,
consulte Request for Comments (RFC) 2221 y RFC 2193.
Para obtener más información acerca del uso de servidores de aplicaciones para usuario, consulte
el artículo técnico Using Microsoft Exchange 2000 Front-End Servers
(http://go.microsoft.com/fwlink/?LinkId=14575). Aunque este documento está destinado a
Exchange 2000, los conceptos también son válidos para Exchange 2003.

Escenarios de servidores de Exchange de aplicaciones para el usuario y servicios de

fondo
Aunque la arquitectura de aplicaciones para el usuario y servicios de fondo de Exchange se puede
implementar de varias formas, esta arquitectura de servidor se establece normalmente del mismo
modo. En primer lugar, en la implementación, uno de los servidores de Exchange se designa como
servidor de aplicaciones para el usuario
y se le hace responsable del enrutamiento de todas las solicitudes de los clientes al servidor de
servicios de fondo de Exchange correspondiente. En segundo lugar, debe decidir la ubicación del
servidor de Exchange. En función de esta ubicación, configure
la red interna para administrar la comunicación entre el servidor de aplicaciones para
el usuario de Exchange y los demás equipos con los que debe comunicarse. Por último, cuando
combine la arquitectura de aplicaciones para el usuario y servicios de fondo de Exchange con
Microsoft Internet Security and Acceleration (ISA) Server, dispondrá de un modelo de acceso a
clientes más seguro y confiable.

Funciones de los servidores de aplicaciones para

el usuario y servicios de fondo
La funcionalidad del servidor de aplicaciones para el usuario consiste en enviar solicitudes en nombre
del cliente a través del proxy al recurso o al servidor de servicios de fondo apropiado. No obstante, el
servidor de aplicaciones para el usuario de Exchange se ocupa de otras tareas que dependen del cliente
y del protocolo que se esté utilizando. En el siguiente capítulo se describe el modo en que los
servidores de aplicaciones para el usuario funcionan con un cliente y un protocolo determinados.

Outlook
Microsoft Office Outlook® 2003, así como las versiones anteriores de Outlook, utilizan
la Interfaz de programación de aplicaciones de mensajería (MAPI) para comunicarse con
Exchange. Como los clientes MAPI utilizan llamadas RPC para comunicarse
con Exchange, resulta difícil proporcionar acceso remoto a Exchange. Sin embargo,
Exchange Server 2003 y Outlook 2003 utilizan el componente de red de RPC a
través de HTTP de Windows en Servicios de Internet Information Server (IIS) para proporcionar
acceso remoto a Exchange. Cuando se utiliza RPC a través de HTTP, los clientes de Outlook 2003
envían toda la comunicación al servidor de Exchange a través del puerto 80 (HTTP) o del puerto
443 (HTTPS).

RPC a través de HTTP

Para utilizar el acceso remoto a Exchange, configure la implementación de Exchange para permitir
RPC a través de HTTP. Al configurar Exchange para que utilice RPC a través de http, es necesario
designar el servidor de aplicaciones para el usuario de Exchange para que actúe como servidor
proxy RPC. El servidor proxy RPC administra todas las solicitudes de RPC a través de HTTP en
nombre del cliente y envía la solicitud a través del proxy al recurso de servicios de fondo
correspondiente. Además, los recursos de servicios de fondo, incluidos el servidor de catálogo
global y los servidores de servicios de fondo de Exchange, se van a configurar específicamente
para que se comuniquen con el servidor de aplicaciones para el usuario de Exchange. Si utiliza ISA
Server como un servidor de seguridad avanzado, ISA Server se configura para publicar el
directorio virtual de RPC en el servidor proxy RPC y para permitir a los clientes establecer conexión
con sus servidores de Exchange. ISA Server se puede configurar para controlar e inspeccionar el
tráfico que proviene del puerto 80 o del puerto 443, y, de ese modo, mejorar la capacidad para
administrar el tráfico de red dirigido al servidor de aplicaciones para el usuario de Exchange.

Proteger Exchange con ISA Server 2000

La mejor alternativa respecto a la ubicación de los servidores de aplicaciones para el usuario de
Exchange 2003 en la red perimetral consiste en implementar ISA Server. ISA Server actúa como
un servidor de seguridad avanzado que ayuda a controlar el tráfico de Internet que entra en su
red. Cuando utilice esta configuración, ubique todos los servidores de Exchange 2003 dentro de la
red corporativa, y utilice ISA Server como el servidor de seguridad avanzado expuesto al tráfico de
Internet en la red perimetral.
ISA Server procesa todo el tráfico de entrada de Internet enlazado con los servidores de
Exchange, como Outlook Web Access, la comunicación de RPC a través de HTTP desde clientes de
Outlook 2003, Outlook Mobile Access, POP3, IMAP4, etc. Cuando
ISA Server recibe una solicitud para un servidor de Exchange, ISA Server envía las solicitudes a
través del proxy a los servidores de Exchange oportunos de la red interna. Los servidores internos
de Exchange devuelven los datos solicitados a ISA Server y,
a continuación, ISA Server envía la información al cliente a través de Internet. En la figura 5.1 se
muestra un ejemplo de una implementación de ISA recomendada.
Implementación de Exchange 2003 tras ISA Server

Al utilizar ISA Server como un servidor de seguridad avanzado en la red perimetral para ayudar a
la protección de la red de mensajería, se obtienen las siguientes ventajas:
ISA Server no es miembro del dominio; si ISA Server se ve comprometido, no se puede
penetrar en el dominio.
Como ISA Server no es miembro del dominio, no necesita establecer comunicación con el
servidor de catálogo global ni con el controlador del dominio, lo que reduce
el número de puertos abiertos entre la red perimetral y la red corporativa interna.
ISA Server puede autenticar previamente el tráfico enlazado a los servidores de Exchange
que se origina en Internet, lo que ayuda a garantizar que sólo el tráfico autenticado llega a la
red corporativa.
ISA Server puede detectar y ayudar a prevenir cierto tráfico de red malintencionado, como
los ataques de denegación de servicio y la exploración de puertos.

Utilizar RPC a través de HTTP

La característica RPC a través de HTTP de Windows Server 2003 permite a los usuarios de Outlook
conectarse a su servidor de Exchange a través de Internet incluso si intervienen servidores de
seguridad. La estrategia de implementación recomendada consiste en utilizar ISA Server 2000 con
Feature Pack 1 como infraestructura de seguridad, o ubicar ISA Server en la red perimetral y, a
continuación, colocar el servidor de aplicaciones para el usuario de Exchange (que actúa como servidor
proxy RPC) en la red corporativa. Por otro lado, puede ubicar el servidor de aplicaciones para el usuario
de Exchange 2003 que actúa como servidor proxy RPC en la red perimetral.
Al utilizar ISA Server como servidor proxy inverso, dispone de varias opciones de implementación.
Para obtener más información acerca de la instalación de ISA Server como servidor proxy inverso
para su uso con Exchange.
Al implementar RPC a través de HTTP en el entorno de la empresa, hay dos opciones
de implementación principales en función de dónde se encuentre el servidor proxy RPC:
Opción 1 (recomendada): implemente ISA Server en la red perimetral, y ubique el
servidor proxy RPC (servidor de aplicaciones para el usuario de Exchange) en la red
corporativa.
 Nota: al utilizar ISA Server como servidor de seguridad avanzado, dispone de varias
opciones de implementación. Para obtener más información acerca de la instalación de ISA
Server como servidor de seguridad avanzado.

Opción 2: ubique el servidor de aplicaciones para el usuario de Exchange 2003

que actúa como servidor proxy RPC en la red perimetral.
Cada una de estas opciones se detalla en las secciones siguientes.

Opción 1: ISA Server en la red perimetral

La primera opción consiste en utilizar ISA Server en la red perimetral y ubicar el servidor proxy
RPC (servidor de aplicaciones para el usuario) en la red corporativa.
Ésta es la opción recomendada. Si se utiliza ISA Server en la red perimetral para enrutar
solicitudes de RPC a través de HTTP y se ubica el servidor de aplicaciones para el usuario de
Exchange en la red corporativa, basta con abrir el puerto 80 o el puerto 443 del servidor de
seguridad interno para que los clientes de Outlook 2003 puedan establecer la comunicación con
Exchange. Además, puede eliminar completamente
el servidor de seguridad interno entre ISA Server y la red corporativa, ya que ISA Server con
Feature Pack 1 proporciona características de seguridad adicionales que
los servidores de seguridad estándar no pueden proporcionar. En la figura 5.2 se
ilustra este tipo de implementación.

Figura 5.2 Implementación de RPC a través de HTTP utilizando ISA Server como servidor
proxy inverso en la red perimetral

Cuando se ubica en la red perimetral, el servidor en que se ejecuta ISA Server es

el encargado de enrutar las solicitudes de RPC a través de HTTP hacia el servidor de aplicaciones
para el usuario de Exchange que actúa como servidor proxy RPC. En esta situación, el servidor
proxy RPC utiliza los puertos especificados para establecer comunicación con otros servidores que
utilizan RPC a través de HTTP.

Opción 2: Servidor proxy RPC en la red perimetral

Aunque no es la opción recomendada, es posible ubicar el servidor de aplicaciones para el usuario
de Exchange 2003 que actúa como servidor proxy RPC en la red perimetral. En este caso, se
especifica un número de puertos limitado que requiere el servidor proxy RPC. En la figura 5.3 se
ilustra este tipo de implementación. Tenga en cuenta que, en el ejemplo siguiente, el servidor de
aplicaciones para el usuario de Exchange seguirá precisando todos los puertos estándar para
establecer la comunicación con la red corporativa interna además de los puertos que utiliza RPC a
través de HTTP.
Figura 5.3 Implementación de RPC a través de HTTP en el servidor
de aplicaciones para el usuario de Exchange en la red perimetral

Para obtener más información acerca de cómo configurar las opciones 1 y 2 de implementación de
RPC a través de HTTP, consulte "Implementar RPC a través de HTTP" más adelante en este mismo
capítulo. En este caso, el servidor proxy RPC utiliza de nuevo los puertos especificados para
establecer comunicación con otros servidores que utilizan RPC a través de HTTP.

Implementación de RPC a través de HTTP

Para implementar RPC a través de HTTP, realice las siguientes operaciones:
1. Configure el servidor de aplicaciones para el usuario de Exchange como un servidor proxy
RPC.
2. Configure el directorio virtual de RPC en Servicios de Internet Information Server (IIS) del
servidor de aplicaciones para usuario de Exchange.
3. Configure el registro en el equipo de Exchange 2003 que se comunica con el servidor proxy
RPC para que utilice los puertos especificados por Exchange 2003 para la comunicación de RPC
a través de HTTP.
4. Abra los puertos especificados en el servidor de seguridad interno para RPC a través de
HTTP, así como los puertos estándar para las comunicaciones con el servidor de aplicaciones
para usuario de Exchange.
5. Cree un perfil para los usuarios para la utilización de RPC a través de HTTP.
Después de realizar estas operaciones, los usuarios pueden comenzar a utilizar RPC
a través de HTTP para obtener acceso al servidor de aplicaciones para el usuario de Exchange.
Para utilizar RPC a través de HTTP, es necesario ejecutar Windows Server 2003 en los equipos
siguientes:
Todos los servidores de Exchange 2003 a los que se obtiene acceso mediante RPC
a través de HTTP.
El servidor de aplicaciones para usuario de Exchange 2003 que actúa como servidor proxy
RPC.
Todos los controladores de dominio que se comunican con los clientes de Outlook 2003 y
los servidores de Exchange 2003 configurados para que utilicen
RPC a través de HTTP.
El servidor de catálogo global utilizado por los clientes de Outlook 2003 y los servidores de
Exchange 2003 configurados para utilizar RPC a través de HTTP.
Exchange 2003 debe estar instalado en todos los servidores de Exchange que utiliza
el servidor proxy RPC. Además, todos los equipos cliente que ejecuten Outlook 2003 deben
ejecutar el Service Pack 1 (SP1) o posterior de Microsoft Windows XP con
la actualización "Revisión de Windows XP: actualizaciones de RPC (Llamada a procedimiento
remoto).