Descripción del uso de proxy y redirección

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

En una organización de Microsoft Exchange Server 2010, un servidor de acceso de cliente puede actuar como proxy para otros servidores de acceso de cliente de la misma organización. Esta posibilidad resulta útil cuando existen varios servidores de acceso de cliente en distintos sitios de Active Directory de una organización y al menos uno de ellos no está abierto a Internet.

Un servidor de acceso de cliente además puede efectuar redirecciones para URL de Microsoft Office Outlook Web App y de dispositivos de Exchange ActiveSync. El redireccionamiento es útil cuando los usuarios se conectan con un servidor de acceso de cliente que no está en el sitio de Active Directory local o si un buzón se ha movido entre sitios de Active Directory. También resulta útil si los usuarios deberían estar usando realmente una URL más eficaz. Por ejemplo, los usuarios deberían estar usando una URL más próxima al sitio de Active Directory en el que residen sus buzones.

La respuesta del servidor de acceso de cliente puede variar según el protocolo. Normalmente, sin embargo, un servidor de acceso de cliente emprende la siguiente acción si recibe una solicitud de un usuario cuyo buzón se encuentra en un sitio de Active Directory distinto del sitio al que pertenece el servidor de acceso de cliente: en este caso, el servidor busca la presencia de una propiedad ExternalURL en el directorio virtual correspondiente de un servidor de acceso de cliente que se encuentre en el mismo sitio de Active Directory que el buzón del usuario. Si existe la propiedad ExternalURL y el tipo de cliente admite la redirección (por ejemplo, Outlook Web App o Exchange ActiveSync), el servidor de acceso de cliente emite una redirección a ese cliente. Si no existe una propiedad ExternalURL o si el tipo de cliente no admite la redirección (por ejemplo, POP3 o IMAP4), el servidor de acceso de cliente intentará redirigir mediante proxy la conexión al sitio de Active Directory de destino.

En este tema se explica la redirección mediante proxy y la redirección estándar, cuándo se usa cada una de ellas y cómo se deben configurar los servidores de acceso de cliente para cada escenario.

Contenido

Introducción a las conexiones proxy

Introducción a la redirección

Proxy con equilibrio de carga de red

Resumen de métodos de acceso de cliente

Rendimiento y escalabilidad de proxy

Introducción a la función de proxy

En Microsoft Exchange Server 2003, el servidor front-end se comunica con el servidor back-end mediante HTTP. En Exchange Server 2007 y Exchange 2010, el servidor de acceso de cliente se comunica con un servidor de buzones de Exchange a través de RPC. Es necesario tener un servidor de acceso de cliente de Exchange 2010 en todos los sitios de Active Directory que contengan un servidor de buzones de Exchange 2010. La función de proxy significa que un servidor de acceso de cliente envía tráfico a otro servidor de acceso de cliente. Un servidor de acceso de cliente Exchange 2010 puede actuar de proxy de solicitudes en las siguientes situaciones:

• Entre servidores de acceso de cliente Exchange 2010   Las solicitudes con proxy entre dos servidores de acceso de cliente Exchange 2010 permiten a las organizaciones con varios sitios de Active Directory designar un servidor de acceso de cliente como servidor sin conexión a Internet y hacer que ejerza la función de proxy para las solicitudes a servidores de acceso de cliente de sitios que no tienen presencia en Internet. El servidor de acceso de cliente con conexión a Internet envía como proxy la solicitud al servidor de acceso de cliente más próximo al buzón de correo del usuario.

• Entre un servidor de acceso de cliente de Exchange 2010 y servidores de acceso de cliente de Exchange 2007   Las solicitudes de proxy entre un servidor de acceso de cliente de Exchange 2010 y un servidor de acceso de cliente de Exchange 2007 dentro de un sitio de Active Directory o entre sitios de Active Directory les permiten a Exchange 2010 y Exchange 2007 coexistir en la misma organización. Para obtener más información sobre actualización y coexistencia de versiones, consulte Actualizar desde el servicio de acceso de cliente de Exchange 2003 y Actualizar desde el servicio de acceso de cliente de Exchange 2007.

La función de proxy se admite para clientes que usan Outlook Web App, Exchange ActiveSync, panel de control de Exchange (ECP), POP3, IMAP4 y servicios web de Exchange. El uso de proxy es compatible entre dos servidores Acceso cliente cuando el servidor de destino esté ejecutando la misma versión de Microsoft Exchange o una versión de Microsoft Exchange anterior a la del servidor Acceso cliente de origen, salvo en los casos en que se necesite una URL de una versión específica. Para obtener más información sobre las direcciones URL de versiones específicas y los nombres de host heredados en un entorno mixto de Exchange 2007 y Exchange 2010, consulte Actualizar desde el servicio de acceso de cliente de Exchange 2007. Para obtener más información sobre las direcciones URL de versiones específicas y los nombres de host heredados en un entorno mixto de Exchange 2010 y Exchange 2013, consulte Crear un nombre de host de Exchange heredado.

Función de proxy para acceso de cliente

En la figura anterior, el buzón de correo del usuario 1 está ubicado en el servidor de buzón 1, el buzón de correo del usuario 2 está ubicado en el servidor de correo 2 y el del usuario 3, en el servidor 3. Cada servidor de buzón de correo se encuentra en un sitio de directorio activo diferente. El usuario 1 puede tener acceso a su buzón mediante el servidor 1 de acceso de cliente sin usar la función de proxy y el usuario 2 puede tener acceso a su buzón de correo mediante el servidor 2 de acceso de cliente. Si el usuario 3 intenta tener acceso al buzón de correo mediante el servidor de acceso de cliente 1 o 2, cualquier servidor enviará la solicitud de proxy al servidor 3 de acceso de cliente. El servidor 3 de acceso de cliente no tiene conexión a Internet pero puede recibir solicitudes de otros servidores dentro del firewall. La función de proxy es invisible para el usuario.

