Diseño de alta disponibilidad y resistencia de sitios

Diseño de alta disponibilidad y resistencia de sitios
 

Microsoft Exchange Server 2010 incluye un nuevo marco unificado para la resistencia de buzones que incluye nuevas características, como el grupo de disponibilidad de base de datos (DAG) y las copias de base de datos de buzones de correo. Si bien la implementación de estas nuevas características es un proceso simple y rápido, debe realizarse una planificación cuidadosa en forma anticipada para garantizar que cualquier solución de alta disponibilidad y resistencia de sitios que use estas características cumpla con sus expectativas y requisitos comerciales.

Durante la fase de planificación, los arquitectos del sistema, los administradores y otras partes interesadas clave deben identificar los requisitos para la implementación; particularmente, los requisitos de alta disponibilidad y resistencia de sitios. Existen requisitos generales que deben cumplirse para implementar estas características, así como requisitos de hardware, software y redes. Para obtener instrucciones sobre los requisitos de almacenamiento para los DAG, consulte Diseño del almacenamiento del servidor de buzones de correo.

Contenido

Requisitos generales

Requisitos de hardware

Requisitos de almacenamiento

Requisitos de software

Requisitos de red

Requisitos de servidor testigo

Planificación de resistencia de sitios

Planificación de cambios de centro de datos

 Requisitos generales

Antes de implementar un DAG y crear copias de base de datos de buzones de correo, compruebe que se cumplan las siguientes recomendaciones relativas a todo el sistema:

  • Se debe estar ejecutando el Sistema de nombres de dominio (DNS). En condiciones ideales, el servidor DNS debería admitir actualizaciones dinámicas. Si el servidor DNS no las admite, usted debe crear un registro de host DNS (A) para cada servidor de Exchange. En caso contrario, Exchange no funcionará correctamente.
  • Cada servidor de buzones en un DAG debe ser un servidor miembro en el mismo dominio.
  • No se permite agregar un servidor de buzones de Exchange 2010 que también sea un servidor de directorio de un DAG.
  • El nombre que asigna al DAG debe ser un nombre de equipo válido, disponible y único de 15 caracteres o menos.
 Requisitos de hardware

Generalmente, no hay requisitos de hardware especiales que sean específicos de los DAG o las copias de base de datos de buzones de correo. Los servidores usados deben cumplir con todos los requisitos estipulados en los temas para Requisitos previos de Exchange 2010 y Requisitos del sistema para Exchange 2010. Para obtener información de planificación de hardware, consulte los temas siguientes:

 Requisitos de almacenamiento

En general, no hay requisitos de almacenamiento especiales que se apliquen específicamente a los DAG ni a las copias de bases de datos de buzones. Los DAG no requieren ni usan almacenamiento compartido administrado por clúster. El almacenamiento compartido administrado por clúster es compatible con un DAG únicamente cuando éste está configurado para usar una solución que aproveche la API de replicación de terceros integrada en Exchange 2010. Para obtener más información acerca de cómo planificar el almacenamiento, consulte Diseño del almacenamiento del servidor de buzones de correo.

 Requisitos de software

Los DAG están disponibles en Exchange 2010 Standard Edition y Exchange 2010 Enterprise Edition. Asimismo, un DAG puede incluir una combinación de servidores que ejecuten Exchange 2010 Standard Edition y Exchange 2010 Enterprise Edition.

Cada miembro del DAG también debe ejecutar el mismo sistema operativo. Exchange 2010 se admite en los sistemas operativos Windows Server 2008 y Windows Server 2008 R2. Todos los miembros de un DAG deben ejecutar el sistema operativo Windows Server 2008 o Windows Server 2008 R2. No pueden incluir una combinación de Windows Server 2008 y Windows Server 2008 R2.

Además de cumplir con los requisitos previos para la instalación de Exchange 2010, existen requisitos del sistema operativo que deben cumplirse. Los DAG usan tecnología de clúster de conmutación por error de Windows y, por lo tanto, requieren la versión Enterprise de Windows.

 Requisitos de red

Existen requisitos de red específicos que deben cumplirse para cada DAG y para cada miembro del DAG. Las redes del DAG son similares a las redes públicas, mixtas y privadas usadas en versiones anteriores de Exchange. Sin embargo, a diferencia de las versiones anteriores, es posible configurar una única red en cada miembro del DAG. Además, la terminología ha cambiado ligeramente. En lugar de redes públicas, privadas o mixtas, cada DAG cuenta con una única red MAPI, que es usada por otros servidores (p. ej., otros servidores de directorio, servidores de Exchange 2010, etc.) para comunicarse con el miembro del DAG, y ninguna o más redes de replicación, que son redes dedicadas al trasvase de registros y la inicialización.

Si bien se admite una única red, recomendamos que cada DAG tenga, al menos, dos redes: una única red MAPI y una única red de replicación. Esto ofrece redundancia para la red y la ruta de la red, y permite al sistema distinguir entre un error del servidor y un error de la red. El uso de un único adaptador de red evita que el sistema distinga entre dos tipos de errores.

Dd638104.note(es-ES,EXCHG.141).gifNota:
La documentación del producto en esta área de contenido está redactada sobre el supuesto de que cada miembro del DAG incluye, al menos, dos adaptadores de red, que cada DAG está configurado con una red MAPI y, al menos, una red de replicación, y que el sistema puede distinguir entre un error de la red y un error del servidor.

Tenga en cuenta lo siguiente al diseñar la infraestructura de red para su DAG:

  • Cada miembro del DAG debe tener, como mínimo, un adaptador de red que pueda comunicarse con los demás miembros del DAG. Si usa una única ruta de red, le recomendamos que use Gigabit Ethernet. Al usar un único adaptador de red en cada miembro del DAG, la red del DAG debe estar habilitada para la replicación y debe estar configurada como una red MAPI. Debido a que no hay otras redes, el sistema usará la red MAPI también como una red de replicación. Asimismo, al usar un único adaptador de red en cada miembro del DAG, recomendamos que diseñe la solución general teniendo en cuenta el adaptador de red único y la ruta.
  • El uso de dos adaptadores de red en cada miembro del DAG le ofrece una red MAPI y una red de replicación, y los siguientes comportamientos de recuperación:
    • En caso de que ocurra un error que afecte la red MAPI, ocurrirá una conmutación por error del servidor (siempre que haya copias de base de datos de buzones de correo en buen estado que puedan activarse).
    • En caso de que ocurra un error que afecte la red de replicación, si la red MAPI no se ve afectada por el error, las operaciones de trasvase de registros e inicialización se revertirán para usar la red MAPI. Cuando se restaure la red de replicación que presenta el error, las operaciones de trasvase de registros e inicialización volverán a la red de replicación.
  • Cada miembro del DAG debe tener el mismo número de redes. Por ejemplo, si planea usar un único adaptador de red en cada miembro del DAG, todos los miembros del DAG también deben usar un único adaptador de red.
  • Cada DAG debe tener una red MAPI como máximo. La red MAPI debe proporcionar conectividad a los otros servicios y servidores de Exchange, como Active Directory y DNS.
  • Se pueden agregar redes de replicación, según sea necesario. También puede evitar que un adaptador de red individual sea un punto de error único al usar la formación de equipos del adaptador de red o una tecnología similar. Sin embargo, incluso si se usa la formación de equipos, no se evitará que la red misma sea un único punto de error.
  • Cada red de cada servidor miembro del DAG debe encontrarse en su propia subred de red. Cada servidor del DAG puede encontrarse en una subred diferente, pero las redes MAPI y las redes de replicación deben ser enrutables y suministrar conectividad, de modo que:
    • Cada red de cada servidor miembro del DAG se encuentra en su propia subred de red, que es independiente de la subred usada por cada una de las demás redes del servidor.
    • Cada red MAPI del servidor miembro del DAG puede comunicarse con cada una de las demás redes MAPI del miembro del DAG.
    • Cada red de replicación del servidor miembro del DAG puede comunicarse con cada una de las demás redes de replicación del miembro del DAG.
    • No existe un enrutamiento directo que permita el tráfico de latidos de la red de replicación en un servidor miembro del DAG a la red MAPI en otro servidor miembro del DAG, o viceversa, o entre varias redes de replicación del DAG.
  • Independientemente de su ubicación geográfica en relación con otros miembros del DAG, cada miembro del DAG debe contar con una latencia de red de recorrido de ida y vuelta que no supere los 500 milisegundos (ms) entre cada uno de los demás miembros. A medida que la latencia de recorrido de ida y vuelta entre dos servidores de buzones que hospedan copias de una base de datos aumenta, el potencial de replicaciones desactualizadas también aumenta. Independientemente de la latencia de la solución, los clientes deben validar que las redes entre todos los miembros de DAG sean capaces de satisfacer la protección de datos y los objetivos de disponibilidad de la implementación. Las configuraciones con valores de latencia más altos pueden requerir un ajuste especial de los parámetros de DAG, replicación y red, como el aumento del número de bases de datos o la disminución del número de buzones por base de datos, para lograr los objetivos deseados.
  • Es posible que los requisitos de latencia de ida y vuelta no sean los más estrictos en cuanto al ancho de banda de red y a la latencia para una configuración de varios centros de datos. Debe evaluar la carga de red total que incluye acceso de cliente, Active Directory, transporte, replicación continua y otro tráfico de aplicación para determinar los requisitos de red necesarios para su entorno.
  • Las redes del DAG admiten el protocolo de Internet versión 4 (IPv4) e IPv6. La versión IPv6 sólo se admite cuando también se usa IPv4; no se admite un entorno de versión IPv6 exclusivamente. Sólo se admite el uso de direcciones IPv6 e intervalos de direcciones IP si están habilitadas las versiones IPv6 e IPv4 en dicho equipo y la red es compatible con ambas versiones de dirección IP. Si Exchange 2010 está implementado en esta configuración, todas las funciones del servidor podrán enviar datos a dispositivos, servidores y clientes que usen direcciones IPv6, así como recibir datos de ellos.
  • La dirección IP privada automática (APIPA) es una función de Microsoft Windows que asigna automáticamente direcciones IP cuando no hay ningún servidor de protocolo de configuración dinámica de host (DHCP) disponible en la red. Las direcciones APIPA (incluidas las direcciones asignadas manualmente del intervalo de direcciones APIPA) no pueden ser usadas por los DAG ni por Exchange 2010.
 Requisitos de dirección IP y nombre del DAG

Durante la creación, a cada DAG se le asigna un nombre único y una o más direcciones IP estáticas, o se lo configura para usar DHCP. Independientemente de que se usen direcciones asignadas en forma dinámica o estática, cualquier dirección IP asignada al DAG debe encontrarse en la red MAPI.

Cada DAG requiere, al menos, una dirección IP en la red MAPI. Un DAG requiere direcciones IP adicionales cuando la red MAPI se extiende en varias subredes. En la siguiente figura, se ilustra un DAG en el que todos los nodos del DAG tienen la red MAPI en la misma subred.

Grupo de disponibilidad de base de datos con la red MAPI en la misma subred
DAG en una única subred

En este ejemplo, la red MAPI de cada miembro del DAG se encuentra en la subred 172.19.18.x. Como resultado, el DAG requiere una dirección IP única en dicha subred.

En la siguiente figura, se ilustra un DAG que tiene una red MAPI que se extiende en dos subredes: 172.19.18.x y 172.19.19.x.

Grupo de disponibilidad de base de datos con la red MAPI en varias subredes
DAG ampliado en varias subredes

