Outlook Anywhere is ‘broken’ on IPv6 in Windows Server 2008
Posted by: Kevin Reeuwijk in ExchangeI run Exchange 2007 SP1 on Windows Server 2008 RC1 and have run different beta’s of both products for some time now. In every case, I ran into the following problem: Outlook Anywhere (aka RPC over HTTP) would not work if the RPC-over-HTTP Proxy and the Exchange mailbox were on the same Windows 2008 server. Outlook would fail to connect to the server over the internet with some generic error message. When I was running the same configuration on a Windows 2003 server however, the problem did not occur. Also, if I put the RPC-over-HTTP Proxy on a seperate Windows 2003 server and the mailbox on a Exchange 2007 SP1 on Windows 2008 server, Outlook Anywhere worked just fine. I always thought it was a bug in either Exchange or Windows 2008, but I became convinced the problem was more serious when I still had problems with the official Exchange 2007 SP1 release on Windows 2008 RC1…
Meanwhile, I had already accepted the fact that I had to run the RPC-over-HTTP Proxy on a Windows 2003 machine for now, so that was how my environment was set up. However, when troubleshooting a different problem with Exchange, I stumbled upon the rootcause of the Outlook Anywhere problem! It turns out that the problem is in IPv6 and the way that Windows 2008 (and Vista btw) handles IPv6 as a preferred protocol over IPv4: When I did a “netstat -a -n” on my Windows 2008 machine, I noticed that Exchange was listening on the usual ports 6001, 6002 and 6004 on its IPv4 address, but only on ports 6001 and 6002 on its IPv6 address. The DSProxy service (port 6004) is NOT listening on the IPv6 stack!!! This now explains the behaviour that I was experiencing:
- Because Windows 2008 prefers IPv6 over IPv4, it talks to itself over IPv6. So when the RPC-over-HTTP Proxy tries to connect a user session to port 6004 on the same server, it tries to connect to :::1:6004 and NOT to 127.0.0.1:6004. Because the server is not listening to port 6004 on the IPv6 stack, the connection fails.
- If you put the RPC-over-HTTP proxy on a Windows 2003 server, the problem disappears because the Windows 2003 server only uses IPv4 to talk to Exchange on the Windows 2008 server.
So while this may not be a huge problem right now, it will be in the future for:
- Native Windows 2008 environments where all Exchange servers are Windows 2008 and the RPC-over-HTTP proxy is on either one of the Exchange servers or on a seperate Windows 2008 server.
- Single server deployments (e.g. Small Business Server) where everything is condensed to a single Windows 2008 server.
The next step is: how to solve the problem in the meanwhile? Fortunately I found a workaround, although it might not be what you expect! The workaround is to disable IPv6 (duh!), however this proves rather difficult for Windows 2008 (and Vista): you can’t fully disable IPv6 in these products!
- If you’re in a multi-server scenario where the RPC-over-HTTP Proxy is not on the same server as Exchange 2007, than you can simply unselect IPv6 from the properties of your NIC (on the RPC-over-HTTP Proxy machine); that will force the RPC-over-HTTP Proxy to use IPv4 to talk to Exchange and everything will be fine.
- If you’re in a single-server scenario than you can’t disable IPv6 because whatever you do (including the “DisabledComponents” registry setting to disable even more IPv6 components), the loopback interface still uses IPv6.
So it seems that in the latter case, you’re screwed… Not so, because we fortunately still have good old ‘name resolution’ to help us out. Simply open up your hosts file and make the following changes:
- Comment out the line “:::1 localhost”
- Add the following two lines:
<IPv4 address> <hostname of the computer>
<IPv4 address> <FQDN of the computer>
This will resolve all queries for your computer’s name to its IPv4 address, effectively disabling the use of IPv6 for self-communication. You can confirm that this works by doing a “telnet localhost 6004″.
I will pass this issue on to Microsoft when I attend the Exchange ‘14′ Summit next week, so hopefully they can fix it soon.
Kevin Reeuwijk
UPDATE: Microsoft has told me that they will put this on the QFE list for SP2…
Entries (RSS)
June 11th, 2008 at 6:41 am
You have no idea how much this post just saved me from losing 5 years on my life. I was just about to rebuild exchange for the second time to fix this exact issue. Thank you, thank you, thank you.
July 2nd, 2008 at 12:12 pm
This is definitely not the case for all configurations. It\’s working just fine for me for months without doing anything about IPv6. So there must be more to this story.
2 things that come to mind is that in my case the Exchange 2007 server is also a DNS server with Active Directory installed (so in that sense; Exchange is truly a single server installation). Another thing is that I using Basic Authentication and not NTLM (in case that fails on IPv6).
And just in case you were wondering; pinging localhost on the Exchange server does return the IPv6 loopback address.
July 2nd, 2008 at 1:22 pm
Robert,
you are a special case because you also have the domain controller on the same box. In your case the DC will create the TCP 6004 listener on the IPv6 stack, therefore you don’t need the missing TCP 6004 listener on IPv6 that Exchange should create for you. So because you actually have DC and Exchange on one box, you don’t experience the problem. If your DC would be a seperate box, you would experience the same problem as everyone else.
July 2nd, 2008 at 4:31 pm
Thanks Kevin!
Sometimes you escape close calls without knowing
But in that case your example of a single server deployment (or SBS) being a huge issue wouldn\’t be completely accurate. Those configurations wouldn\’t experience the issue for the same reason I\’m not experiencing it. It indeed would only be the case when your have single server dedicated Exchange server configuration (just to give it a name :-D) and thus separate DCs.
Thanks for solving my mystery
July 4th, 2008 at 6:33 pm
TEARS!!!! I had tears in my eyes when this worked. I pulled all of my hair out (very little to begin with) trying to get outlook anywhere to work. This is what did it….
I applaud your sharing the information and THANK YOU sincerely for your efforts.
July 28th, 2008 at 10:48 pm
Wow, I ran across a rippoff of your page 3 days ago. It stated that just disabling IPv6 would do the trick. Umm no, it won\’t, just like you said! This only affected my two Vista machines outside the office. This problem did NOT affect my XP laptop inside the office or when I took it home. Thank you very much!! You saved my bleeding edge technology from getting some real blood on it!
August 1st, 2008 at 8:55 pm
Well, I’m still crying here. Tried all your points, none work. My mobile device nor my rpc - http machines work. I just can’t reach the server. OWA works nice, a little slow though.
Any suggestions?
August 14th, 2008 at 11:28 am
Hi!
I´ve done all of the above and it still dont work.. well some parts work. Vista machines outside and on the inside works but NOT XP machines with OL2007. they just recive the login dialog. Been running outlook /rpcdiag but it doesn´t even try connecting with https
any help?
August 16th, 2008 at 11:03 pm
Definitely it solved my problem. That saved many days of mu work.
Thank You