Introducción a la función de proxy

Introducción a la redirección

Los usuarios de Outlook Web App que obtienen acceso a un servidor de acceso de cliente abierto a Internet que se encuentra en un sitio de Active Directory distinto que el sitio que contiene su buzón de correo, pueden ser redirigidos al servidor de acceso de cliente que se encuentra en el mismo sitio que su servidor de buzones si dicho servidor tiene conexión a Internet. Cuando un usuario de Outlook Web App intenta conectar con un servidor de acceso de cliente que está fuera del sitio de Active Directory que contiene su servidor de buzón de correo, se abrirá una página web con un vínculo al servidor de acceso de cliente correcto para su buzón de correo. Esto se conoce como redireccionamiento manual. En Exchange 2010 SP2, los administradores pueden configurar un redireccionamiento silencioso entre sitios para permitir que este proceso de redireccionamiento se produzca sin el conocimiento del usuario. Para obtener más información, consulte el Redireccionamiento silencioso entre sitios más adelante en este tema.

Los usuarios de Exchange ActiveSync que tienen acceso a un servidor de acceso a cliente con conexión a Internet en un sitio de Active Directory diferente del sitio que contiene su buzón de correo podrá ser redirigido al servidor de acceso de cliente en el mismo sitio que el servidor de buzones si el servidor de acceso de cliente tiene conexión a Internet y si el dispositivo o teléfono móvil del cliente ha implementado correctamente la lógica de redirección generada en el protocolo que usa al comunicarse con Exchange 2007 y Exchange 2010. La redirección de usuarios Exchange ActiveSync se logra al enviar al dispositivo un código de error HTTP 451 que contiene la URL que debería usar el dispositivo. A continuación, el dispositivo se reconfigura automáticamente para usar la nueva dirección URL.

En la figura siguiente se ilustra el funcionamiento de la redirección en una organización con varios servidores de acceso de cliente en varios sitios de Active Directory.

Redireccionamiento para Exchange ActiveSync y Outlook Web App en Exchange 2010

En la figura anterior, el usuario 1 generalmente tenía acceso a su buzón de correo en el sitio 1 de Active Directory con su teléfono móvil. A continuación, el administrador transfiere su buzón de correo al servidor 2 de buzón de correo en el sitio 2 de Active Directory. La próxima vez que el dispositivo intenta sincronizarse, el servidor le responderá con un error de estado HTTP 451. Contiene la dirección URL que el dispositivo debe usar ahora para ese usuario. En el paso 3 de la secuencia, el dispositivo se reconfigura y se conecta a la URL especificada. El usuario 2, cuyo buzón de correo se encuentra en el sitio 2 de Active Directory, intenta abrir su buzón de correo con Outlook Web App al conectarse con el servidor 1 de acceso de cliente por Internet. Con el redireccionamiento manual, tan pronto como el usuario se autentica, el servidor de acceso de cliente 1 presenta una página al usuario, con un vínculo a la Outlook Web App URL para el servidor de acceso de cliente en el sitio 2 de Active Directory. El usuario hace clic en el vínculo, que lo lleva al sitio 2 de Active Directory e inicia sesión nuevamente para acceder a su buzón. Con el redireccionamiento manual, cuando el usuario se autentica, se lo redirecciona silenciosamente a la Outlook Web App URL para el servidor de acceso de cliente en el sitio 2 de Active Directory.

Redireccionamiento silencioso entre sitios

Exchange 2010 SP2 permite a los administradores configurar el redireccionamiento silencioso entre sitios. El redireccionamiento silencioso entre sitios redirecciona de manera silenciosa las solicitudes de los clientes destinados a un CAS que se encuentra en un sitio distinto de Active Directory, en la misma organización de Exchange. Por ejemplo, un usuario con un buzón en el sitio A de Active Directory que accede a la Outlook Web App URL en el sitio B de Active Directory será redirigido silenciosamente a la Outlook Web App URL para en el sitio A de Active Directory.

Para configurar el redireccionamiento silencioso entre sitios, el administrador debe usar el nuevo parámetro CrossSiteRedirectType que se ha agregado al cmdlet Set-OWAVirtualDirectory. El parámetro tiene dos configuraciones posibles. El valor predeterminado es Manual.

• Silencioso Cuando se elige esta configuración, el explorador web de un usuario se redirecciona automáticamente cuando un servidor de acceso de cliente debe redirigir una solicitud de Outlook Web App a un servidor de acceso de cliente o una matriz de servidor ubicada en otro sitio de Active Directory. Cuando la autenticación basada en formularios se configura en los directorios virtuales OWA CAS de origen y destino (se requiere SSL), el redireccionamiento silencioso también es un evento de inicio de sesión único. Para que se produzca el redireccionamiento, el directorio Outlook Web App del servidor de acceso de cliente de destino debe tener un valor ExternalURL.

• Manual Cuando se elige esta configuración, los usuarios recibirán una notificación acerca de que están obteniendo acceso a la URL incorrecta y que deben hacer clic en un vínculo para acceder a la URL correcta de Outlook Web App para su buzón de correo. Esta notificación solamente se produce cuando el servidor de acceso de cliente determina que debe redirigir una solicitud de Outlook Web App a un servidor de acceso de cliente o una matriz de servidor ubicada en otro sitio de Active Directory. Para que se produzca el redireccionamiento, el directorio Outlook Web App del servidor de acceso de cliente de destino debe tener un valor ExternalURL.

Por ejemplo:

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Para obtener más información acerca del cmdlet Set-OwaVirtualDirectory, consulte. Set-OwaVirtualDirectory

Uso de servidor proxy y redirección de ActiveSync de Exchange