En este ejemplo, la red MAPI de cada miembro del DAG se encuentra en una subred independiente. Como resultado, el DAG requiere dos direcciones IP, una para cada subred de la red MAPI.

Cada vez que la red MAPI del DAG se extiende en una subred adicional, debe configurarse una dirección IP adicional para dicha subred del DAG. Cada dirección IP configurada para el DAG se asigna al clúster de conmutación por error subyacente del DAG, y éste la usa. El nombre del DAG también se usa como el nombre para el clúster de conmutación por error subyacente.

En cualquier momento específico, el clúster para el DAG usará sólo una de las direcciones IP asignadas. Los clústeres de conmutación por error de Windows registran esta dirección IP en DNS cuando la dirección IP del clúster y los recursos de nombre de red se conectan. Además de usar una dirección IP y un nombre de red, se crea un objeto de la red de clústeres (CNO) en Active Directory. El sistema usa internamente el nombre, la dirección IP y el CNO para el clúster a fin de proteger el DAG y permitir la comunicación interna. Los administradores y los usuarios finales no necesitan conectarse a la dirección IP ni el nombre del DAG, ni usarlos como interfaz.

Dd638104.note(es-ES,EXCHG.141).gifNota:
Si bien el sistema usa internamente el nombre de red y la dirección IP del clúster, no existe una dependencia fuerte de la disponibilidad de dichos recursos en Exchange 2010. Incluso si los recursos de nombre de red y dirección IP del clúster subyacente están desconectados, aún se produce la comunicación interna dentro del DAG mediante el uso de los nombres de servidores del miembro del DAG. Sin embargo, recomendamos que supervise periódicamente la disponibilidad de estos recursos para garantizar que no estén desconectados por más de 30 días. Si el clúster subyacente está desconectado por más de 30 días, es posible que el mecanismo de recolección de elementos no utilizados invalide la cuenta del CNO del clúster en Active Directory.
 Configuración del adaptador de red para DAG

Cada adaptador de red debe configurarse correctamente según su uso previsto. Un adaptador de red usado para una red MAPI tiene una configuración diferente de la del adaptador de red usado para una red de replicación. Además de configurar cada adaptador de red de forma correcta, debe configurar el orden de conexión de red en Windows para que la red MAPI se encuentre al principio en el orden de conexión. Para obtener instrucciones detalladas acerca de cómo modificar el orden de la conexión de red, consulte Modificar el orden de enlaces de protocolo.

 Configuración de adaptador de red MAPI

Un adaptador de red destinado para ser usado por una red MAPI debe configurarse como se describe en la siguiente tabla.

 

Características de red Configuración
Cliente para redes Microsoft Habilitado
Programador de paquetes QoS Habilitar opcionalmente
Uso compartido de impresoras y archivos para redes Microsoft Habilitar
Protocolo de Internet versión 6 (TCP/IP v6) Habilitar opcionalmente
Protocolo de Internet versión 4 (TCP/IP v4) Habilitado
Controlador de E/S del asignador de detección de topologías de nivel de vínculo Habilitado
Respondedor de detección de topologías de nivel de vínculo Habilitado

Las propiedades de TCP/IP v4 para un adaptador de red MAPI se configuran de la siguiente forma:

  • La dirección IP puede configurarse o asignarse manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas persistentes para la dirección IP del servidor.
  • La red MAPI usa habitualmente una puerta de enlace predeterminada, aunque no se requiere una.
  • Se debe configurar al menos una dirección de servidor DNS. Se recomienda el uso de varios servidores DNS para obtener redundancia.
  • La casilla Registrar la dirección de esta conexión en DNS debe estar activada.
 Configuración de adaptador de red de replicación

Un adaptador de red destinado para ser usado por una red de replicación debe configurarse como se describe en la siguiente tabla.

 

Características de red Configuración
Cliente para redes Microsoft Deshabilitado
Programador de paquetes QoS Habilitar opcionalmente
Uso compartido de impresoras y archivos para redes Microsoft Deshabilitado
Protocolo de Internet versión 6 (TCP/IP v6) Habilitar opcionalmente
Protocolo de Internet versión 4 (TCP/IP v4) Habilitado
Controlador de E/S del asignador de detección de topologías de nivel de vínculo Habilitado
Respondedor de detección de topologías de nivel de vínculo Habilitado

Las propiedades de TCP/IP v4 para un adaptador de red de replicación se configuran de la siguiente forma:

  • La dirección IP puede configurarse o asignarse manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas persistentes para la dirección IP del servidor.
  • Las redes de replicación, por lo general, no poseen puertas de enlace predeterminadas; y si la red MAPI cuenta con una, ninguna otra red deberá tener puertas de enlace predeterminadas. El enrutamiento del tráfico de red en una red de replicación puede configurarse mediante el uso de rutas estáticas y persistentes a la red correspondiente en otros miembros del DAG usando direcciones de puerta de enlace con capacidad de enrutamiento entre las redes de replicación. Cualquier otro tráfico que no coincida con esta ruta estará controlado por la puerta de enlace predeterminada configurada en el adaptador para la red MAPI.
  • No deben configurarse las direcciones del servidor DNS.
  • La casilla Registrar la dirección de esta conexión en DNS no debe estar activada.

Volver al principio

 Requisitos de servidor testigo

Un servidor testigo es un servidor externo al DAG que se usa para alcanzar y mantener quórum cuando el DAG cuenta con un número par de miembros. Los DAG con un número impar de miembros no usan un servidor testigo. Todos los DAG con número par de miembros usarán un servidor testigo. El servidor testigo puede ser cualquier equipo que ejecute Windows Server. No es necesario que la versión del sistema operativo Windows Server del servidor testigo coincida con el sistema operativo usado por los miembros del DAG.

Se mantiene el quórum en el clúster, debajo del DAG. Un DAG tiene quórum cuando la mayoría de sus miembros están conectados y pueden comunicarse con los demás miembros conectados del DAG. Esta noción de quórum representa un aspecto del concepto de quórum en los clústeres de conmutación por error de Windows. El recurso de quórum es un aspecto relacionado y necesario del quórum en los clústeres de conmutación por error. El recurso de quórum es un recurso interno del clúster de conmutación por error que ofrece un medio para arbitrar las decisiones de pertenencia y de estado del clúster. El recurso de quórum también proporciona almacenamiento persistente para almacenar información de configuración. Un asistente del recurso de quórum es el registro de quórum, que es una base de datos de configuración para el clúster. Este registro contiene información, como los servidores que forman parte del clúster, los recursos instalados en el clúster y el estado de dichos recursos (por ejemplo, sin están conectados o no).

Es esencial que cada miembro del DAG tenga una vista uniforme de la forma en que está configurado el clúster subyacente del DAG. El quórum actúa como repositorio definitivo de toda la información de configuración relativa al clúster. El quórum se usa también como mecanismo para resolver empates con el fin de evitar el síndrome de “cerebro dividido”. El síndrome de cerebro dividido es una condición que ocurre cuando los miembros del DAG no pueden comunicarse entre ello, pero se encuentran en ejecución. El síndrome de cerebro dividido se evita al requerir la disponibilidad e interacción de una mayoría de los miembros del DAG (y en el caso de los DAG con un número par de miembros, el servidor testigo del DAG) en forma permanente para que el DAG esté en funcionamiento.

 Planificación de resistencia de sitios

Cada día, más y más empresas reconocen que el acceso a un sistema de mensajería confiable y disponible es fundamental para alcanzar el éxito. En muchas organizaciones, el sistema de mensajería forma parte de los planes de continuidad comercial; y la implementación de su servicio de mensajería está diseñada tendiendo en cuenta la resistencia de sitios. Fundamentalmente, varias soluciones de resistencia de sitios implican la implementación de hardware en un centro de datos secundario.

En última instancia, el diseño general de un DAG, incluido el número de miembros del DAG y el número de copias de base de datos de buzones de correo, dependerá de los acuerdos de nivel de servicio (SLA) de recuperación de cada organización que cubren varios escenarios de conmutación por error. Durante la etapa de planificación, los administradores y los arquitectos de la solución identifican los requisitos para la implementación, en especial, los requisitos de resistencia de sitios. Identifican las ubicaciones que se usarán y los destinos requeridos de los acuerdos de nivel de servicio de recuperación. El SLA identificará dos elementos específicos que deben ser la base del diseño de una solución que ofrece alta disponibilidad y resistencia de sitios: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Ambos valores se miden en minutos. El RTO representa el tiempo que se demora en restaurar el servicio. El RPO hace referencia al estado de actualización de los datos después de que se completa la operación de restauración. También puede definirse un SLA para la restauración del centro de datos principal en el servicio completo una vez que se corrigen sus problemas.

Los administradores y los arquitectos de la solución también identificarán el conjunto de usuarios que requerirán protección de resistencia de sitios, y determinarán si la solución de varios sitios tendrá una configuración activa/pasiva o activa/activa. En una configuración activa/pasiva, generalmente, no hay usuarios hospedados en el centro de datos en espera. En una configuración activa/activa, los usuarios se hospedan en ambas ubicaciones, y cierto porcentaje del número total de bases de datos dentro de la solución posee una ubicación activa preferida en un centro de datos secundario. En caso de ocurrir un error en el servicio para los usuarios de un centro de datos, dichos usuarios se activan en el otro centro de datos.

Construir los SLA correspondientes requiere, a menudo, que se respondan las siguientes preguntas básicas:

  • ¿Qué nivel de servicio es necesario en caso de error del centro de datos principal?
  • ¿Los usuarios necesitan los datos o necesitan únicamente los servicios de mensajería?
  • ¿Con qué rapidez se requieren los datos?
  • ¿A cuántos usuarios hay que admitir?
  • ¿Cómo tendrán acceso los usuarios a sus datos?
  • ¿Cuál es el acuerdo de nivel de servicio (SLA) para la activación del centro de datos en espera?
  • ¿Cómo se traslada de nuevo el servicio al centro de datos principal?
  • ¿Están dedicados los recursos a la solución de resistencia de sitios?

Al responder estas preguntas, comenzará a dar forma al diseño de resistencia de sitios de su solución de mensajería. Uno de los requisitos fundamentales para la recuperación ante errores de sitios es crear una solución que envíe los datos necesarios a un centro de datos de copias de seguridad que hospede el servicio de mensajería de copias de seguridad.

 Planificación de espacio de nombres

Exchange 2010 cambia la forma en que se planifica el diseño del espacio de nombres al implementar una configuración de resistencia de sitios. La planificación adecuada del espacio de nombres es esencial para que el cambio de centro de datos se realice correctamente. Desde una perspectiva del espacio de nombres, cada centro de datos usado en una configuración de resistencia de sitios se considera activo. Como resultado, cada centro de datos requerirá su propio espacio de nombres único para los diferentes servicios de Exchange 2010 en dicho sitio, incluidos los espacios de nombres para Outlook Web App, Outlook en cualquier lugar, Exchange ActiveSync, servicios Web Exchange, acceso de cliente de RPC, Protocolo de oficina de correos v.3 (POP3), Protocolo de acceso a mensajes de Internet versión 4 (IMAP4) y Protocolo simple de transferencia de correo (SMTP). Además, uno de los centros de datos aloja también el espacio de nombres de Detección automática. Este diseño también le permite realizar el cambio de una base de datos única del centro de datos principal a un centro de datos secundario para validar la configuración de los datos secundarios como parte de la validación y la práctica de un cambio de centro de datos.

