Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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 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 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 at 15:35
@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 at 15:38
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 1 at 10:03

2 Answers 2

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 :


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.

share|improve this answer
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 2 hours ago

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.

share|improve this answer
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 1 at 9: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\ –  Aceth Jul 1 at 10:43
If it's possible, try swapping out your load balancer for NGINX (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 .. gist.github.com/taddev/7275873 –  Aceth Jul 1 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. –  Aceth Jul 1 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 1 at 10:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.