La siguiente serie de pasos muestra de qué forma se manejan las solicitudes entrantes para un usuario que se conecta a un servidor de acceso de cliente Exchange 2010 llamado CAS-01 con un teléfono móvil.

1. El servidor de acceso de cliente consulta a Active Directory para determinar la ubicación del buzón de correo del usuario y la versión de Microsoft Exchange instalada en el servidor de buzones.

2. Si el buzón de correo del usuario se encuentra en un servidor Exchange 2003, la solicitud entrante se envía mediante proxy directamente al servidor Exchange 2003 que hospeda el buzón de correo y el directorio virtual Exchange ActiveSync. De forma predeterminada, en Exchange 2003, el directorio virtual Exchange ActiveSync se instala en todos los servidores de buzón de correo. El sitio de Active Directory del buzón de correo del usuario no se aplica en este caso porque Exchange 2003 no usa Active Directory sitios para determinar la ubicación. La conexión siempre se realiza directamente desde el servidor de acceso de cliente Exchange 2010 hacia el servidor de buzón de correo Exchange 2003. 

   Nota

   Los usuarios con buzones en un servidor de Exchange 2003 que intenten usar Exchange ActiveSync a través de un servidor de acceso de cliente de Exchange 2010 recibirán un mensaje de error y no podrán sincronizar, a no ser que la autenticación de integrada Windows esté habilitada en el directorio virtual Microsoft-Server-ActiveSync en el servidor de Exchange 2003. La autenticación integrada de Windows permite la comunicación entre el servidor de acceso de cliente Exchange 2010 y el servidor back-end deExchange 2003.

3. Si el buzón de correo del usuario se encuentra en un servidor de buzón de correoExchange 2007, CAS-01 localiza un servidor de acceso de clienteExchange 2007 ubicado en el mismo sitio de Active Directory que el servidor de buzón de correo del usuario. Este puede ser el mismo sitio de Active Directory que CAS-01. CAS-01 redirige mediante proxy la solicitud de Exchange ActiveSync a la propiedad InternalURL del servidor de acceso de cliente de Exchange 2007 independientemente de la configuración de la propiedad ExternalURL. La solicitud va al directorio virtual /Proxy situado bajo el directorio virtual de Exchange ActiveSync de Microsoft Server en IIS y, de forma predeterminada, tiene habilitada la autenticación de Windows integrada en él.

4. Si el buzón de correo se encuentra en un servidor de buzón de correo de Exchange 2010 en el mismo sitio de Active Directory que CAS-01, CAS-01 proporcionará acceso al buzón de correo. Si el buzón de correo del usuario se encuentra en un servidor de buzón Exchange 2010, en un sitio diferente de Active Directory, CAS-01 localiza un servidor de acceso de cliente ubicado en el mismo sitio de Active Directory que el servidor de buzón de correo del usuario. CAS-01 determina si el servidor de acceso de cliente de Exchange 2010 en ese sitio de Active Directory tiene la propiedad ExternalURL configurada en el directorio virtual de Exchange ActiveSync. En caso afirmativo, CAS-01 emite un código de error 451 de HTTP que contiene el valor ExternalURL y le ordena al cliente que se redireccione a esa ubicación. Si no se ha configurado un valor de ExternalURL, se enviará la conexión mediante proxy al servidor de acceso de cliente con la FQDN especificada por la propiedadInternalURL, específicamente al directorio virtual del proxy. El directorio virtual se ubica debajo del directorio virtual Exchange ActiveSync en IIS y, de manera predeterminada, tiene autenticación integrada de Windows habilitada para éste.

   Importante

   La función de proxy no es posible entre directorios virtuales que usan autenticación básica. Para que las comunicaciones de cliente se envíen mediante proxy entre directorios virtuales de Exchange ActiveSync, el directorio virtual del proxy deben usar autenticación integrada de Windows.

Introducción a la función de proxy

Enviar mediante proxy y redireccionar para Outlook Web App

La siguiente serie de pasos muestra de qué forma se manejan las solicitudes entrantes para un usuario que se conecta a un servidor de acceso de cliente Exchange 2010 llamado CAS-01 con un Outlook Web App.

1. El servidor de acceso de cliente consulta a Active Directory para determinar la ubicación del buzón de correo del usuario y la versión de Microsoft Exchange instalada en el servidor de buzones.

2. Si el buzón de correo se encuentra en un servidor Exchange 2003 y el usuario intenta tener acceso a Outlook Web App mediante https://domain name/owa, recibirán un error porque el servidor de acceso de cliente de Exchange 2010 no puede proporcionar directamente acceso de Outlook Web App a un buzón de correo de Exchange 2003. Sin embargo, si el administrador configuró la redirección desde Exchange 2010 hacia Exchange 2003, que sería habitual durante la migración desde Exchange 2003 hacia Exchange 2010, la propiedad Exchange2003URL del directorio virtual de Outlook Web Appse configurará al valor de un servidor de Exchange 2003 con conexión a Internet.