Como procedimiento recomendado, se le sugiere que use la división de DNS para los nombres de host de Exchange usados por los clientes. La división de DNS hace referencia a una configuración del servidor DNS en la que los servidores DNS internos devuelven una dirección IP interna para un nombre de host y los servidores DNS externos (orientados a Internet) devuelven una dirección IP pública para el mismo nombre de host. Debido a que la división de DNS usa los mismos nombres de host tanto interna como externamente, esta estrategia permite minimizar la cantidad de nombres de host que necesitará.

En la figura siguiente, se ilustra la planificación del espacio de nombres para una configuración de resistencia de sitios.

Espacios de nombres para una implementación de DAG de resistencia de sitios

Espacios de nombres para DAG resistente a sitios

Como se muestra anteriormente, cada centro de datos usa un espacio de nombres independiente y único, y cada uno incluye servidores DNS en una configuración de división de DNS para dichos espacios de nombres. El centro de datos Redmond, que se considera el centro de datos principal, está configurado con el espacio de nombres protocolo.contoso.com. El centro de datos Portland está configurado con el espacio de nombres protocolo.enespera.contoso.com. Los espacios de nombres pueden incluir designaciones de “en espera”, como se muestra en la figura de ejemplo, pueden basarse en la región (p. ej., protocolo.portland.contoso.com) o pueden basarse en otras convenciones de nomenclatura que se adapten a las necesidades de su organización. El requisito fundamental es que, independientemente de la convención de nomenclatura que use, cada centro de datos debe tener su propio espacio de nombres.

 Configuración de FailbackURL

Algunos exploradores web, incluido Microsoft Internet Explorer, mantienen una memoria caché de nombres DNS durante las sesiones de exploración que está separada de la memoria caché DNS proporcionada por el sistema operativo. Durante la conmutación por recuperación al centro de datos principal después de que ha ocurrido un cambio, el uso del explorador web de esta memoria caché separada puede resultar en bucles de inicio de sesión para los usuarios de Outlook Web App donde los usuarios son redireccionados a la misma dirección URL en un bucle repetitivo.

Durante el proceso de conmutación por recuperación, la dirección IP del espacio de nombres Outlook Web App se cambia en DNS desde un extremo en el centro de datos en espera nuevamente al extremo original del centro de datos principal. Una vez que el TTL del registro de DNS ha expirado y aun después de que la memoria caché de DNS se ha borrado, los exploradores web que mantienen su propia memoria caché separada pueden continuar conectándose al extremo en el centro de datos en espera, aunque el espacio de nombres esté hospedado en el centro de datos principal.

Generalmente, el cierre del explorador web es suficiente para borrar la memoria caché de nombres separados y evitar los bucles de inicio de sesión. Sin embargo, para mitigar este problema para todos los exploradores web y para todos los usuarios de Outlook Web App, puede configurar la propiedad FailbackURL de su directorio virtual de Outlook Web App. El parámetro FailbackUrl especifica el nombre de host que Outlook Web App usa para conectarse al servidor de acceso de cliente después de que se realiza la conmutación por recuperación en un sitio principal. Este espacio de nombres requiere una entrada DNS separada que apunta a la dirección IP del servidor de acceso de cliente original. El valor del parámetro FailbackUrl debe ser diferente del valor del parámetro ExternalUrl para el directorio virtual de Outlook Web App. Cuando un usuario de Outlook Web App proporciona las credenciales, el servidor de acceso de cliente detecta si la dirección URL es la misma que está visitando el usuario. Si las direcciones URL son las mismas, el servidor de acceso de cliente comprueba si el parámetro FailbackUrl está configurado:

  • Si el parámetro FailbackUrl está configurado, redirecciona el usuario a la dirección URL donde podrían obtener acceso a Outlook Web App.
  • Si el parámetro FailbackUrl no está configurado, el usuario recibe un mensaje de error que indica que el cambio de configuración de un servidor está evitando de manera temporal el acceso a su buzón. Este mensaje indica al usuario que cierre todas las ventanas del explorador (limpiando así la memoria caché del nombre del explorador) y que intente de nuevo en unos pocos minutos.
 Planificación de certificado

No existen consideraciones de diseño especiales ni únicas para los certificados al implementar un DAG en un centro de datos único. Sin embargo, al extender un DAG entre varios centros de datos en una configuración de resistencia de sitios, existen ciertas consideraciones específicas en relación con los certificados. Generalmente, el diseño de su certificado dependerá de los clientes en uso, así como de los requisitos del certificado por parte de otras aplicaciones que usan certificados. Sin embargo, hay algunas recomendaciones específicas y procedimientos recomendados que debe seguir en relación con el tipo y el número de certificados.

Como procedimiento recomendado, debe minimizar la cantidad de certificados que usará para sus servidores de acceso de cliente, servidores proxy inversos y servidores de transporte (perimetral y concentrador). Se recomienda usar un único certificado para todos esos extremos del servicio en cada centro de datos. Este enfoque minimiza la cantidad de certificados necesarios, lo que reduce los costes y la complejidad de la solución.

Para los clientes de Outlook en cualquier lugar, recomendamos que use un certificado con nombre alternativo del sujeto (SAN) único para cada centro de datos e incluya varios nombres de host en el certificado. Para garantizar la conectividad de Outlook en cualquier lugar después de un cambio de base de datos, servidor o centro de datos, debe usar el mismo nombre principal del certificado en cada certificado y configurar el objeto de configuración de proveedor de Outlook en Active Directory con el mismo nombre principal, en el formato estándar de Microsoft (msstd). Por ejemplo, si usa el nombre principal del certificado correo.contoso.com, deberá configurar los atributos de la siguiente forma:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Varias aplicaciones que se integran con Exchange cuentan con requisitos de certificados específicos que pueden exigir el uso de certificados adicionales. Exchange 2010 puede coexistir con Office Communications Server (OCS). OCS requiere certificados con 1024 bits o superiores que usen el nombre del servidor OCS para el nombre principal del certificado. Debido a que el uso de un nombre del servidor OCS para el nombre principal del certificado impedirá el funcionamiento correcto de Outlook en cualquier lugar, deberá usar un certificado adicional e independiente para el entorno del OCS.

Para obtener más información acerca de cómo usar certificados SAN para acceso de cliente de Exchange 2010, consulte Configurar certificados SSL para usar varios nombres de host del servidor de acceso de cliente.

 Planificación de red

Además de los requisitos de red específicos que deben cumplirse para cada DAG, así como para cada servidor miembro del DAG, existen recomendaciones y requisitos específicos para la configuración de resistencia de sitios. Al igual que con todos los DAG, ya sea que los miembros del DAG estén implementados en un sitio único o en varios sitios, la latencia de red de regreso de recorrido de ida y vuelta entre los miembros del DAG no debe ser superior a 500 milisegundos (ms). Además, existen valores de configuración específicos recomendados para los DAG que se extienden a varios sitios:

  • Las redes MAPI deben aislarse de las redes de replicación. Las directivas de red de Windows, las directivas de firewall de Windows o las listas de control de acceso (ACL) del enrutador deben usarse para bloquear el tráfico entre la red MAPI y las redes de replicación. Esta configuración es necesaria para evitar la interferencia de latidos de la red.
  • Los registros DNS orientados al cliente deben tener un período de vida (TTL) de 5 minutos. La cantidad de tiempo de inactividad que experimentan los clientes depende no sólo de la rapidez con la que puede ocurrir un cambio, sino también de la rapidez con la que ocurre la replicación de DNS y la rapidez con la que los clientes consultan la información DNS actualizada. Los registros DNS de todos los servicios de cliente de Exchange, incluidos Outlook Web App, Exchange ActiveSync, servicios Web Exchange, Outlook en cualquier lugar, SMTP, POP3, IMAP4 y acceso de cliente de RPC en servidores DNS internos y externos, deben configurarse con un TTL de 5 minutos.
  • Uso de rutas estáticas para configurar la conectividad entre las redes de replicación. Para proporcionar conectividad de red entre cada uno de los adaptadores de la red de replicación, use rutas estáticas persistentes. Ésta es una configuración única y rápida que se realiza en cada miembro del DAG al usar direcciones IP estáticas. Si usa DHCP a fin de obtener direcciones IP para sus redes de replicación, también puede usarlo para asignar rutas estáticas para la replicación; de esta manera, se simplifica el proceso de configuración.
 Planificación general de resistencia de sitios

Además de los requisitos mencionados anteriormente para alta disponibilidad, existen otras recomendaciones para la implementación de Exchange 2010 en una configuración de resistencia de sitios (p. ej., extender un DAG a varios centros de datos). Lo que realice durante la fase de planificación tendrá un impacto directo en el éxito de su solución de resistencia de sitios. Por ejemplo, un diseño de espacio de nombres deficiente puede causar dificultades con los certificados, y una configuración de certificados incorrecta puede impedir que los usuarios obtengan acceso a los servicios.

Para minimizar el tiempo que demora la activación de un centro de datos secundario y permitir que éste aloje los extremos del servicio de un centro de datos que falló, debe realizarse la planificación adecuada. Por ejemplo:

  • Los objetivos del acuerdo de nivel de servicio (SLA) para la solución de resistencia de sitios debe comprenderse y documentarse correctamente.
  • Los servidores en el centro de datos secundario deben tener la capacidad suficiente para alojar la población de usuarios combinada de ambos centros de datos.
  • El centro de datos secundario debe tener habilitados todos los servicios suministrados en el centro de datos principal (excepto que el servicio no esté incluido como parte del SLA de resistencia de sitios). Esto incluye Active Directory, infraestructura de red (DNS, TCP/IP, etc.), servicios de telefonía (si está en uso la mensajería unificada) e infraestructura del sitio (energía, refrigeración, etc.).
  • A fin de que ciertos servicios puedan brindarse a los usuarios desde el centro de datos donde se produjo un error, deben tener configurados los certificados del servidor correctos. Ciertos servicios no permiten la instanciación (por ejemplo, POP3 e IMAP4) y sólo permiten el uso de un certificado único. En dichos casos, el certificado debe ser un certificado con nombre alternativo del sujeto (SAN) que incluya varios nombres, o los diferentes nombres deben ser lo suficientemente similares para que pueda usarse un certificado comodín (suponiendo que las directivas de seguridad de la organización permiten el uso de certificados comodín).
  • Deben definirse los servicios necesarios en el centro de datos secundario. Por ejemplo, si el primer centro de datos tiene tres direcciones URL de SMTP distintas en diferentes servidores de transporte, debe definirse la configuración apropiada en el centro de datos secundario para habilitar al menos un servidor de transporte (si no se habilitan los tres) para alojar la carga de trabajo.
  • Debe haberse realizado la configuración de red necesaria para admitir el cambio de centro de datos. Esto podría significar que debe asegurarse de que la configuración del equilibrio de carga se haya realizado, el DNS global esté configurado y la conexión a Internet esté habilitada con la configuración de enrutamiento apropiada.
  • Debe comprenderse la estrategia para permitir los cambios de DNS necesarios a fin de realizar un cambio de centro de datos. Los cambios de DNS específicos, incluidos los valores del período de vida (TTL), deben definirse y documentarse para admitir los SLA vigentes.
  • También debe establecerse e incluirse en el SLA una estrategia para probar la solución. La validación periódica de la implementación es la única forma de garantizar que la calidad y la viabilidad de la implementación no se perderán con el tiempo. Recomendamos que, una vez validada la implementación, se documente explícitamente la parte de la configuración que afecte de manera directa el éxito de la solución. Asimismo, recomendamos que mejore los procesos de administración de cambios en relación con dichos segmentos de la implementación.

Volver al principio

 Planificación de cambios de centro de datos

