19

We have a load-balanced Exchange 2013 SP1 cluster, running MAPI over HTTP.

Client connectivity inside our own network works just fine, while clients connected over Direct Access does not connect. The Outlook logs on the client show absolutely no error at all.

The Direct Access server is running 2012 R2, the clients are all Windows 8.1. Everything is patched.

I've been searching like crazy the last couple of weeks, and the only interesting hits I get are about TMG 2010 (UAG) filtering out the requests due to the source IP changing (the exchange load balancer). There is a Knowledge Base Article (982604) that describes this, and a rather hefty blog post about the issue from premier support, but sadly the script does not work on our server since it's not TMG and it's Windows Server 2012 R2..

I'm at a loss here. I'll give this question a week, then I'll raise a premier support case with Microsoft.

pauska
  • 19,532
  • 4
  • 55
  • 75
  • Do you mean MAPI over HTTP? What version of Outlook? Can you post details or screenshots from the DA clients Outlook, showing Connection Status and Test Email Autoconfiguration? What are you using for load-balancing? – mfinni Jun 17 '14 at 15:12
  • @mfinni Sorry, of course MAPI :-) Outlook 2013 SP1 with the latest patches. Our load-balancer is KEMP VLM-1000. I'll try to post a screenshot, but the office install is Norwegian.. will probably not make a lot of sense to you? – pauska Jun 17 '14 at 15:14
  • Well, what we're looking for is if the client is trying to connect to the internal Autodiscover URL (as it should be, using DA) or the external one, which might fail and could be causing your problems. A lot of it could come down to your DNS config. Of if autodiscover is working correctly, but some part of the connection is failing. – mfinni Jun 17 '14 at 15:35
  • 1
    @mrfinni I've checked this, as we're not using forced tunneling. We have a split-brain DNS with single namespace, so all the internal and external domains are explicitly tunneled. In reality this means that the client can't resolve any of our external DNS entries. I'll install an english version of Outlook when I have the time.. – pauska Jun 17 '14 at 15:38
  • What does the Outlook "Connection Status" dialog look like when it's failing? The Autodiscover log would be nice to see, too. – Evan Anderson Jun 26 '14 at 18:50
  • A Wireshark capture at the faulty client will show the DNS actions, the destination IPs, and the prematurely closed TCP connections; their ports will tell you about the server module/s rejecting the connection. – Pat Jun 30 '14 at 11:43
  • What build of Exchange 2013? I'm not familiar with "KEMP VLM-1000" the I had a similar issue with pre SP1 where RPC doesn't work through – Rhys Evans Jun 30 '14 at 20:36
  • If you disable all the Exchange servers in the VLM except for one, does it work? – longneck Jun 30 '14 at 21:00
  • 1
    EvanAnderson: I'll provide screenshots and logs later this day. Aceth: Sorry, it's SP1 (clarified in the Q). longneck: It does not make a difference. I know that the LB re-writes the source IP (nat), and I'm thinking that this is where it breaks.. – pauska Jul 01 '14 at 10:03
  • I'd capture traffic on both sides of the load-balancer, just to confirm that the requests from the client are getting there. Tracing traffic on the DirectAccess client, using the `netsh trace start scenario=directaccess report=yes capture=yes` command would probably be helpful to. The articles re: TMG feel like a red-herring to me, because you're doing MAPI over HTTP. My gut says you're going to run into something simple like a name resolving to an external vs. internal address, etc. I'd certainly love to know how this turns out. – Evan Anderson Jul 03 '14 at 15:47

2 Answers2

1

I've hit this sort of problem previously(on a HAproxy based solution), in my case it was Exchange 2010 and ISA 2006 Server with the RPC filter enabled. We disabled the RPC filter and happy days again...

I did a little searching around myself and I found this :

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

Which suggest problems with Outlook, DirectAccess and tunnel mode that never got resolved(other than a possible client reg hack..) so I did wonder if it was the same thing. he's got his case ID in the comments so if you do go to MS you might be able to add some weight to your case.

Aaron West
  • 11
  • 1
  • I also found a lot of posts about RPC filter and ISA, but sadly we use neither. Our environment now runs pure HTTP MAPI, so there should not be any RPC involved at all. I gave up on the whole problem for now, excluding Outlook traffic from the DA tunnel. – pauska Sep 22 '14 at 07:52
0

What build of Exchange 2013 are the CAS servers running? I'm not familiar with "KEMP VLM-1000" but I have load balanced exchange 2013 using NGINX and came in to a similar issue with pre Exchange 2013 SP1 where RPC doesn't work load balanced over HTTPS.

In the recent release of Exchange 2013 SP1 they've implemented MAPI over HTTPS which is meant to address this issue - I haven't tested it yet technet link is below

Exchange 2013 SP1 - MAPI over HTTPS

Let me know how you get on as I haven't got round to implementing this yet as I just used haproxy to TCP load balance between the CAS servers.

Rhys Evans
  • 919
  • 8
  • 23
  • Hi. We're using MAPI over HTTPS on SP1 (and RPC over HTTPS for Pre-2013 clients). This has all been covered in the question. – pauska Jul 01 '14 at 09:40
  • Only because you've just edited it! lol. Have you done the steps described in the link? Have you tried testing and looking in the exchange mapi log files.. %ExchangeInstallPath%Logging\MAPI Client Access\ %ExchangeInstallPath%Logging\HttpProxy\Mapi\ – Rhys Evans Jul 01 '14 at 10:43
  • If it's possible, try swapping out your load balancer for NGINX (http://www.turnkeylinux.org/nginx-php-fastcgi - already installed and nicely configured) add a new config for exchange. The one I intend on implementing for the MAPI over HTTP is based on .. https://gist.github.com/taddev/7275873 – Rhys Evans Jul 01 '14 at 10:46
  • or if you don't need a HTTP based load balancer trying using HAProxy that's what I did and works good. – Rhys Evans Jul 01 '14 at 10:47
  • Replacing our loadbalancer just because Outlook connectivity breaks through DirectAccess is not an option.. We have paid a lot of money for it, and it's loadbalancing everything else we run (RDS farms, gateway servers, proxies etc) perfectly. It's just under DA that Outlook breaks. I haven't checked those logs no, so I'll do that later today when I run a new test from home. – pauska Jul 01 '14 at 10:52
  • Fair enough, I didn't realise it was a commercial product. Also to clarify both the onsite and remote connections funneled through the Load balancer and onsite works fine? Let's see what the logs say - Is there an option to forward the IP headers? or convert it to TCP based routing instead? – Rhys Evans Jul 01 '14 at 11:04
  • Absolutely all traffic (both transparent load-balanced or just routed) works excellent through the load-balancer, both internal and external through our firewalls. It's only Outlook Connectivity through a _DirectAccess_ tunnel that fails. The only option I can see is to disable layer 7 transparency, which will stop it from re-writing source headers. I'll try this later tonight. – pauska Jul 01 '14 at 11:06