3. Si el buzón del usuario se encuentra en un servidor de buzón Exchange 2007, CAS-01 localiza un servidor de acceso de cliente ubicado en el mismo sitio de Active Directory que el servidor de buzón del usuario. Si el servidor de buzón de correo Exchange 2007 se encuentra en el mismo sitio de Active Directory que CAS-01, se producirán una de las cuatro acciones posibles.

   • CAS-01 buscará una propiedad de Exchange 2007 ExternalURL con configuración ExternalAuthenticationMethods de idéntica InternalAuthenticationMethods a la configuración del servidor de acceso de cliente de Exchange 2010. Si la configuración coincide, CAS-01 se redirigirá a esta dirección URL externa. Si el CAS de origen y destino tiene habilitada la Autenticación basada en formularios (FBA), el CAS de origen emite un formulario oculto al explorador. Este formulario contiene la configuración de la FBA y las credenciales del usuario, junto con la URL para redirección. Esto es transparente para el usuario.

   • Si no se encuentra una configuración ExternalURL, CAS-01 buscará un servidor de acceso de cliente de Exchange 2007que tenga la propiedad ExternalURL configurada, independientemente de la coincidencia. Si encuentra alguno, CAS-01 se redirigirá a esta dirección URL externa. Como resultado, se le solicitará autenticación al usuario.

   • Si no se encuentra una configuración ExternalURL coincidente, CAS-01 buscará un servidor de acceso de cliente de Exchange 2007 con una propiedad InternalURL cuya configuración InternalAuthenticationMethods sea idéntica a la configuración InternalAuthenticationMethods del servidor de acceso de cliente de Exchange 2010. Si encuentra alguna, CAS-01 se redirigirá a este InternalURL. Si está habilitada la autenticación basada en formulario, ocasionará una redirección única de inicio de sesión.

   • Si no se encuentra un InternalURL coincidente, CAS-01 buscará un servidor de acceso de clientes de Exchange 2007 con un InternalURL configurado, independientemente de la coincidencia. Si encuentra alguna, CAS-01 se redirigirá a este InternalURL. Como resultado, se le solicitará autenticación al usuario.

   Si el servidor de buzón de Exchange 2007 se encuentra en un sitio Active Directory diferente, CAS-01 determinará si la propiedad ExternalURL se configura en ese sitio de Active Directory. Si esto es así, el redireccionamiento silencioso entre sitios no se habilita, el valor CrossSiteRedirectType se configura en Manual, y se emite un redireccionamiento manual. En este caso, se le proporcionará al usuario un vínculo que los redirija a la URL especificada.

   Si se ha habilitado el redireccionamiento silencioso entre sitios, el valor CrossSiteRedirectType se configura en Silencioso y el uso se redirecciona automáticamente en la URL especificada. Si la propiedad ExternalURL no está presente y el método de autenticación del directorio virtual /OWA está configurado con la autenticación de Windows integrada, CAS-01 enviará mediante proxy la solicitud del usuario al servidor de acceso de cliente especificado por la propiedad InternalURL.

   Importante

   Para permitir a un servidor de acceso de cliente de Exchange 2010 el envío mediante proxy de solicitudes de Outlook Web App a un servidor de acceso de cliente Exchange 2007 en otro sitio de Active Directory, debe copiar la carpeta con la última versión de un servidor de acceso de cliente de Exchange 2007 en el sitio de destino de Active Directory desde la carpeta %installpath%\ClientAccess\OWA\ hasta la misma ruta en el servidor de acceso de cliente de Exchange 2010 que realiza la solicitud de proxy.

   Importante

   Un Exchange 2010 servidor de acceso de cliente nunca enviará mediante proxy solicitudes de Outlook Web App a un servidor de acceso de cliente de Exchange 2007 al mismo sitio de Active Directory. Todas las solicitudes dentro del mismo sitio de Active Directory se redirigen a un servidor de acceso de cliente de Exchange 2007, mediante las propiedadesInternalURL o ExternalURL para el servidor de acceso de cliente, según las propiedades configuradas.

4. Si el buzón de correo se encuentra en un servidor de buzón de correo de Exchange 2010 en el mismo sitio de Active Directory que CAS-01, CAS-01 proporcionará acceso al buzón de correo. Si el buzón de correo del usuario se encuentra en un servidor de buzón Exchange 2010, en un sitio diferente de Active Directory, CAS-01 localiza un servidor de acceso de cliente ubicado en el mismo sitio de Active Directory que el servidor de buzón de correo del usuario. Cuando se encuentra uno, Exchange 2010 determina si el servidor de acceso de cliente tiene la propiedad ExternalURL configurada en ese sitio de Active Directory. Si esto es así, y no se ha habilitado el redireccionamiento silencioso entre sitios, se le proporcionará al usuario un vínculo que lo redirigirá a la URL especificada. Si se habilita el redireccionamiento silencioso entre sitios, el usuario se redirigirá automáticamente a la URL especificada. Si no está configurado ExternalURL y el método de autenticación del directorio virtual se ha configurado a la autenticación integrada de Windows, CAS-01 enviará mediante proxy la solicitud de usuario al servidor de acceso de cliente especificado por la propiedadInternalURL.

Conexiones de proxy para el panel de control de Exchange

Exchange 2010 proporciona una interfaz basada en la web para los usuarios y los administradores de la organización para configurar valores de su buzón de correo o para la organización. El acceso al panel de control de Exchange (ECP) se obtiene mediante el menú de opciones en Outlook Web App o en Outlook 2010al seleccionar opciones de correo de voz, solicitar información de seguimiento de mensajes o configurar notificaciones móviles. Si selecciona cualquiera de estas opciones en Outlook inicia una sesión de explorador web.

El destino de la sesión dependerá del estado actual de la conexión del cliente Outlook. Si el cliente Outlook se conecta mediante RPC por TCP, el cliente se conecta al valor de InternalURL del directorio virtual de ECP. Si el cliente se conecta mediante Anywhere de Outlook, el cliente de Outlook iniciará una sesión de explorador. La sesión de explorador solo intentará conectarse con el valor ExternalURL del directorio virtual de ECP. Las direcciones URL se proporcionan al Outlook mediante el servicio de detección automática.

Cuando el cliente interno se conecta mediante TCP, la sesión ECP siempre se conectará a un servidor de acceso de cliente en el mismo sitio de Active Directory del buzón de correo del usuario. El proxy no se usa en este escenario. Cuando el cliente que se encuentra fuera de la red corporativa usa Anywhere de Outlook para conectarse, el cliente abre una sesión de explorador hacia la URL externa del directorio virtual de ECP hacia la URL externa de un sitio con conexión a Internet de Active Directory si el buzón de correo del usuario se ubica en un sitio sin conexión a Internet.