La planificación y la preparación adecuadas requieren la implementación de los recursos del centro de datos secundario, como los servidores de transporte de concentradores y de acceso de cliente, y la configuración previa de dichos recursos para minimizar los cambios necesarios como parte de una operación de cambio de centro de datos.

Dd638104.note(es-ES,EXCHG.141).gifNota:
Los servicios de transporte de concentradores y de acceso de cliente son necesarios en el centro de datos secundario, incluso cuando está bloqueada la activación automática de las bases de datos de buzones de correo en el centro de datos secundario. Dichos servicios son necesarios para realizar cambios de bases de datos, y para realizar pruebas y validaciones de los servicios y los datos en el centro de datos secundario.

Para comprender mejor la forma en que funciona el proceso de cambio de un centro de datos, es útil entender el funcionamiento básico de un cambio de centro de datos de Exchange 2010.

Como se ilustra en la siguiente figura, una implementación de resistencia de sitios incluye un DAG que cuenta con miembros en ambos centros de datos.

Grupo de disponibilidad de base de datos con miembros en dos centros de datos
Grupo de disponibilidad de base de datos en dos sitios

Cuando se extiende un DAG entre varios centros de datos, éste debe estar diseñado de forma que la mayoría de los miembros del DGA se ubiquen en el centro de datos principal o que, cuando cada centro de datos tenga el mismo número de miembros, el centro de datos principal aloje el servidor testigo. Este diseño garantiza que el servicio se suministrará en el centro de datos principal, incluso si la conectividad de red entre los dos centros de datos falla. Sin embargo, también implica que, cuando el centro de datos principal falle, se perderá el quórum de los miembros del centro de datos secundario.

Los errores parciales en el centro de datos también son posibles, y ocurrirán. Se presupone que si se pierde suficiente funcionalidad en el centro de datos principal como para impedir el servicio y la administración adecuados, debe realizarse un cambio de centro de datos para activar el centro de datos secundario. El proceso de activación implica la interrupción del servicio por parte del administrador que realiza la configuración de los servidores subsistentes con estado de funcionamiento parcial. A continuación, la activación puede continuar en el centro de datos secundario. Esto se realiza para impedir que ambos tipos de servicio intenten funcionar al mismo tiempo.

Como resultado de la pérdida de quórum, los miembros del DAG del centro de datos secundario no pueden conectarse automáticamente. Por lo tanto, la activación de los servidores de buzones del centro de datos secundario también requiere un paso en el que los servidores miembros del DAG sean forzados a crear quórum; en este punto, los servidores del centro de datos donde se produjo un error se quitan del DAG (sólo de manera temporal). Esto ofrece una solución de servicio parcial, que es estable y susceptible de experimentar cierto nivel de errores adicionales, y que aún continúa funcionando.

Dd638104.note(es-ES,EXCHG.141).gifNota:
Un requisito previo de experimentar errores adicionales es que el DAG cuente, al menos, con cuatro miembros, y que los cuatro miembros estén distribuidos en dos sitios de Active Directory (p. ej., al menos dos miembros en cada centro de datos).

Éste es el proceso básico usado para volver a establecer la funcionalidad de la función del buzón en el centro de datos secundario. La activación de las demás funciones en el centro de datos secundario no implica acciones explícitas en los servidores afectados del centro de datos secundario. En cambio, los servidores del centro de datos secundario se convierten en los extremos del servicio para aquellos servicios habitualmente alojados en el centro de datos principal. Por ejemplo, un usuario alojado normalmente en el centro de datos principal podría usar https://mail.contoso.com/owa para conectarse a Outlook Web App. Después de que se produce el error en el centro de datos, dichos extremos del servicio se trasladan a los extremos del centro de datos secundario como parte de la operación de cambio. Durante la operación de cambio, los extremos del servicio del centro de datos principal se redirigen a direcciones IP alternativas para los mismos servicios en el centro de datos secundario. Esto minimiza el número de cambios que deben realizarse en la información de configuración almacenada en Active Directory durante el proceso de cambio. Por lo general, hay dos formas de completar este paso:

  • Actualizar los registros DNS o
  • Volver a configurar el DNS y el/los equilibrador(es) de carga para habilitar y deshabilitar las direcciones IP alternativas, moviendo así los servicios entre los centros de datos.

Se debe establecer una estrategia para probar la solución. Debe tenerse en cuenta en el SLA. La validación periódica de la implementación es la única forma de garantizar que la implementación no se perderá con el tiempo.

La finalización cuidadosa de estos pasos de planificación tendrá un impacto directo en el éxito del cambio de un centro de datos. Por ejemplo, un diseño de espacio de nombres deficiente puede causar dificultades con los certificados, y una configuración de certificados incorrecta puede impedir que los usuarios obtengan acceso a los servicios.

Recomendamos que, una vez validada la implementación, se documenten explícitamente todas las partes de la configuración que afecten de manera directa el éxito de un cambio de centro de datos. Asimismo, puede ser prudente mejorar los procesos de administración de cambios en relación con dichos segmentos de la implementación.

Puertos de red de Exchange Server 2010

Puertos de red de Exchange Server 2010

En este tema se proporciona información sobre puertos, autenticación y cifrado para todas las rutas de datos que usa Microsoft Exchange Server 2010. En la sección Notas que sigue a cada tabla se aclaran o se definen la autenticación no estándar o los métodos de cifrado.

 Servidores de transporte

 

Exchange 2010 incluye dos roles de servidor que realizan la tarea de transportar mensajes: el servidor de transporte de concentradores y el servidor de transporte perimetral

En la tabla siguiente se ofrece información sobre puertos, autenticación y cifrado de rutas de datos entre estos servidores de transporte, así como de otros servidores y servicios de Exchange 2010.

Rutas de datos de servidores de transporte

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?
De servidor de transporte perimetral a servidor de transporte perimetral 25/TCP (SMTP) Kerberos Kerberos Sí, mediante la Seguridad de la capa de transporte (TLS)
De servidor de transporte de concentradores a servidor de transporte perimetral 25/TCP (SMTP) Confianza directa Confianza directa Sí, mediante TLS
De servidor de transporte perimetral a servidor de transporte de concentradores 25/TCP (SMTP) Confianza directa Confianza directa Sí, mediante TLS
De servidor de transporte perimetral a servidor de transporte perimetral 25/TCP SMTP Anónimo, Certificado Anónimo, Certificado Sí, mediante TLS
De servidor de buzones a servidor de transporte perimetral a través del Servicio de entrega de correo de Microsoft Exchange 135/TCP (RPC) NTLM. Si las funciones del servidor Transporte de concentradores y Buzón de correo están en el mismo servidor, se usa Kerberos. NTLM/Kerberos Sí, mediante cifrado RPC
De servidor de transporte de concentradores a servidor de buzones a través de MAPI 135/TCP (RPC) NTLM. Si las funciones del servidor Transporte de concentradores y Buzón de correo están en el mismo servidor, se usa Kerberos. NTLM/Kerberos Sí, mediante cifrado RPC
De servidor de mensajería unificada a servidor Transporte de concentradores 25/TCP (SMTP) Kerberos Kerberos Sí, mediante TLS
Servicio Microsoft Exchange EdgeSync de servidor Transporte de concentradores a servidor Transporte perimetral 50636/TCP (SSL) Básico Básico Sí, mediante LDAP sobre SSL (LDAPS)
Acceso a Active Directory desde el servidor Transporte de concentradores 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
Acceso a Active Directory Rights Management Services (AD RMS) desde un servidor Transporte de concentradores 443/TCP (HTTPS) NTLM/Kerberos NTLM/Kerberos Sí, mediante SSL Sí*
De clientes SMTP a servidor Transporte de concentradores (por ejemplo, usuarios finales que usan Windows Live Mail) 587 (SMTP)

25/TCP (SMTP)

NTLM/Kerberos NTLM/Kerberos Sí, mediante TLS
 Notas sobre servidores de transporte
  • Todo el tráfico entre los servidores Transporte de concentradores está cifrado mediante TLS con certificados autofirmados que se instalan durante el proceso de instalación de Exchange 2010.
    Bb331973.note(es-ES,EXCHG.141).gifNota:
    En Exchange 2010, se puede deshabilitar el servicio TLS en servidores Transporte de concentradores cuando se produce comunicación SMTP interna con otros servidores Transporte de concentradores en la misma organización de Exchange. No se recomienda hacerlo a menos que sea absolutamente necesario. Para obtener más información, consulte Deshabilitar TLS entre sitios de Active Directory para permitir la optimización de WAN.
  • Todo el tráfico entre servidores de transporte perimetral y servidores de transporte de concentradores está autenticado y cifrado. La autenticación TLS mutua es el mecanismo subyacente de autenticación y cifrado. En lugar de usar la validación X.509, Exchange 2010 usa la confianza directa para autenticar los certificados. Confianza directa significa que el certificado queda validado por su presencia en Active Directory o Active Directory Lightweight Directory Services (AD LDS). Active Directory se considera un mecanismo de almacenamiento de confianza. Si se usa la confianza directa, da igual que el certificado tenga una firma personal o esté firmado por una entidad de certificación. Al suscribir un servidor de transporte perimetral a la organización de Exchange, la suscripción perimetral publica el certificado del servidor de transporte perimetral en Active Directory para que se validen los servidores de transporte de concentradores. El servicio Microsoft Exchange Edgesync actualiza AD LDS con el conjunto de certificados de servidor Transporte de concentradores para que lo valide el servidor Transporte perimetral.
  • EdgeSync usa una conexión LDAP segura entre el servidor Transporte de concentradores y los servidores Transporte perimetral suscritos a través de TCP 50636. AD LDS también escucha en TCP 50389. Las conexiones a este puerto no usan SSL. Puede usar las utilidades LDPA para conectarse al puerto y comprobar los datos AD LDS.
  • De forma predeterminada, el tráfico entre los servidores de transporte perimetral en dos organizaciones diferentes está cifrado. La instalación de Exchange 2010 crea un certificado autofirmado y la TLS se activa de forma predeterminada. Esto permite a cualquier sistema de envío cifrar la sesión SMTP entrante para Exchange. De forma predeterminada, Exchange 2010 intenta también la TLS para todas las conexiones remotas.
  • Los métodos de autenticación para el tráfico entre servidores Transporte de concentradores y los servidores de buzones de correo difieren cuando los roles de servidor Transporte de concentradores y los roles de servidor Buzón de correo están instalados en el mismo equipo. Cuando la entrega de correo es local, se usa la autenticación Kerberos. Cuando la entrega de correo es remota, se usa la autenticación NTLM.
  • Exchange 2010 admite también la seguridad de dominio. La seguridad de dominio se refiere al conjunto de funcionalidades de Exchange 2010 y Microsoft Outlook 2010 que proporciona una alternativa económica a S/MIME u otras soluciones de seguridad para mensajes en Internet. La seguridad de dominio proporciona un modo de administrar rutas de mensajes seguras entre dominios en Internet. Una vez configuradas estas rutas de mensajes seguras, los mensajes que han viajado correctamente a través de la ruta segura desde un remitente autenticado se muestran a los usuarios de Outlook y Outlook Web Access como “dominio seguro”. Para obtener más información, consulte Descripción de la seguridad de dominio.
  • Muchos agentes pueden ejecutarse en servidores Transporte de concentradores y servidores Transporte perimetral. Normalmente, los agentes contra correo no deseado confían en la información local del equipo en el que se ejecutan los agentes. Por lo tanto, se requiere poca comunicación con los equipos remotos. El filtrado de destinatarios es la excepción. El filtrado de destinatarios requiere llamadas a AD LDS o Active Directory. Se recomienda ejecutar el filtrado de destinatarios en el servidor Transporte perimetral. En este caso, el directorio AD LDS está en el mismo equipo que el servidor Transporte perimetral, por lo que no se requiere una comunicación remota. Una vez que se ha instalado y configurado el filtrado de destinatarios en el servidor de transporte de concentradores, el filtrado de destinatarios obtiene acceso a Active Directory.
  • La característica de reputación del remitente de Exchange 2010 usa el agente de análisis de protocolo. Este agente realiza también varias conexiones a servidores proxy externos para determinar las rutas de mensajes entrantes para conexiones sospechosas.
  • Todas las demás funciones contra correo electrónico no deseado usan datos recopilados, almacenados y a los que se obtiene acceso sólo en el equipo local. Con frecuencia, los datos como la agregación de listas seguras o los datos de destinatarios para el filtrado de destinatarios, se trasladan al directorio de AD LDS local mediante el servicio Microsoft Exchange EdgeSync.
  • Los agentes de Information Rights Management (IRM) en servidores Transporte de concentradores establecen conexiones con los servidores de Active Directory Rights Management Services (AD RMS) de la organización. AD RMS es un servicio web protegido mediante SSL, que se considera la mejor solución. La comunicación con los servidores AD RMS se produce a través de HTTPS, y se usa autenticación Kerberos o NTLM, según la configuración del servidor AD RMS.
  • Las reglas de diario, las reglas de transporte y las clasificaciones de mensajes se almacenan en Active Directory y pueden acceder a ellas el agente de registro en diario y el agente de reglas de transporte de los servidores Transporte de concentradores.
 Servidores de buzones de correo

 

