Outlook non riesce a connettersi a un cluster Exchange 2013 con bilanciamento del carico tramite Direct Access 2012 R2

Abbiamo un cluster Exchange 2013 SP1 con bilanciamento del carico, che esegue MAPI su HTTP.

La connettività client all'interno della nostra rete funziona bene, mentre i client connessi tramite Direct Access non si connettono. I log di Outlook sul client non mostrano assolutamente alcun errore.

Il server di accesso diretto esegue 2012 R2, i client sono tutti Windows 8.1. Tutto è patchato.

Ho cercato come un matto nelle ultime due settimane, e gli unici successi interessanti che ottengo riguardano il TMG 2010 (UAG) che filtra le richieste a causa della modifica dell'IP di origine (il bilanciamento del carico di scambio). C'è un articolo della Knowledge Base (982604) che descrive questo, e un post di blog piuttosto pesante sulla questione dal supporto premier, ma purtroppo lo script non funziona sul nostro server poiché non è TMG ed è Windows Server 2012 R2 ..

Sono in perdita qui. Farò questa domanda una settimana, quindi solleverò un primo caso di supporto con Microsoft.

— pauska
fonte

Intendi MAPI su HTTP? Quale versione di Outlook? È possibile pubblicare dettagli o schermate dai client DA Outlook, che mostrano lo stato della connessione e la configurazione automatica della posta elettronica di prova? Cosa stai usando per il bilanciamento del carico?

— mfinni,

@mfinni Siamo spiacenti, ovviamente MAPI :-) Outlook 2013 SP1 con le ultime patch. Il nostro bilanciamento del carico è KEMP VLM-1000. Proverò a pubblicare uno screenshot, ma l'installazione di Office è norvegese .. probabilmente non avrà molto senso per te?

— pauska,

Bene, quello che stiamo cercando è se il client sta cercando di connettersi all'URL di individuazione automatica interna (come dovrebbe essere, utilizzando DA) o a quello esterno, che potrebbe non riuscire e causare i tuoi problemi. Molte di queste potrebbero dipendere dalla tua configurazione DNS. Se il rilevamento automatico funziona correttamente, ma parte della connessione non riesce.

— mfinni,

@mrfinni L'ho verificato, poiché non stiamo utilizzando il tunneling forzato. Abbiamo un DNS split-brain con un singolo spazio dei nomi, quindi tutti i domini interni ed esterni sono esplicitamente sottoposti a tunnel. In realtà ciò significa che il client non può risolvere nessuna delle nostre voci DNS esterne.

— Installerò

EvanAnderson: fornirò schermate e log più avanti nel corso della giornata. Aceth: Siamo spiacenti, è SP1 (chiarito nella Q). collo lungo: non fa differenza. So che l'LB riscrive l'IP di origine (nat) e sto pensando che questo è dove si rompe ..

— pauska,

Risposte:

In precedenza ho riscontrato questo tipo di problema (su una soluzione basata su HAproxy), nel mio caso era Exchange 2010 e ISA 2006 Server con il filtro RPC abilitato. Abbiamo disabilitato il filtro RPC e di nuovo giorni felici ...

Ho fatto un po 'di ricerche intorno a me stesso e ho trovato questo:

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

Il che suggerisce problemi con Outlook, DirectAccess e la modalità tunnel che non sono mai stati risolti (oltre a un possibile hack del client reg. ..) quindi mi sono chiesto se fosse la stessa cosa. ha l'ID del caso nei commenti, quindi se vai in MS potresti essere in grado di aggiungere un po 'di peso al tuo caso.

— Aaron West
fonte

Ho anche trovato molti post sul filtro RPC e ISA, ma purtroppo non ne usiamo nessuno. Il nostro ambiente ora esegue puro MAPI HTTP, quindi non dovrebbe essere coinvolto alcun RPC. Ho rinunciato all'intero problema per ora, escludendo il traffico di Outlook dal tunnel DA.

— pauska,

Quale build di Exchange 2013 sono in esecuzione i server CAS? Non ho familiarità con "KEMP VLM-1000" ma ho uno scambio bilanciato del carico 2013 con NGINX e ho riscontrato un problema simile con pre Exchange 2013 SP1 in cui RPC non funziona con il bilanciamento del carico su HTTPS.

Nella recente versione di Exchange 2013 SP1 hanno implementato MAPI su HTTPS, che ha lo scopo di risolvere questo problema: non l'ho ancora provato, il collegamento technet è inferiore

Exchange 2013 SP1 - MAPI su HTTPS

Fammi sapere come vai avanti dato che non ho ancora avuto modo di implementarlo, dato che ho appena usato il bilanciamento del carico da haproxy a TCP tra i server CAS.

— Rhys Evans
fonte

Ciao. Stiamo utilizzando MAPI su HTTPS su SP1 (e RPC su HTTPS per i clienti pre-2013). Tutto questo è stato trattato nella domanda.

— pauska,

Solo perché l'hai appena modificato! lol. Hai eseguito i passaggi descritti nel link? Hai provato a testare e cercare nei file di registro di mapi di scambio.% ExchangeInstallPath% Logging \ Accesso client MAPI \% ExchangeInstallPath% Logging \ HttpProxy \ Mapi \

— Rhys Evans

Se possibile, prova a sostituire il bilanciamento del carico con NGINX ( turnkeylinux.org/nginx-php-fastcgi - già installato e ben configurato) aggiungi una nuova configurazione per lo scambio. Quello che intendo implementare per MAPI su HTTP si basa su .. gist.github.com/taddev/7275873

— Rhys Evans

o se non hai bisogno di un bilanciamento del carico basato su HTTP che prova a utilizzare HAProxy è quello che ho fatto e funziona bene.

— Rhys Evans,

Sostituire il nostro bilanciamento del carico solo perché la connettività di Outlook interrompe DirectAccess non è un'opzione .. Abbiamo pagato un sacco di soldi per esso, e sta bilanciando il carico di tutto il resto che eseguiamo (farm RDS, server gateway, proxy ecc.) Perfettamente. È proprio sotto DA che Outlook si rompe. Non ho controllato quei registri no, quindi lo farò più tardi oggi quando eseguo un nuovo test da casa.

— pauska,