La lógica de proxy para el ECP es idéntico para Outlook Web App. Si el buzón de correo del usuario se encuentra en un servidor de buzón de correo Exchange 2010 en el mismo sitio de Active Directory que el servidor de acceso de cliente que recibe la solicitud, ese servidor de acceso de cliente proporcionará acceso al buzón de correo. Si el buzón de correo del usuario se encuentra en un servidor de buzón Exchange 2010 en un sitio diferente de Active Directory, el servidor de acceso de cliente localiza un servidor de acceso de cliente ubicado en el mismo sitio de Active Directory que el servidor de buzón de correo del usuario. El servidor de acceso de cliente original enviará mediante proxy la solicitud de usuario a ese servidor de acceso de cliente.

El ECP realiza redirección, pero, a menos que el usuario escriba de manera explícita la URL para tener acceso al ECP, es poco habitual que se realice. Si el usuario ingresa al ECP desde Outlook Web App, Outlook Web App es responsable por asegurarse que el usuario usa la URL correcta. Si el usuario usa Outlook 2010, Outlook y el servicio de detección automática son responsables por asegurarse que el usuario usa la URL correcta para el ECP.

Introducción a la función de proxy

Función de proxy para servicios web de Exchange

Los servicios web de Exchange proporcionan una interfaz de mensajería XML que le permiten administrar elementos de almacenamiento de Exchangey tener acceso a la funcionalidad de servidores de Exchange de aplicaciones de clientes. Desde el proxy, la redirección y la perspectiva de clientes de esta funcionalidad se usan usualmente en el contexto de los siguientes casos:

• Solicitudes de servicio de disponibilidad

• Solicitudes de detección automática

• Establecer y comprobar el estado de las respuestas automáticas (OOF)

La aplicación escrita mediante servicios web de Exchange puede usar comportamiento mediante proxy para tareas como configurar un mensaje de respuesta automática (Fuera de la oficina), que a continuación se enviará por proxy entre sitios de Active Directory, si fuera necesario. 

Los siguientes pasos muestran de qué manera las solicitudes entrantes se manejan para un usuario que realiza un pedido de servicio de disponibilidad a un servidor de acceso de cliente de Exchange 2010 llamado CAS-01. El usuario usa Outlook Web App para verificar la disponibilidad de otro usuario en la misma organización de Exchange.

1. El CAS-01 consulta a Active Directory para determinar la ubicación del buzón de correo del usuario y la versión de Microsoft Exchange instalada en el servidor de buzón de correo.

2. Si el buzón de correo de usuario se encuentra en un servidor de Exchange 2003, Outlook Web App realiza una conexión de HTTP al directorio virtual público del servidor Exchange 2003 y recupera la información solicitada de la carpeta del sistema de disponibilidad.

3. Si el buzón de correo del usuario es una servidor de buzones de Exchange 2007, se devuelve un error al usuario. En cualquier organización de Exchange que contiene buzones en un servidor de buzones de Exchange 2007, debe haber un servidor de acceso de cliente de Exchange 2007 accesible de manera externa. El servicio Detección automática es responsable de devolver la URL de servicios web Exchange al cliente. Esta URL debe coincidir con la versión del servidor de buzón en el que se encuentra el buzón del usuario.

4. Si el buzón de correo se encuentra en un servidor de buzón de correo de Exchange 2010 en el mismo sitio de Active Directory que CAS-01, CAS-01 tendrá acceso al buzón de correo por sí mismo para recuperar la información solicitada. Si el buzón de correo del usuario se encuentra en un servidor de buzón de correo de Exchange 2010 en un sitio Active Directory diferente, CAS-01 enviará mediante proxy a un servidor de acceso de cliente en ese sitio de Active Directory mediante el FQDN especificado por la propiedad InternalURL del directorio virtual EWS.

   Importante

   El servidor de acceso de cliente de Exchange enviará mediante proxy las solicitudes de servicio de disponibilidad desde un servidor a otro independientemente de si la propiedadExternalURL está o no configurada.

   Importante

   Algunas aplicaciones de servicios web Exchange usan métodos web tales como GetEvents y Unsubscribe, que tienen una fuerte afinidad con el servidor de acceso de cliente. Cuando un servidor de acceso de cliente debe enviar por proxy una de estas solicitudes hacia otro sitio de Active Directory, puede usar la propiedadInternalNLBBypassURLdel servidor de acceso de cliente, que siempre deberá estar configurado para el FQDN del servidor del host en sí mismo. De este modo, se asegura que el servidor de acceso de cliente que realiza la solicitud pueda mantener la afinidad con un servidor de acceso de cliente específico del sitio de destino Active Directory.

Los servicios web de Exchange en sí mismos no proporcionan funcionalidad de redirecciones debido a que el servicio de detección automática que se usa para proporcionarle las URL a una aplicación proporciona las URL necesarias para tener acceso a un buzón de correo específico. Por ejemplo, cuando se mueve un buzón de correo entre sitios de Active Directory, Outlook recibe las URL actualizadas específicas del sitio Active Directory del servicio de detección automática cuando luego envía una consulta. A veces, puede provocar que el cliente realice solicitudes de servicio de disponibilidad a un servidor de acceso de cliente en un sitio de Active Directory diferente al buzón de correo en el que se encuentra. Sin embargo, debido a que el servicio de disponibilidad aún procesará las solicitudes y las enviará por proxy según fuera necesario, no afectará al usuario.

Conexiones de proxy para POP3 e IMAP4

Exchange 2010 puede enviar por proxy sesiones de POP3 e IMAP4 entre servidores de acceso de cliente y sitios de Active Directory.