El hecho de que se use autenticación NTLM o Kerberos para servidores de buzones de correo depende del usuario o del contexto del proceso en el que se esté ejecutando el cliente del nivel de lógica de negocios de Exchange. En este contexto, se denomina cliente a cualquier aplicación o proceso que usa el nivel de lógica de negocios de Exchange. Por lo tanto, en muchas de las entradas de la columna Autenticación predeterminada de la tabla Rutas de datos de servidores de buzones aparece NTLM/Kerberos.

El nivel empresarial lógico de Exchange se usa para obtener acceso a y comunicarse con el almacén de Exchange. El nivel empresarial lógico de Exchange también se llama desde el almacén de Exchange para comunicarse con aplicaciones y procesos externos.

Si el cliente del nivel empresarial lógico de Exchange se está ejecutando como sistema local, el método de autenticación siempre es Kerberos desde el cliente hasta el almacén de Exchange. Se usa Kerberos porque el cliente debe ser autenticado mediante la cuenta de equipo de sistema local y debe existir una confianza autenticada bidireccional.

Si el cliente del nivel de lógica de negocios de Exchange no se está ejecutando como sistema local, el método de autenticación es NTLM. Por ejemplo, se usa NTLM cuando se ejecuta un cmdlet del Shell de administración de Exchange que usa el nivel de lógica de negocios de Exchange.

El tráfico RPC siempre está cifrado.

En la tabla siguiente se ofrece información acerca de puertos, autenticación y cifrado para rutas de datos, así como para y desde servidores de buzones.

Rutas de datos de servidores de buzones

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?
Acceso de Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
Acceso remoto de administrador (Registro remoto) 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante IPsec No
Acceso remoto de administrador (SMB/archivo) 445/TCP (SMB) NTLM/Kerberos NTLM/Kerberos Sí, mediante IPsec No
Servicio de Web de disponibilidad (Acceso de cliente a buzón) 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
Organización por clústeres 135/TCP (RPC) Consulte el tema Notas sobre servidores de buzones tras esta tabla. NTLM/Kerberos NTLM/Kerberos Sí, mediante IPsec No
Indización de contenido 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
Trasvase de registros 64327 (personalizable) NTLM/Kerberos NTLM/Kerberos No
Inicialización 64327 (personalizable) NTLM/Kerberos NTLM/Kerberos No
Copia de seguridad de Servicio de instantáneas de volumen (VSS) Bloqueo de mensajes local (SMB) NTLM/Kerberos NTLM/Kerberos No No
Asistentes de buzones 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos No No
Acceso MAPI 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
Acceso de servicio de topología de Microsoft Exchange Active Directory 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
Acceso heredado de servicio Operador de sistema de Microsoft Exchange (escuchar las convocatorias) 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos No No
Acceso heredado de servicio Operador de sistema de Microsoft Exchange para Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
Acceso heredado de servicio Operador de sistema de Microsoft Exchange (como cliente MAPI) 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
Libreta de direcciones sin conexión (OAB) que accede a Active Directory 135/TCP (RPC) Kerberos Kerberos Sí, mediante cifrado RPC
Acceso de servicio de actualización de destinatarios RPC 135/TCP (RPC) Kerberos Kerberos Sí, mediante cifrado RPC
Actualización de destinatarios para Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
 Notas sobre servidores de buzones
  • La ruta de datos de clúster que aparece en la tabla anterior usa RPC dinámico a través de TCP para comunicar el estado del clúster y la actividad entre los diferentes nodos del clúster. El servicio de clúster (ClusSvc.exe) usa también UDP/3343 y puertos TCP superiores asignados aleatoriamente para comunicarse entre nodos de clústeres.
  • Para comunicaciones entre nodos, los nodos en clúster se comunican a través de Protocolo de datagramas de usuario (UDP) puerto 3343. Cada nodo del clúster cambia periódicamente los datagramas UDP de unidifusión secuenciados con todos los demás nodos del clúster. El propósito de este cambio es determinar si todos los nodos se están ejecutando correctamente y supervisar el estado de los vínculos de red.
  • El puerto 64327/TCP es el puerto predeterminado que se usa para el trasvase de registros. Los administradores pueden especificar un puerto diferente para el trasvase de registros.
  • Para la autenticación HTTP en la que se indica Negociar, en primer lugar se intenta Kerberos y, a continuación, NTLM.
 Servidores de acceso de cliente

 

A no ser que se indique, las tecnologías de acceso de cliente, tales como Outlook Web App, POP3 o IMAP4, se describen mediante la autenticación y cifrado de la aplicación cliente al servidor de acceso de cliente.

En la tabla siguiente se ofrece información acerca del puerto, la autenticación y el cifrado para rutas de datos entre servidores de acceso de cliente y otros servidores y clientes.

Rutas de datos del servidor de acceso de cliente

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?
Acceso de Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
Servicio Detección automática 80/TCP, 443/TCP (SSL) Autenticación de Windows integrada/básica (Negociar) Básico, Digest, NTLM, Negociar (Kerberos) Sí, mediante HTTPS
Servicio de disponibilidad 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM, Kerberos Sí, mediante HTTPS
Outlook que accede a OAB 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM/Kerberos Sí, mediante HTTPS No
Outlook Web App 80/TCP, 443/TCP (SSL) Autenticación basada en formularios Básico, Digest, Autenticación basada en formularios, NTLM (sólo v2), Kerberos, Certificar Sí, mediante HTTPS Sí, mediante un certificado autofirmado
POP3 110/TCP (TLS), 995/TCP (SSL) Básica, Kerberos Básica, Kerberos Sí, mediante SSL, TLS
IMAP4 143/TCP (TLS), 993/TCP (SSL) Básica, Kerberos Básica, Kerberos Sí, mediante SSL, TLS
Outlook en cualquier lugar (conocido anteriormente como RPC sobre HTTP) 80/TCP, 443/TCP (SSL) Básico Básico o NTLM Sí, mediante HTTPS
Aplicación de Exchange ActiveSync 80/TCP, 443/TCP (SSL) Básico Básico, Certificar Sí, mediante HTTPS
De servidor de acceso de cliente a servidor de mensajería unificada 5060/TCP, 5061/TCP, 5062/TCP, un puerto dinámico Mediante dirección IP Mediante dirección IP Sí, mediante Protocolo de inicio de sesión (SIP) sobre TLS
De servidor de acceso de cliente a un servidor de buzones que ejecute una versión anterior de Exchange Server 80/TCP, 443/TCP (SSL) NTLM/Kerberos Negociar (Kerberos con retroceso a NTLM o Básico opcionalmente,) POP/IMAP texto sin formato Sí, mediante IPsec No
De servidor de acceso de cliente a servidor de buzones de correo de Exchange 2010 RPC. Consulte Notas sobre servidores de acceso de cliente. Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
De servidor de acceso de cliente a servidor de acceso de cliente (Exchange ActiveSync) 80/TCP, 443/TCP (SSL) Kerberos Kerberos, Certificar Sí, mediante HTTPS Sí, mediante un certificado autofirmado
De servidor de acceso de cliente a servidor de acceso de cliente (Outlook Web Access) 80/TCP, 443/TCP (HTTPS) Kerberos Kerberos Sí, mediante SSL
De servidor de acceso de cliente a servidor de acceso de cliente (servicios web de Exchange) 443/TCP (HTTPS) Kerberos Kerberos Sí, mediante SSL
De servidor de acceso de cliente a servidor de acceso de cliente (POP3) 995 (SSL) Básico Básico Sí, mediante SSL
De servidor de acceso de cliente a servidor de acceso de cliente (IMAP4) 993 (SSL) Básico Básico Sí, mediante SSL
Acceso de Office Communications Server al servidor de acceso de cliente (si está habilitada la integración de Office Communications Server y Outlook Web App) 5075-5077/TCP (entrada), 5061/TCP (salida) mTLS (requerido) mTLS (requerido) Sí, mediante SSL
Bb331973.note(es-ES,EXCHG.141).gifNota:
La autenticación integrada de Windows (NTLM) no es compatible con la conectividad de cliente POP3 o IMAP4. Para obtener más información, consulte las secciones “Características de acceso de cliente” en Características suprimidas y funciones que ya no destacan.
 Notas sobre servidores de acceso de cliente
  • En Exchange 2010, los clientes MAPI como Microsoft Outlook se conectan a servidores de acceso de cliente.
  • Los servidores de acceso de cliente usan muchos puertos para comunicarse con servidores de buzones de correo. Con algunas excepciones, estos puertos los determina el servicio RPC y no son fijos.
  • Para la autenticación HTTP en la que se indica Negociar, en primer lugar se intenta Kerberos y, a continuación, NTLM.
  • Cuando un servidor de acceso de cliente de Exchange 2010 se comunica con un servidor de buzones de correo que ejecuta Exchange Server 2003, se recomienda usar Kerberos y deshabilitar la autenticación NTLM y la autenticación básica. Asimismo, se recomienda configurar Outlook Web App para que use autenticaciones basadas en formularios con un certificado de confianza. Para que los clientes de Exchange ActiveSync se comuniquen a través del servidor de acceso de cliente de Exchange 2010 con el servidor back-end de Exchange 2003, la autenticación integrada de Windows debe estar habilitada en el directorio virtual Microsoft-Server-ActiveSync del servidor back-end de Exchange 2003. Para usar el Administrador del sistema de Exchange en un servidor de Exchange 2003 para administrar la autenticación en un directorio virtual de Exchange 2003, descargue e instale la revisión a la que se hace referencia en el artículo 937031 de Microsoft Knowledge Base, El identificador de evento 1036 está registrado en un servidor de Exchange 2007 que ejecuta la directiva de seguridad de acceso al código (CAS) cuando los dispositivos móviles se conectan al servidor de Exchange 2007 para obtener acceso a los buzones de correo de un servidor back-end de Exchange 2003.
    Bb331973.note(es-ES,EXCHG.141).gifNota:
    Aunque el artículo de Knowledge Base se refiere específicamente a Exchange 2007, también es aplicable a Exchange 2010.
  • Cuando un servidor de acceso de cliente manda solicitudes POP3 a otro servidor de acceso de cliente, la comunicación se realiza a través del puerto 995/TCP, al margen de si el cliente que se conecta usa POP3 y solicita TLS (en el puerto 110/TCP) o se conecta al puerto 995/TCP mediante SSL. De forma similar, en el caso de conexiones IMAP4, se usa el puerto 993/TCP para mandar solicitudes, al margen de si el cliente que se conecta usa IMAP4 y solicita TLS (en el puerto 443/TCP) o se conecta al puerto 995 mediante IMAP4 con cifrado SSL.
 Servidores de mensajería unificada

 

