Outlook ne parvient pas à se connecter à un cluster Exchange 2013 à charge équilibrée via Direct Access 2012 R2

Nous avons un cluster Exchange 2013 SP1 à charge équilibrée, exécutant MAPI sur HTTP.

La connectivité client à l'intérieur de notre propre réseau fonctionne très bien, tandis que les clients connectés via Direct Access ne se connectent pas. Les journaux Outlook sur le client ne montrent absolument aucune erreur.

Le serveur d'accès direct exécute 2012 R2, les clients sont tous Windows 8.1. Tout est patché.

J'ai cherché comme un fou ces deux dernières semaines, et les seuls résultats intéressants que j'ai obtenus concernent TMG 2010 (UAG) filtrant les demandes en raison du changement d'IP source (l'équilibreur de charge d'échange). Il existe un article de la base de connaissances (982604) qui décrit cela, et un article de blog plutôt lourd sur le problème de la prise en charge Premier, mais malheureusement, le script ne fonctionne pas sur notre serveur car il ne s'agit pas de TMG et de Windows Server 2012 R2.

Je suis perdu ici. Je donnerai cette question une semaine, puis je soulèverai un premier cas de support avec Microsoft.

exchange load-balancing exchange-2013 direct-access pauska
la source

Voulez-vous dire MAPI sur HTTP? Quelle version d'Outlook? Pouvez-vous publier des détails ou des captures d'écran des clients DA Outlook, montrant l'état de la connexion et la configuration automatique des e-mails? Qu'utilisez-vous pour l'équilibrage de charge?

mfinni

@mfinni Désolé, bien sûr MAPI :-) Outlook 2013 SP1 avec les derniers correctifs. Notre équilibreur de charge est KEMP VLM-1000. J'essaierai de poster une capture d'écran, mais l'installation au bureau est norvégienne .. ça n'aura probablement pas beaucoup de sens pour vous?

pauska

Eh bien, ce que nous recherchons, c'est si le client essaie de se connecter à l'URL de découverte automatique interne (comme il se doit, en utilisant DA) ou à l'externe, ce qui pourrait échouer et causer vos problèmes. Une grande partie de cela pourrait se résumer à votre configuration DNS. Si la découverte automatique fonctionne correctement, mais une partie de la connexion échoue.

mfinni

@mrfinni J'ai vérifié cela, car nous n'utilisons pas de tunneling forcé. Nous avons un DNS à cerveau divisé avec un seul espace de noms, donc tous les domaines internes et externes sont explicitement tunnelés. En réalité, cela signifie que le client ne peut résoudre aucune de nos entrées DNS externes.

J'installerai

EvanAnderson: Je fournirai des captures d'écran et des journaux plus tard dans la journée. Aceth: Désolé, c'est SP1 (clarifié dans le Q). longneck: Cela ne fait aucune différence. Je sais que le LB réécrit l'IP source (nat), et je pense que c'est là que ça casse ..

pauska

Réponses:

J'ai déjà rencontré ce type de problème (sur une solution basée sur HAproxy), dans mon cas, c'était Exchange 2010 et ISA 2006 Server avec le filtre RPC activé. Nous avons désactivé le filtre RPC et encore des jours heureux ...

J'ai fait une petite recherche autour de moi et j'ai trouvé ceci:

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

Ce qui suggère des problèmes avec Outlook, DirectAccess et le mode tunnel qui n'ont jamais été résolus (à part un éventuel piratage de reg client ..) alors je me suis demandé si c'était la même chose. il a son ID de cas dans les commentaires, donc si vous allez à MS, vous pourrez peut-être ajouter du poids à votre cas.

Aaron West
la source

J'ai également trouvé beaucoup de messages sur le filtre RPC et ISA, mais malheureusement nous n'utilisons ni l'un ni l'autre. Notre environnement exécute maintenant du MAPI HTTP pur, donc aucun RPC ne devrait être impliqué du tout. J'ai abandonné tout le problème pour l'instant, à l'exclusion du trafic Outlook du tunnel DA.

pauska

Quelle version d'Exchange 2013 les serveurs CAS exécutent-ils? Je ne suis pas familier avec "KEMP VLM-1000", mais j'ai Exchange 2013 à charge équilibrée à l'aide de NGINX et j'ai rencontré un problème similaire avec Exchange 2013 SP1 antérieur où RPC ne fonctionne pas à charge équilibrée sur HTTPS.

Dans la récente version d'Exchange 2013 SP1, ils ont implémenté MAPI sur HTTPS qui est destiné à résoudre ce problème - je ne l'ai pas encore testé Le lien technet est ci-dessous

Exchange 2013 SP1 - MAPI sur HTTPS

Faites-moi savoir comment vous vous en sortez, car je n'ai pas encore mis en œuvre cela, car je viens d'utiliser l'équilibrage de charge haproxy vers TCP entre les serveurs CAS.

Rhys Evans
la source

Salut. Nous utilisons MAPI sur HTTPS sur SP1 (et RPC sur HTTPS pour les clients antérieurs à 2013). Tout cela a été couvert dans la question.

pauska

Seulement parce que vous venez de le modifier! lol. Avez-vous suivi les étapes décrites dans le lien? Avez-vous essayé de tester et de consulter les fichiers journaux mapi d'échange.% ExchangeInstallPath% Logging \ MAPI Client Access \% ExchangeInstallPath% Logging \ HttpProxy \ Mapi \

Rhys Evans

Si c'est possible, essayez d'échanger votre équilibreur de charge pour NGINX ( turnkeylinux.org/nginx-php-fastcgi - déjà installé et bien configuré) ajoutez une nouvelle configuration pour l'échange. Celui que j'ai l'intention d'implémenter pour le MAPI sur HTTP est basé sur .. gist.github.com/taddev/7275873

Rhys Evans

ou si vous n'avez pas besoin d'un équilibreur de charge basé sur HTTP pour essayer d'utiliser HAProxy, c'est ce que j'ai fait et qui fonctionne bien.

Rhys Evans

Le remplacement de notre équilibreur de charge simplement parce que la connectivité Outlook passe par DirectAccess n'est pas une option. Nous avons payé beaucoup d'argent pour cela, et il équilibre parfaitement tout le reste que nous exécutons (fermes RDS, serveurs de passerelle, proxys, etc.). C'est juste sous DA qu'Outlook se casse. Je n'ai pas vérifié ces journaux non, donc je le ferai plus tard dans la journée lorsque j'effectuerai un nouveau test à domicile.

pauska