Los siguientes pasos muestran de qué forma se manejan las solicitudes entrantes para un usuario que realiza una solicitud a un servidor de acceso de cliente Exchange 2010 llamado CAS-01 con un cliente POP3.

1. El CAS-01 consulta a Active Directory para determinar la ubicación del buzón de correo del usuario y la versión de Microsoft Exchange instalada en el servidor de buzón de correo.

2. Si el buzón de correo del usuario es un servidor de Exchange 2003, CAS-01 enviará por proxy la conexión al servicio POP3 que se ejecuta en el servidor de Exchange 2003 que hospeda el buzón de correo del usuario.

3. Si el buzón de correo del usuario se encuentra en un servidor de buzón de correo de Exchange 2007, CAS-01 localizará el servidor de acceso de cliente de Exchange 2007 en el mismo sitio de Active Directory del servidor de buzón de correo del usuario, que podrá encontrarse en el mismo sitio de Active Directory que CAS-01. CAS-01 enviará por proxy la solicitud al servidor de acceso de cliente.

4. Si el buzón de correo se encuentra en un servidor de buzón de correo de Exchange 2010 en el mismo sitio de Active Directory que CAS-01, CAS-01 tendrá acceso al buzón de correo por sí mismo. Si el buzón de correo del usuario se encuentra en un servidor de buzón de correo de Exchange 2010 en un sitio de Active Directory diferente, CAS-01 enviará mediante proxy a un servidor de acceso de cliente en ese sitio mediante el FQDN especificado por la propiedad InternalConnectionSettings de la configuración POP de ese servidor.

   Importante

   No existen configuraciones InternalURL o ExternalURL para los servicios POP3 o IMAP4 y el servidor de acceso de cliente de Exchange 2010 enviará por proxy las solicitudes de servicio POP3 e IMAP4 de un servidor al otro cuando sea necesario.

   Importante

   Los servidores de acceso de cliente que intentar enviar por proxy a otro sitio de Active Directory no verifican si el servicio POP3 o IMAP4 en realidad se ejecuta en el servidor de acceso de cliente remoto. Por lo tanto, es importante no solamente asegurarse de que los servicios se ejecuten en cada servidor de acceso de cliente en un sitio de Active Directory remoto, sino considerar el uso del equilibrador de carga para el servicio. Los equilibradores de carga se analizarán más adelante en este tema.

Introducción a la función de proxy

Configuración del proxy

Si el servidor de acceso de cliente tiene conexión a Internet, configure la propiedad ExternalURL en los directorios virtuales /Microsoft-Server-ActiveSync, /OWA, /ECP, y /EWS mediante la Consola de administración (EMC) de Exchange o la Consola de administración (Shell) de Exchange. El directorio virtual de EWS solamente se puede configurar mediante el Shell. La propiedad InternalURL se configura automáticamente durante la configuración inicial de Exchange 2010 y solo se debe cambiar si desea usar una solución de equilibrador de carga. La propiedad ExternalURL debe contener el FQDN registrado para su organización Exchange en DNS.

La siguiente tabla contiene los valores adecuados de las propiedades ExternalURL e InternalURL de un servidor de clientes con conexión a Internet de una organización de Exchange que tiene acceso a Outlook Web App mediante la siguiente URL: https://mail.contoso.com. La segunda tabla contiene los valores adecuados de propiedades ExternalURL e InternalURL de servidores de acceso de cliente sin conexión a Internet en un segundo sitio de Active Directory de la misma organización. Deberá asegurar que el método de autenticación en todos estos directorios virtuales estén configurados con autenticación de Windows integrada. No se admite el envío mediante proxy para directorios virtuales que usan otros métodos de autenticación excepto para POP3 e IMAP4, que usan SSL/TLS y envían por proxy las credenciales de autenticación básicas del usuario.

Configuración de InternalURL y ExternalURL en un servidor de acceso de cliente con conexión a Internet

Servicio de Exchange 2010	Configuración de InternalURL	Configuración de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://mail.contoso.com/OWA
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	https://mail.contoso.com/Microsoft-Server-ActiveSync
Servicios Web Exchange	https://fullyqualifiedcomputername/EWS/Exchange.asmx	https://mail.contoso.com/EWS/Exchange.asmx
Panel de control de Exchange	https://fullyqualifiedcomputername/ECP	https://mail.contoso.com/ECP

Configuración de InternalURL y ExternalURL para servidor de acceso de cliente sin conexión a Internet

Servicio de Exchange 2010	Configuración de InternalURL	Configuración de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	$Null
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	$Null
Servicios Web Exchange	https://fullyqualifiedcomputername/EWS/Exchange.asmx	$Null
Panel de control de Exchange	https://fullyqualifiedcomputername/ECP	$Null

Configuración de la redirección

Si más de uno de sus sitios de Active Directory tienen conexión a Internet, configure la propiedad ExternalURL en los directorios virtuales /OWA y /Microsoft-Server-ActiveSync mediante la EMC o la Consola para permitir la redirección entre ellos. La propiedad InternalURL se configura automáticamente durante la configuración inicial de Exchange 2010 y solo se debe cambiar si desea usar una solución de equilibrador de carga. En las dos tablas siguientes se indican las configuraciones de ExternalURL e InternalURL para servidores de acceso de cliente en dos sitios deActive Directory para una empresa llamada Contoso. Los dos sitios son usa.contoso.com y europe.contoso.com.

Configuración de propiedades de InternalURL y ExternalURL para servidor de acceso de cliente con conexión a Internet en el sitio usa.contoso.com

Servicio de Exchange 2010	Configuración de InternalURL	Configuración de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://usa.contoso.com/OWA
Panel de control de Exchange	https://fullyqualifiedcomputername/ECP	https://usa.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://usa.contoso.com/ Microsoft-Server-ActiveSync
Servicios Web Exchange	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://usa.contoso.com/EWS/Exchange.asmx