Las puertas de enlace IP PBX solo admiten la autenticación basada en certificados que use TLS mutua para el cifrado de tráfico SIP y autenticación basada en IP para conexiones del Protocolo de inicio de sesión (SIP)/TCP. Las puertas de enlace IP no admiten la autenticación NTLM ni Kerberos. Por lo tanto, cuando use una autenticación basada en IP, se usa la dirección o direcciones IP de conexión para ofrecer un mecanismo de autenticación para conexiones (TCP) no cifradas. Cuando se usa una autenticación basada en IP en mensajería unificada, el servidor de mensajería unificada comprueba que la dirección IP tiene permiso para conectarse. La dirección IP se configura en la puerta de enlace IP o en la IP PBX.

Las puertas de enlace IP y IP PBX admiten autenticación TLS mutua para cifrar el tráfico SIP. Una vez que haya importado y exportado correctamente los certificados de confianza necesarios, la puerta de enlace IP o IP PBX solicitará un certificado al servidor de mensajería unificada, que a su vez solicitará un certificado a la puerta de enlace IP o IP PBX. El intercambio de certificados de confianza entre la puerta de enlace IP o IP PBX y el servidor de mensajería unificada permite que la puerta de enlace IP o IP PBX y el servidor de mensajería unificada se comuniquen a través de una conexión cifrada mediante autenticación TLS mutua.

En la tabla siguiente se ofrece información acerca del puerto, la autenticación y el cifrado de rutas de datos entre servidores de mensajería unificada y otros servidores.

Rutas de datos de los servidores de mensajería unificada

Ruta de datos Puertos necesarios Autenticación predeterminada Autenticación admitida ¿Se admite el cifrado? ¿Se cifra de forma predeterminada?
Acceso de Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) Kerberos Kerberos Sí, mediante cifrado Kerberos
Interacción telefónica de mensajería unificada (IP/PBX VoIP Gateway) 5060/TCP , 5065/TCP, 5067/TCP (no seguros), 5061/TCP, 5066/TCP, 5068/TCP (seguros), un intervalo de puerto dinámico 16000-17000/TCP (control), puertos UDP dinámicos del intervalo 1024-65535/UDP (RTP) Mediante dirección IP Mediante dirección IP, MTLS Sí, mediante SIP/TLS, SRTP No
Servicio Web de mensajería unificada 80/TCP, 443/TCP (SSL) Autenticación de Windows integrada (Negociar) Básico, Digest, NTLM, Negociar (Kerberos) Sí, mediante SSL
De servidor de mensajería unificada a servidor de acceso de cliente 5075, 5076, 5077 (TCP) Autenticación integrada de Windows (Negociar) Básico, Digest, NTLM, Negociar (Kerberos) Sí, mediante SSL
De servidor de mensajería unificada a servidor de acceso de cliente (Reproducir en teléfono) RPC dinámica NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
De servidor de mensajería unificada a servidor Transporte de concentradores 25/TCP (TLS) Kerberos Kerberos Sí, mediante TLS
De servidor de mensajería unificada a servidor de buzones 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Sí, mediante cifrado RPC
 Notas sobre servidores de mensajería unificada
  • Cuando cree un objeto de puerta de enlace IP de mensajería unificada (UM) en Active Directory, debe definir la dirección IP de la puerta de enlace IP física o IP PBX (central de conmutación). Cuando defina la dirección IP en el objeto de puerta de enlace IP de mensajería unificada, la dirección IP se agrega a una lista de puertas de enlace IP válidas o IP PBX (también denominadas interlocutores SIP) con las que puede comunicarse el servidor de mensajería unificada. Cuando se crea una puerta de enlace IP de mensajería unificada, se puede asociar a un plan de marcado de mensajería unificada. La asociación de la puerta de enlace IP de mensajería unificada con un plan de marcado permite a los servidores de mensajería unificada asociados con el plan de marcado usar la autenticación basada en IP para comunicarse con la puerta de enlace IP. Si la puerta de enlace IP de mensajería unificada no se ha creado o no está configurada para usar la dirección IP correcta, se produce un error de autenticación y los servidores de mensajería unificada no aceptan conexiones desde esa dirección IP de la puerta de enlace IP. Además, cuando se implementa la autenticación TLS mutua, una puerta de enlace IP o IP PBX y servidores de mensajería unificada, la puerta de enlace IP de mensajería unificada debe configurarse usando el nombre de dominio completo (FQDN). Tras configurar una puerta de enlace de mensajería unificada con un FQDN, deberá agregar también un registro de host a la zona de búsqueda directa de DNS para dicha puerta.
  • En Exchange 2010, un servidor de mensajería unificada se puede comunicar en el puerto 5060/TCP (no seguro) o en el puerto 5061/TCP (seguro) y, a continuación, configurarse para usar ambos puertos.

Para obtener más información, consulte Descripción de la seguridad de la mensajería unificada VoIP y Descripción de protocolos, puertos y servicios de mensajería unificada.

 Reglas de Firewall de Windows creadas por el programa de instalación de Exchange 2010

 

El Firewall de Windows con seguridad avanzada es un firewall con estado y basado en host que filtra el tráfico entrante y saliente según las reglas del firewall. El programa de instalación de Exchange 2010 crea las reglas del Firewall de Windows para abrir los puertos necesarios para la comunicación entre servidor y cliente en cada rol de servidor. Por lo tanto, ya no necesita usar el asistente para configuración de seguridad (SCW) para configurar estos parámetros. Para obtener más información sobre el Firewall de Windows con seguridad avanzada, vea Firewall de Windows con seguridad avanzada e IPsec.

En esta tabla se muestran las reglas de Firewall de Windows que se crean durante la instalación de Exchange, incluidos los puertos que se abren en cada rol de servidor. Puede ver estas reglas si una el Firewall de Windows con un complemento MMC de seguridad avanzada.

 

Nombre de regla Roles de servidor Puerto Programa
MSExchangeADTopology – RPC (TCP-In) Acceso de clientes, Transporte de concentradores, Buzón de correo, Mensajería unificada RPC dinámica Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring – RPC (TCP-In) Acceso de clientes, Transporte de concentradores, Transporte perimetral, Mensajería unificada RPC dinámica Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost – RPC (TCP-In) Todos los roles RPC dinámica Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost – RPCEPMap (TCP-In) Todos los roles RPC-EPMap Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP-In) Todos los roles RPC-EPMap Cualquiera
MSExchangeRPC (GFW) (TCP-In) Acceso de clientes, Transporte de concentradores, Buzón de correo, Mensajería unificada RPC dinámica Cualquiera
MSExchange – IMAP4 (GFW) (TCP-In) Acceso de clientes 143, 993 (TCP) Todos
MSExchangeIMAP4 (TCP-In) Acceso de clientes 143, 993 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange – POP3 (FGW) (TCP-In) Acceso de clientes 110, 995 (TCP) Todos
MSExchange – POP3 (TCP-In) Acceso de clientes 110, 995 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange – OWA (GFW) (TCP-In) Acceso de clientes 5075, 5076, 5077 (TCP) Todos
MSExchangeOWAAppPool (TCP-In) Acceso de clientes 5075, 5076, 5077 (TCP) Inetsrv\w3wp.exe
MSExchangeAB-RPC (TCP-In) Acceso de clientes RPC dinámica Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RPCEPMap (TCP-In) Acceso de clientes RPC-EPMap Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP-In) Acceso de clientes 6002, 6004 (TCP) Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP-In) Acceso de clientes RPC dinámica System32\Svchost.exe
MSExchangeRPC – RPC (TCP-In) Acceso de clientes, Buzón de correo RPC dinámica Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC – PRCEPMap (TCP-In) Acceso de clientes, Buzón de correo RPC-EPMap Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP-In) Acceso de clientes, Buzón de correo 6001 (TCP) Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP-In) Acceso de clientes 808 (TCP) Cualquiera
MSExchangeMailboxReplication (TCP-In) Acceso de clientes 808 (TCP) Bin\MSExchangeMailboxReplication.exe
MSExchangeIS – RPC (TCP-In) Buzón de correo RPC dinámica Bin\Store.exe
MSExchangeIS RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\Store.exe
MSExchangeIS (GFW) (TCP-In) Buzón de correo 6001, 6002, 6003, 6004 (TCP) Cualquiera
MSExchangeIS (TCP-In) Buzón de correo 6001 (TCP) Bin\Store.exe
MSExchangeMailboxAssistants – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailboxAssistants – RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSExchangeMailSubmission.exe
MSExchangeMailSubmission – RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSExchangeMailSubmission.exe
MSExchangeMigration – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSExchangeMigration.exe
MSExchangeMigration – RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSExchangeMigration.exe
MSExchangerepl – Copiadora de registros (TCP-In) Buzón de correo 64327 (TCP) Bin\MSExchangeRepl.exe
MSExchangerepl – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSExchangeRepl.exe
MSExchangerepl – RPC-EPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSExchangeRepl.exe
MSExchangeSearch – RPC (TCP-In) Buzón de correo RPC dinámica Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSExchangeThrottling.exe
MSExchangeThrottling – RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSExchangeThrottling.exe
MSFTED – RPC (TCP-In) Buzón de correo RPC dinámica Bin\MSFTED.exe
MSFTED – RPCEPMap (TCP-In) Buzón de correo RPC-EPMap Bin\MSFTED.exe
MSExchangeEdgeSync – RPC (TCP-In) Transporte de concentradores RPC dinámica Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeEdgeSync – RPCEPMap (TCP-In) Transporte de concentradores RPC-EPMap Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker – RPC (TCP-In) Transporte de concentradores RPC dinámica Bin\edgetransport.exe
MSExchangeTransportWorker – RPCEPMap (TCP-In) Transporte de concentradores RPC-EPMap Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP-In) Transporte de concentradores 25, 587 (TCP) Cualquiera
MSExchangeTransportWorker (TCP-In) Transporte de concentradores 25, 587 (TCP) Bin\edgetransport.exe
MSExchangeTransportLogSearch – RPC (TCP-In) Transporte de concentradores, Transporte perimetral, Buzón de correo RPC dinámica Bin\MSExchangeTransportLogSearch.exe
MSExchangeTransportLogSearch – RPCEPMap (TCP-In) Transporte de concentradores, Transporte perimetral, Buzón de correo RPC-EPMap Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-In) Mensajería unificada Cualquiera Cualquiera
SESWorker (TCP-In) Mensajería unificada Cualquiera UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP-In) Mensajería unificada 5060, 5061 Cualquiera
UMService (TCP-In) Mensajería unificada 5060, 5061 Bin\UMService.exe
UMWorkerProcess (GFW) (TCP-In) Mensajería unificada 5065, 5066, 5067, 5068 Cualquiera
UMWorkerProcess (TCP-In) Mensajería unificada 5065, 5066, 5067, 5068 Bin\UMWorkerProcess.exe
UMWorkerProcess – RPC (TCP-In) Mensajería unificada RPC dinámica Bin\UMWorkerProcess.exe
 Notas sobre las reglas del Firewall de Windows creadas por el programa de instalación de Exchange 2010
  • En los servidores que tienen instalado Internet Information Services (IIS), Windows abre los puertos HTTP (puerto 80, TCP) y HTTPS (puerto 443, TCP). La instalación de Exchange 2010 no abre estos puertos. Por lo tanto, dichos puertos no aparecen en la tabla anterior.
  • En Windows Server 2008 y Windows Server 2008 R2, el Firewall de Windows con seguridad avanzada permite especificar el proceso o servicio para el que se abre un puerto. Esta opción es más segura porque restringe el uso del puerto al proceso o servicio especificado en la regla. El programa de instalación de Exchange crea reglas de firewall con el nombre del proceso especificado. En algunos casos, y por motivos de compatibilidad, se crea una regla adicional que no está restringida al proceso. Puede deshabilitar o quitar las reglas que no están restringidas a los procesos y mantener las reglas correspondientes restringidas a procesos, en el caso de que la implementación lo admita. Las reglas que no están restringidas a procesos se distinguen con la palabra (GFW) en el nombre de regla.
  • Hay una serie de servicios de Exchange que usan llamadas a procedimientos remotos (RPC) para establecer la comunicación. Los procesos de servidor que usan RPC se ponen en contacto con el asignador de extremos de RPC para recibir extremos dinámicos y registrarlos en la base de datos del asignador de extremos. Los clientes RPC se ponen en contacto con el asignador de extremos de RPC para determinar los extremos que usa el proceso de servidor. De forma predeterminada, el asignador de extremos de RPC escucha en el puerto 135 (TCP). Cuando se configura el Firewall de Windows para un proceso que usa RPC, el programa de instalación de Exchange 2010 crea dos reglas de firewall para dicho proceso. Una regla permite la comunicación con el asignador de extremos de RCP y la otra permite la comunicación con el extremo asignado dinámicamente. Para obtener más información acerca de RPC, consulte Funcionamiento de RPC. Para obtener más información acerca de cómo crear reglas de Firewall de Windows para RPC dinámica, consulte Permitir trafico de red entrante que use RPC dinámica.

 

