Outlook no puede conectarse a un clúster de Exchange 2013 con equilibrio de carga a través de Direct Access 2012 R2

Tenemos un clúster de Exchange 2013 SP1 con equilibrio de carga, que ejecuta MAPI sobre HTTP.

La conectividad del cliente dentro de nuestra propia red funciona bien, mientras que los clientes conectados a través de Acceso directo no se conectan. Los registros de Outlook en el cliente no muestran absolutamente ningún error.

El servidor de acceso directo ejecuta 2012 R2, todos los clientes son Windows 8.1. Todo está remendado.

Las últimas semanas he estado buscando como loco, y los únicos éxitos interesantes que recibo son sobre TMG 2010 (UAG) filtrando las solicitudes debido al cambio de IP de origen (el equilibrador de carga de intercambio). Hay un artículo de Knowledge Base (982604) que describe esto, y una publicación de blog bastante importante sobre el problema del soporte principal, pero lamentablemente el script no funciona en nuestro servidor ya que no es TMG y es Windows Server 2012 R2.

Estoy perdido aquí. Daré esta pregunta una semana, luego plantearé un caso de soporte principal con Microsoft.

exchange load-balancing exchange-2013 direct-access pauska
fuente

¿Te refieres a MAPI sobre HTTP? ¿Qué versión de Outlook? ¿Puede publicar detalles o capturas de pantalla de los clientes DA de Outlook, que muestran el estado de la conexión y la configuración automática de correo electrónico de prueba? ¿Qué estás usando para equilibrar la carga?

mfinni

@mfinni Lo siento, por supuesto MAPI :-) Outlook 2013 SP1 con los últimos parches. Nuestro equilibrador de carga es KEMP VLM-1000. Intentaré publicar una captura de pantalla, pero la instalación de la oficina es noruega ... ¿probablemente no tenga mucho sentido para ti?

pauska

Bueno, lo que estamos buscando es si el cliente está intentando conectarse a la URL de detección automática interna (como debería ser, usando DA) o la externa, lo que podría fallar y podría estar causando sus problemas. Mucho de esto podría deberse a su configuración de DNS. De si la detección automática funciona correctamente, pero alguna parte de la conexión falla.

mfinni

@mrfinni He comprobado esto, ya que no estamos utilizando túneles forzados. Tenemos un DNS de cerebro dividido con un solo espacio de nombres, por lo que todos los dominios internos y externos están explícitamente tunelizados. En realidad, esto significa que el cliente no puede resolver ninguna de nuestras entradas DNS externas. Voy a instalar una versión Inglés de Outlook cuando tengo el tiempo ..

pauska

EvanAnderson: Proporcionaré capturas de pantalla y registros más adelante este día. Aceth: Lo siento, es SP1 (aclarado en la Q). cuello largo: no hace la diferencia. Sé que el LB reescribe la IP de origen (nat), y estoy pensando que aquí es donde se rompe ...

pauska

Respuestas:

He encontrado este tipo de problema anteriormente (en una solución basada en HAproxy), en mi caso fue Exchange 2010 e ISA 2006 Server con el filtro RPC habilitado. Desactivamos el filtro RPC y felices días otra vez ...

Hice un poco de búsqueda a mi alrededor y encontré esto:

http://geek.martinwahlberg.com/problem-using-forced-tunneling-mode-in-directaccess

Lo que sugiere problemas con Outlook, DirectAccess y el modo de túnel que nunca se resolvieron (aparte de un posible hack de registro de cliente ...), así que me pregunté si era lo mismo. él tiene su identificación de caso en los comentarios, por lo que si va a MS podría agregar algo de peso a su caso.

Aaron West
fuente

También encontré muchas publicaciones sobre el filtro RPC y el ISA, pero lamentablemente no usamos ninguno. Nuestro entorno ahora ejecuta HTTP MAPI puro, por lo que no debería haber ningún RPC involucrado en absoluto. Renuncié a todo el problema por ahora, excluyendo el tráfico de Outlook desde el túnel DA.

pauska

¿Qué compilación de Exchange 2013 están ejecutando los servidores CAS? No estoy familiarizado con "KEMP VLM-1000", pero tengo un intercambio de carga equilibrada 2013 usando NGINX y tuve un problema similar con el SP1 anterior a Exchange 2013 donde RPC no funciona con carga equilibrada sobre HTTPS.

En el reciente lanzamiento de Exchange 2013 SP1, implementaron MAPI sobre HTTPS, que está destinado a solucionar este problema. Todavía no lo he probado.

Exchange 2013 SP1 - MAPI sobre HTTPS

Déjame saber cómo te va, ya que todavía no he podido implementar esto, ya que solo utilicé el equilibrio de carga de haproxy a TCP entre los servidores CAS.

Rhys Evans
fuente

Hola. Estamos utilizando MAPI sobre HTTPS en SP1 (y RPC sobre HTTPS para clientes anteriores a 2013). Todo esto ha sido cubierto en la pregunta.

pauska 01 de

¡Solo porque lo acabas de editar! jajaja ¿Has realizado los pasos descritos en el enlace? ¿Ha intentado probar y buscar en los archivos de registro de mapi de Exchange ..% ExchangeInstallPath% Logging \ MAPI Client Access \% ExchangeInstallPath% Logging \ HttpProxy \ Mapi \

Rhys Evans

Si es posible, intente cambiar su equilibrador de carga por NGINX ( turnkeylinux.org/nginx-php-fastcgi - ya instalado y bien configurado) agregue una nueva configuración para el intercambio. El que tengo la intención de implementar para el MAPI a través de HTTP se basa en ... gist.github.com/taddev/7275873

Rhys Evans

o si no necesita un equilibrador de carga basado en HTTP que intente usar HAProxy, eso es lo que hice y funciona bien.

Rhys Evans

Reemplazar nuestro equilibrador de carga solo porque la conectividad de Outlook rompe con DirectAccess no es una opción. Hemos pagado mucho dinero por ello, y está equilibrando la carga de todo lo demás que ejecutamos (granjas RDS, servidores de puerta de enlace, servidores proxy, etc.) perfectamente. Es justo debajo de DA que Outlook se rompe. No he verificado esos registros, no, así que lo haré más tarde hoy cuando realizo una nueva prueba desde casa.

pauska 01 de