Configuración de propiedades de InternalURL y ExternalURL para servidor de acceso de cliente con conexión a Internet en el sitio europe.contoso.com

Servicio de Exchange 2010	Configuración de InternalURL	Configuración de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://europe.contoso.com/OWA
Panel de control de Exchange	https://fullyqualifiedcomputername/ECP	https://europe.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://europe.contoso.com/ Microsoft-Server-ActiveSync
Servicios Web Exchange	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://europe.contoso.com/EWS/Exchange.asmx

Introducción a la función de proxy

Proxy con equilibrio de carga de red

En una organización con varios sitios de Active Directory y varios servidores de acceso de cliente en cada sitio, puede usar el equilibrio de carga de red (NLB) para equilibrar la carga del tráfico entre los servidores de acceso de cliente de cada sitio y para los usuarios que acceden directamente a esos servidores. No basta con implementar un balanceador de carga para garantizar que el tráfico se equilibre de manera eficaz. También se debe realizar una configuración adicional de propiedades InternalURL y ExternalURL. Recomendamos incluir en una matriz de equilibrado de carga únicamente los servidores de acceso de cliente del mismo sitio de Active Directory. NLB se puede implementar en un sitio de Active Directory con conexión a Internet y un sitio de Active Directory sin conexión a Internet.

La siguiente tabla enumera las configuraciones que debe configurar para los directorios virtuales de servidores de acceso de cliente en sitios con y sin conexión a Internet. El FQDN de NLB se debe configurar en DNS para resolver el servicio o el dispositivo de equilibrio de carga. La solución de equilibrio de carga después será responsable de reenviar el tráfico a los servidores de acceso de cliente adecuados.

Configuración de directorio virtual en servidores de acceso de cliente en una organización que usa NLB

Directorio virtual /servicio	InternalURL	ExternalURL (Sitio de Active Directory con conexión a Internet)	ExternalURL (Sitio de Active Directory sin conexión a Internet)
/OWA	FQDN de NLB (consulte las instrucciones siguientes)	FQDN de NLB	$null
/ECP	FQDN de NLB (consulte las instrucciones siguientes)	FQDN de NLB	$null
/Microsoft-Server-ActiveSync	FQDN de NLB	FQDN de NLB	$null
/OAB	FQDN de NLB	FQDN de NLB	$null
/EWS	FQDN de NLB	FQDN de NLB	$null
POP/IMAP	(InternalConnectionsSettings) FQDN de NLB	No aplicable	No aplicable

Le recomendamos que utilice las siguientes instrucciones para configurar la propiedad InternalURL:

• La propiedad InternalURL para los directores virtuales /OWA y /ECP en todos los servidores de acceso de cliente en un sitio de Active Directory puede configurarse en FQDN de NLB de los servidores en ese sitio si existen usuarios internos de Outlook 2010.

• Si un servidor de acceso de cliente en un sitio de Active Directory es el destino de una solicitud proxy de ECP u Outlook Web App desde un servidor de acceso de cliente en otro sitio de Active Directory, asegúrese de configurar su balanceador de carga para garantizar que se mantenga la afinidad. Esto sucede porque el servidor de acceso de cliente en el sitio con conexión a Internet no puede seleccionar un servidor para cada solicitud individual y mantener su propia afinidad

La siguiente tabla enumera las diversas configuraciones de autenticación necesarias en directorios virtuales de una organización que usa equilibrio de carga de red (NLB). En el caso de una organización que usa NLB, la URL de NLB se usa en lugar de una URL de servidor de acceso de cliente específico para la conectividad de clientes.

Las configuraciones de autenticación de directorios virtuales de servidores de acceso de clientes en una organización que usa URL de NLB para tolerancia de errores y equilibrio de carga.

Directorio virtual /servicio	Sitio de Active Directory con conexión a Internet	Sitio de Active Directory sin conexión a Internet
/OWA	Si se usa Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) o Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG), y está habilitada la autenticación basada en formularios, use autenticación básica o integrada de Windows, según la configuración de delegación de reglas de firewall. Si el tráfico de Internet se traslada al servidor de acceso de clientes sin autenticación previa, use la autenticación basada en formularios. Se debe habilitar el mismo método de autenticación en los directorios virtuales /OWA y /ECP.	Autenticación integrada de Windows
/ECP	Si se usa Forefront TMG o Forefront UAFG, y está habilitada la autenticación basada en formularios, use la autenticación básica o integrada de Windows, según la configuración de delegación de reglas de firewall. Si el tráfico de Internet se traslada al servidor de acceso de clientes sin autenticación previa, use la autenticación basada en formularios. Se debe habilitar el mismo método de autenticación en los directorios virtuales /OWA y /ECP.	Autenticación integrada de Windows
/Microsoft-Server-ActiveSync	Autenticación básica.	Autenticación básica (las conexiones proxy se realizan mediante el directorio virtual de sub /Proxy).
/OAB	Autenticación de Windows básica o integrada, según las configuraciones de delegación de reglas de firewall.	Autenticación básica o integrada Windows según la configuración de la delegación de reglas de firewall (las solicitudes de la OAB nunca se envían por proxy entre los sitios de Active Directory. Este directorio virtual es utilizado solamente por clientes de Outlook).
/EWS	Básica (opcional: en función de la configuración de delegación de regla de firewall). Necesita autenticación integrada de Windows.	Autenticación integrada de Windows
POP/IMAP	Según sea necesario mediante el método de conexión de cliente.	Según sea necesario mediante el método de conexión de cliente

Introducción a la función de proxy

Lógica de equilibrio de carga usada por los servidores de acceso de clientes al enviar por proxy entre sitios de Active Directory