Asignaciones estáticas de puertos en Exchange Server

Asignaciones estáticas de puertos en Exchange Server

Asignaciones de puerto estático a equipos con cliente MAPI para que conecten mediante un firewall con Exchange 2000 Server o Exchange Server 2003

Para habilitar a los equipos con un cliente MAPI de una versión anterior para que conecten mediante un firewall con Exchange 2000 Server o Exchange Server 2003, agregue entradas al Registro para volver estáticos los puertos asignados a esas conexiones. Para ello, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque la clave siguiente para seleccionarla y haga clic en ella:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters
  3. Agregue la entrada siguiente para la interfaz SA RFR de Microsoft Exchange:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Información del valor: El número de puerto que se va a asignar, en formato decimal

    Asegúrese de de que asigna diferentes parámetros de puerto a cada clave del Registro. Si ejecuta el comando netstat -an en un símbolo del sistema, puede ver todas las conexiones TCP/IP y los puertos de escucha en formato numérico. Debe utilizar un puerto no usado para las asignaciones estáticas.

    Para obtener más información acerca de las directrices para asignar puertos estáticos a Exchange Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    154596  (http://support.microsoft.com/kb/154596/ ) Cómo configurar la asignación dinámica de puertos RPC para actuar con los servidores de seguridad
  4. Busque la clave siguiente para seleccionarla y haga clic en ella:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters
  5. Agregue el valor del Registro siguiente para la interfaz Proxy NSPI de directorio de Microsoft Exchange:
    Nombre de valor: TCP/IP NSPI Port
    Tipo de valor: REG_DWORD
    Información del valor: El número de puerto que se va a asignar, en formato decimal
  6. Busque y haga clic en la clave siguiente para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
  7. Agregue el valor del Registro siguiente para la interfaz del almacén de información de Microsoft Exchange:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Información del valor: El número de puerto que se va a asignar, en formato decimal
  8. Busque y haga clic en la clave siguiente para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS\Parameters
  9. Agregue el valor del Registro siguiente para el Servicio de replicación de sitios (SRS) de Microsoft Exchange:
    Nombre de valor: TCP/IP
    Tipo de valor: REG_DWORD
    Información del valor: El número de puerto que se va a asignar, en formato decimal
  10. Salga del Editor del Registro.
  11. Reinicie el equipo.

Después de completar estos pasos, configure el filtro de paquetes o el firewall para que las conexiones TCP se realicen en el puerto 135 para el servicio Operador de sistema de Microsoft Exchange y en los puertos que asignó en los pasos 3, 5, 7 y 9.

Si realiza estos cambios en un servidor que ejecuta Exchange 2000 Server o Exchange Server 2003 y que está instalado en un servidor de catálogo global, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque y haga clic en la clave siguiente para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  3. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: El número de puerto que se va a asignar, en formato decimal
  4. Salga del Editor del Registro.

Reinicie el servidor de catálogo global para que la asignación estática se lea al inicializarse la Interfaz del proveedor de servicios de nombres (NSPI).

Nota: el número de puerto seleccionado no debe entrar en conflicto con otros programas. Si el número de puerto entra en conflicto con otros programas, el NSPI no se iniciará.

 

Asignaciones de puerto estático a equipos con cliente MAPI para que conecten mediante un firewall con Exchange Server 5.5

Para habilitar a los equipos con un cliente MAPI de una versión anterior para que conecten mediante un firewall con Exchange 5.5, agregue entradas al Registro para volver estáticos los puertos asignados a esas conexiones. Para ello, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque la subclave siguiente para seleccionarla y haga clic en ella:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters
  3. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: 5000

    Nota: se recomienda asignar puertos comprendidos en el intervalo 5000 – 65535 (decimal). Para obtener más información acerca de las directrices para asignar puertos estáticos a servicios de Exchange Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    154596  (http://support.microsoft.com/kb/154596/ ) Cómo configurar la asignación dinámica de puertos RPC para actuar con los servidores de seguridad
  4. Busque y haga clic en la subclave siguiente para seleccionarla:
    System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
  5. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: 5001

    Nota: se recomienda asignar puertos comprendidos en el intervalo 5000 – 65535 (decimal). Para obtener más información acerca de las directrices para asignar puertos estáticos a servicios de Exchange Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    154596  (http://support.microsoft.com/kb/154596/ ) Cómo configurar la asignación dinámica de puertos RPC para actuar con los servidores de seguridad
  6. Salga del Editor del Registro.
  7. Reinicie el equipo.

Después de completar estos pasos, configure el filtro de paquetes o el firewall para que las conexiones del Protocolo de control de transmisión (TCP) se realicen en el puerto 135 para el servicio Operador de sistema de Microsoft Exchange y en los puertos que asignó en los pasos 3 y 5.

Asigne estáticamente los puertos para un servidor de aplicaciones en entornos de Ethernet de red perimetral, para que el equipo pueda iniciar sesión en la red y comunicar con los servidores de fondo

Para instalar Exchange Server 2003 o Exchange 2000 Server en equipos aislados de sus redes de Microsoft Windows Server 2003 o Microsoft Windows 2000 por un firewall y que están en un entorno de Ethernet de red perimetral, siga estos pasos:

  1. Para que los equipos basados en Windows Server 2003 o en Windows 2000 Server puedan iniciar sesión en el dominio a través del firewall, abra los puertos siguientes para el tráfico entrante:
    • 53 (Protocolo de control de transmisión [TCP], Protocolo de datagramas de usuarios [UDP]) – Sistema de nombres de dominio (DNS).
    • 80 (TCP) – Necesario para el acceso de Outlook Web Access para la comunicación entre los servidores de Exchange de aplicaciones para el usuario y de servicios de fondo.
    • 88 (Protocolo de control de transmisión [TCP], UDP) – autenticación Kerberos.
    • 123 (UDP) – Protocolo de sincronización horaria (NTP) de Windows. No es necesario para el inicio de sesión en Windows 2000. Sin embargo, se puede configurar o puede requerirlo el administrador de red.
    • 135 (TCP) – EndPointMapper.
    • 389 (TCP, UDP) – Protocolo ligero de acceso a directorios (LDAP).
    • 445 (TCP) – Bloque de mensajes del servidor (SMB) para Netlogon, conversión a LDAP y descubrimiento del Sistema de archivos distribuido (DFS) de Microsoft.
    • 3268 (TCP) – LDAP a servidores de catálogo global.
    • Un puerto para el inicio de sesión y la interfaz de replicación de directorios de Active Directory (identificadores únicos universales [UUID] 12345678-1234-abcd-ef00-01234567cffb y 3514235-4b06-11d1-ab04-00c04fc2dcd2). Normalmente se le asigna el puerto 1025 ó 1026 durante el inicio. Este valor no se configura en el código fuente DSProxy o del Operador del sistema (MAD). Por tanto, debe asignar el puerto en el Registro en cualquier controlador de dominio con el que el servidor de Exchange deba ponerse en contacto a través del firewall para procesar los inicios de sesión. Después, abra el puerto en el firewall.

      Para asignar el puerto en el Registro, siga estos pasos:

      1. Inicie el Editor del Registro.
      2. Busque la clave siguiente para seleccionarla y haga clic en ella:
        HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
      3. Agregue el valor de Registro siguiente:
        Nombre de valor: TCP/IP Port
        Tipo de valor: REG_DWORD
        Base: decimal
        Valor (Value): un valor superior a 1024
      4. Salga del Editor del Registro.

      Asegúrese de que la barra inclinada de “TCP/IP” sea una barra inclinada, no invertida. Además, asegúrese de que el valor que le asigna es mayor que 1024 (decimal). Este número es el puerto adicional que debe abrir (TCP, UDP) en el firewall. La configuración de este valor del Registro en todos los controladores de dominio dentro del firewall no afecta al rendimiento. Además, la configuración de este valor del Registro cubre todas las redirecciones de solicitudes de inicio de sesión debidas a los servidores que han entrado en inactividad, las funciones que cambian o los requisitos de ancho de banda.

    Notas

    • Para que el servidor que está dentro del firewall se comunique mediante éste con el servidor externo, debe tener también los puertos 1024 a 65535 configurados para las comunicaciones salientes. Los equipos que inician la comunicación a través del firewall utilizan un puerto de cliente que se asigna dinámicamente y que no se puede configurar.
    • Windows 2000 adopta la forma de una secuencia de solicitudes ping de TCP/IP al servidor de destino cuando los equipos basados en Windows 2000 inician sesión en el dominio a través del firewall. Windows 2000 hace esto para determinar si un equipo cliente está teniendo acceso a un controlador de dominio a través de un vínculo lento para aplicar una directiva de grupo o para descargar un perfil de usuario móvil.
  2. Instale Exchange Server 2003 o Exchange 2000 Server en el equipo externo. No es necesario que haya más puertos abiertos para instalar Exchange Server 2003 o Exchange 2000 Server en el equipo externo.
  3. Configure la conectividad de aplicaciones para el usuario y de servicios de fondo de Exchange Server 2003 o de Exchange 2000 Server. La conectividad de aplicaciones para el usuario y de servicios de fondo de Exchange Server 2003 o de Exchange 2000 Server sólo necesita que estén abiertos otros puertos necesarios para cualquier comunicación que sea apropiada. Por ejemplo, la conectividad de aplicaciones para el usuario y de servicios de fondo de los clientes Web requiere que esté abierto el puerto 80 [TCP], IMAP 143 [TCP], etc. Además, cualquier conectividad mediante protocolos seguros, como IPSec o Capa de sockets seguros (SSL)-HTTP seguro, Protocolo de acceso a mensajes de Internet (IMAP) o Protocolo de oficina de correos versión 3 (POP3), que necesite requiere una configuración adicional que no se especifica en este artículo. Si el servidor de servicios de fondo de la red perimetral tiene una subred diferente, asegúrese de agregar esa subred en el complemento Sitios y servicios de Active Directory.

    Nota: no tiene que agregar la subred si no ha creado un objeto de subred independiente en Sitios y servicios de Active Directory.

    En un entorno Ethernet de red perimetral, también debe definir las rutas de acceso TCP/IP desde el equipo del entorno Ethernet de red perimetral a todos los equipos de la red interna con los que se tiene que comunicar.

    Nota: en un escenario de firewall de red perimetral, no hay ninguna conectividad de Protocolo de mensajes de control de Internet (ICMP) entre el servidor Exchange y los controladores de dominio. De manera predeterminada, Acceso al directorio (DSAccess) utiliza ICMP para hacer ping en cada servidor con el que conecta para determinar si el servidor está disponible. Cuando no hay conectividad ICMP, Acceso al directorio responde como si todos los controladores de dominio no estuvieran disponibles. Para obtener más información acerca de cómo desactivar el ping a Acceso al directorio creando una clave del Registro, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

    320529  (http://support.microsoft.com/kb/320529/ ) Para utilizar DSAccess en un escenario con un servidor de seguridad de red perimetral se requiere establecer una clave del registro
    320228  (http://support.microsoft.com/kb/320228/ ) El valor del Registro “DisableNetLogonCheck” y cómo usarlo
 

Cómo configurar Microsoft Exchange Server 5.5 Outlook Web Access para conectar con Exchange Server 5.5 mediante un firewall.

Para instalar Outlook Web Access de Microsoft Exchange Server 5.5 en un equipo externo dirigido a un servidor de Exchange Server 5.5 que se ejecuta dentro de la red perimetral y de un firewall, debe abrir los puertos de Windows 2000 o de Windows Server 2003 mencionados al principio de la sección “Asigne estáticamente los puertos para un servidor de aplicaciones en entornos de Ethernet de red perimetral, para que el equipo pueda iniciar sesión en la red y comunicar con los servidores de fondo”. Además, necesita asignaciones estáticas para el servicio de directorios de Exchange Server 5.5 (UUID f5cc5a18-4264-101a-8c59-08002b2f8426), el servicio Almacén de información de Microsoft Exchange (UUID a4f1db00-ca47-1067-b31f-00dd010662da) y el Operador del sistema (UUID 469d6ec0-0d87-11ce-b13f-00aa003bac6c).

Para configurar el puerto RPC para el Servicio de directorios de Microsoft Exchange, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque la siguiente subclave del Registro y haga clic en ella para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters
  3. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: el número de puerto que se va a asignar, en formato decimal
  4. Salga del Editor del Registro.

Para configurar el puerto RPC para el Almacén de información de Microsoft Exchange, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque y haga clic en la subclave siguiente para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
  3. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: el número de puerto que se va a asignar, en formato decimal
  4. Salga del Editor del Registro.

Para configurar el puerto RPC para el servicio Operador del sistema de Microsoft Exchange, siga estos pasos:

  1. Inicie el Editor del Registro.
  2. Busque y haga clic en la subclave siguiente para seleccionarla:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters
  3. Agregue el valor de Registro siguiente:
    Nombre de valor: TCP/IP Port
    Tipo de valor: REG_DWORD
    Base: Decimal
    Información del valor: el número de puerto que se va a asignar, en formato decimal
  4. Salga del Editor del Registro.
  5. Reinicie el equipo.

Limitaciones de las asignaciones de puerto estático de Exchange Server

La lista siguiente describe algunas de las limitaciones de las asignaciones de puerto estático de Exchange Server:

  • Problemas de acceso a clientes de Outlook

    Si un proceso ya está utilizando el puerto asignado estáticamente cuando se inicia el servicio Exchange, este servicio no puede utilizar ese puerto. Sin embargo, el servicio Almacén de información de Microsoft Exchange o el servicio de directorios de Microsoft Exchange, o ambos, seguirán registrando todos los demás extremos y se iniciarán correctamente.

    Sin embargo, cuando los usuarios intentan abrir Outlook y se conectan a Exchange Server, pueden recibir el mensaje de error siguiente:

    No se pueden abrir las carpetas de correo electrónico predeterminadas. No tiene permiso para iniciar la sesión.

    Para resolver este problema, asegúrese de que Exchange Server ha inicializado un puerto para el servicio Almacén de información, el servicio Operador del sistema y el servicio NSPI de Microsoft Exchange. Puede comprobarlo si ejecuta RPCDump en el servidor para el protocolo TCP/IP.

    Puede asignar estáticamente los servicios de Exchange Server enumerados en este artículo a cualquier número de puerto TCP/IP libre de todo el intervalo (1-65535). Si ejecuta un comando netstat -anen un símbolo del sistema, verá una lista de todos los puertos registrados actualmente en el servidor. Puede utilizar esta lista para seleccionar un nuevo puerto válido (libre) para la asignación estática de los servicios de Exchange.

  • Problemas de seguimiento de mensajes

    Para habilitar la función de seguimiento de mensajes en un servidor que ejecuta el Service Pack 2 (SP2) de Exchange 2000 Server o una versión posterior y que se encuentra en la red perimetral, se debe permitir que Instrumental de administración de Windows (WMI) se conecte al servidor de destino.

    El servicio WMI empieza a crear conexiones en el puerto con el número menor, empezando en el puerto 1024. Con el tiempo, el número de puerto utilizado por WMI aumenta secuencialmente. Para obtener más información acerca de cómo asignar estáticamente puertos para el servicio WMI, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

    154596  (http://support.microsoft.com/kb/154596/ ) Cómo configurar la asignación de puertos dinámica de RPC para actuar con los servidores de seguridad
 

Microsoft Exchange Server 2007

En este artículo, el proceso de asignación de puertos estáticos para Exchange Server 2003 y Exchange 2000 Server sigue funcionando en Exchange 2007. Pero no es compatible con la instalación de un servidor de acceso de cliente en una red perimetral. No es compatible con la instalación de un servidor de acceso de cliente en una red perimetral (también llamado DMZ, zona desmilitarizada y subred protegida) ni con ninguna configuración que tenga un firewall entre ella y el buzón de correo o los controladores de dominio. Puertos de firewall que deben estar abiertos para Exchange 2007.

El tema siguiente proporciona información acerca de los puertos, autenticación y cifrado para todas las rutas de datos usadas por Exchange 2007. Las secciones de Notas que siguen a cada tabla aclaran o definen los métodos de cifrado o autenticación no estándar.
http://technet.microsoft.com/es-es/library/bb331973.aspx (http://technet.microsoft.com/es-es/library/bb331973.aspx)

Para obtener más información acerca de cómo arreglar el puerto UDP para Outlook 2003 y Outlook 2007, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

839226  (http://support.microsoft.com/kb/839226/ ) La característica Buscar de Outlook y las nuevas notificaciones de correo no funcionan después de aplicar el Service Pack 2 de Windows XP

Todos los servidores salvo los de redes perimetrales deberían implementarse en la red corporativa. A diferencia de las versiones anteriores de Exchange, Microsoft no admite la instalación e implementación de Exchange 2007 en una red perimetral. Esta información está documentada en el siguiente artículo de Technet:

Nota: no se admite la instalación de un servidor de acceso de cliente en una red perimetral. Cuando no hay firewalls entre los servidores Exchange 2007, se deben comunicar libremente unos con otros. El firewall debe estar entre el entorno de producción y los clientes

Puertos utilizados en Exchange Server 2003

Puertos utilizados en Exchange Server 2003

La tabla siguiente muestra los servicios de Exchange Server 2003 y sus puertos correspondientes. Para obtener más información sobre cómo configurar servidores de aplicaciones para usuario de Exchange, incluyendo los puertos asociados a las distintas situaciones, consulte el artículo técnico, Using Microsoft Exchange 2000 Front-End Servers. Si bien ese artículo se refiere a Exchange 2000 Server, la información puede aplicarse también a Exchange Server 2003.

Puertos utilizados en Exchange 2003

Servicios (dependencias) Puertos de entrada Puertos de salida (iniciar conexiones en) Notas
Operador de sistema de Microsoft Exchange 135 & otro RPC

Otros puertos requeridos para RPC a través de HTTP

  Todos los servicios básicos de Exchange necesitan el Operador de sistema de Microsoft Exchange.

Para más información sobre la configuración de puertos de RPC a través de HTTP, consulte la guía Exchange Server 2003 RPC over HTTP Deployment Scenarios.

Almacén de información de Microsoft Exchange

(Operador de sistema de Microsoft Exchange)

135 & otro RPC

Otros puertos requeridos para RPC a través de HTTP

Paquetes del Protocolo de datagramas de usuario (UDP) a puertos aleatorios para la notificación de nuevo correo Ejecuta las bases de datos de Exchange.

Para más información sobre la configuración de puertos de RPC a través de HTTP, consulte la guía Exchange Server 2003 RPC over HTTP Deployment Scenarios.

Pila MTA de Microsoft Exchange

(Operador de sistema de Microsoft Exchange)

135 & otro RPC

102 para X.400 a través de TCP

135 & otro RPC

102 para X.400 a través de TCP

Las pilas MTA de Microsoft Exchange son necesarias para las conexiones heredadas con servidores de Exchange Server 5.5. El puerto 102 sólo se abre para las conexiones X.400 activas.
Protocolo simple de transferencia de correo (SMTP)

(Servicio de administración de IIS)

25 25 El almacén de Exchange requiere SMTP
Motor de enrutamiento de Microsoft Exchange

(Servicio de administración de IIS)

691 691 Servicio Motor de enrutamiento
Servicio de publicación World Wide Web

(Servicio de administración de IIS)

80 & 443 80 en el servidor de aplicaciones para usuario Necesario para Outlook Web Access y la administración de carpetas públicas
Exchange ActiveSync

(Servicio de administración de IIS)

  UDP 2883 en el servidor de aplicaciones para usuario Necesario para la inserción directa necesaria de SP2 Exchange ActiveSync
POP3 de Microsoft Exchange

(Servicio de administración de IIS)

110 & 995 (SSL) 110 en el servidor de aplicaciones para usuario Necesario para el acceso POP3
IMAP4 de Microsoft Exchange

(Servicio de administración de IIS)

143 & 993 (SSL) 143 en el servidor de aplicaciones para usuario Necesario para el acceso IMAP4
Protocolo de transferencia de noticias a través de la red (NNTP)

(Servicio de administración de IIS)

119 & (563 SSL)   N/D
Servicio de replicación de sitios de Microsoft Exchange 379, 135 & otro RPC 135 & otro RPC Depende de si los servidores de Exchange Server 5.5 están o no en la organización.
Conector de Active Directory N/D 379, 389, se puede configurar Depende de si los servidores de Exchange Server 5.5 están o no en la organización
Sucesos de Microsoft Exchange

(Almacén de información de Microsoft Exchange)

    No es automático de manera predeterminada
Administración de Exchange

(Instrumental de administración de Windows)

    No es un servicio necesario; sin embargo, Microsoft Operations Manager y otros programas no funcionan sin este servicio.

Bb124075.note(es-es,EXCHG.65).gifNota:
El puerto 445 es necesario para el seguimiento de mensajes