Cuando existen varios servidores de acceso de clientes en el sitio que serán el objetivo de un intento de proxy y el servidor en donde se ubica el buzón de correo del usuario es un servidor de acceso de cliente combinado, el servidor de acceso de cliente del sitio de Active Directory de origen siempre elegirá ese servidor de acceso de cliente combinado con el servidor de buzón de correo como objetivo del intento de proxy.

Outlook Web App, ECP y servicios web de Exchange manejan el equilibrio de carga de manera diferente comparado con el servicio de disponibilidad y Exchange ActiveSync. Outlook Web App, ECP y los servicios web de Exchange implementan su propio equilibrio de carga cuando se implementan en varios servidores de acceso de cliente dentro del mismo sitio de Active Directory. Si un usuario intenta obtener acceso a Outlook Web App a través de https://www.contoso.com/owa y se envía por proxy a CAS-01, la próxima vez que el usuario intente obtener acceso a Outlook Web App volverán a enviarlo por proxy a CAS-01, aunque CAS-02 tenga menos conexiones simultáneas. Eso se hace para garantizar que se puedan completar transacciones de larga duración sin realizar nuevamente reautenticación ni solicitar datos. Esto se conoce como afinidad. Si CAS-01 no está disponible, el usuario se enviará por proxy a CAS-02 y posiblemente se le solicite reautenticación al usuario.

Los servicios web de Exchange pueden mantener la afinidad cuando se envían por proxy entre sitios de Active Directory a pesar de la propiedadInternalURL del servidor de destino que se configura con URL de NLB. Esto ocurre porque el servidor de acceso de cliente que realiza la solicitud de proxy de una aplicación que requiere afinidad usa la propiedad InternalNLBBypassURL en el servidor de destino. La propiedad InternalNLBBypassURL se configura con el FQDN del servidor de destino y usa la autenticación de Windows de manera predeterminada.

El proceso es distinto para Exchange ActiveSync. Cuando el servidor de acceso de cliente con conexión a Internet envía por proxy una solicitud a un cliente de acceso de cliente sin conexión a Internet, el servidor de acceso de cliente solicitante buscará un servidor de acceso de cliente en el sitio de destino e intentará conectarse a éste mediante el valor configurado en la propiedadInternalURL. Si el servidor no responde, se producirá un error en la solicitud y se enviará un mensaje de error al cliente. Recomendamos implementar equilibrio de carga por turnos dentro de un arreglo de NLB mediante la configuración de la propiedad InternalURL con un valor de equilibrio de carga.

También recomendamos equilibrio de carga para el servicio de disponibilidad. Las solicitudes del servicio de disponibilidad no tienen por qué mantener su estado de conexión. En otras palabras, se pueden enviar por proxy dos solicitudes de servicio de disponibilidad consecutivas del mismo cliente a diferentes servidores de acceso de cliente en su sitio de destino de Active Directory sin que ello afecte el rendimiento; no habrá problemas de autenticación si la propiedad InternalURL se configura con un valor de equilibrio de carga. Además, la configuración de la propiedad InternalURL con un valor de equilibrio de carga beneficia internamente a todos los clientes Outlook 2007 y Outlook 2010 porque el servicio de detección automática les proporciona a estos clientes el valor del equilibrio de carga configurado en la propiedadInternalURL a fin de permitirles completar sus solicitudes de servicio de disponibilidad.

Para obtener más información acerca del equilibrio de carga de red, consulte Descripción del equilibrio de carga en Exchange 2010.

Introducción a la función de proxy

Resumen de métodos de acceso de cliente

En la tabla siguiente se resumen los protocolos usados para obtener acceso a Exchange 2010 y cómo se emplean para las funciones de proxy y redirección.

Protocolos de acceso de cliente para redirección y proxy

Protocolo/Aplicación	Redirección admitida entre servidores de acceso de cliente	Proxy admitido entre servidores de acceso de cliente	Comments
Outlook Web App	Sí	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para poder usar Outlook Web App.
Panel de control de Exchange	Sí	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para usar el ECP.
Exchange ActiveSync	Sí	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para poder usar Exchange ActiveSync.
Servicios Web Exchange	No (el servicio de detección automática le proporciona a la aplicación el valor correcto de ExternalURL)	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para poder usar los servicios web de Exchange.
Servicio de disponibilidad	No (el servicio de detección automática le proporciona a la aplicación el valor correcto de ExternalURL)	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para poder usar el servicio Disponibilidad.
POP3 e IMAP4	No	Sí	Debe haber un servidor de acceso de cliente en cada sitio de Active Directory para usar POP3 e IMAP4.

Rendimiento y escalabilidad de proxy

En un entorno de Exchange 2010 con proxy, si los servidores de acceso de cliente reciben muchas solicitudes simultáneas, el rendimiento puede bajar. Normalmente este problema se debe a la falta de subprocesos y conexiones disponibles a causa de las solicitudes de servicios web desde ASP.NET. Esto puede provocar que el servidor de acceso de cliente deniegue las solicitudes o presente una latencia alta cuando se procesan las solicitudes.

Para resolver estos problemas, se pueden configurar diversos parámetros de ASP.NET editando el archivo Machine.config en los equipos que hospedan los servidores de acceso de cliente. Para obtener más información acerca de la configuración de estos parámetros, consulte el artículo 821268 de Microsoft Knowledge Base, Retenciones, mal rendimiento e interbloqueos cuando hace solicitudes de servicios web desde aplicaciones ASP.NET.

Dos de los parámetros que se explican en el artículo de Knowledge Base 821268 se deben configurar de forma distinta en un entorno de proxy de Exchange 2010. Se recomienda permitir 36 subprocesos por procesador y establecer el valor de maxconnections en 2000.

Para obtener más información sobre el rendimiento de servidores, consulte Cómo administrar .NET Framework en Windows Server 2003.

 © 2010 Microsoft Corporation. Reservados todos los derechos.