Hi Guys, Ladies, I'm in some Outlook Anywhere trouble as mentioned in the topic.My actual network setup:"evil internet" -> squid reverse proxy (NTLM-pass through is working!) -> Exchange 2007 on Windows 2008 My actual Exchange setup:Exchange 2007 standard with service packs and update rollup 7 running on Windows 2008 standard with service pack 1 and IIS 7. This Windows 2008 is also the domain controller, GC and everything else (all in one server). It's just installed - nothing special.What happens to me is that I can connect to Exchange via RPC-proxy with NTLM-authentication from any Windows Vista box with Outlook 2007 but the moment I try from any Windows XP box with Outlook 2007 it starts asking me for the password and I never get past this point.I read a lot aboutpassword issues and in the end I even applied the hotfix from KB-articles 968404, 968858, 969791, 970071, 970123, 970144 that was given to public on April, 30 of 2009 and could help me out with this, but still nothing. I used the /rpcdiag switch on Outlook to figure out what's going on, but as i can't sign in there is nothing shown.Everything else I found and checked/tested when I was googling around:- some articles about the connectivity between the RPC-proxy and the Window Server/Exchange itself (ports 6001-6004) -> nothing- some articles about the connectivity if IPv6 is enabled -> nothing- some articles about changing the mode of the RPC-proxy and how it works/the mode it uses -> nothingI also used the rpcping utility from theWin2k3 resource kit toolsto test if the RPC-proxy is answering me -> WORKS.I tested this with NTLM-auth and SSL-encryption -> WORKSTested all this together from Windows XP -> WORKS (!)So to figure out what is going on I started testing inlab.Alltesting is done with NTLM-authentication. I need this for pub apps on terminal services sometime later, as the MSTSC is only authenticating against the RPC-proxy with NTLM or smart card. Terminal services are not installed at the moment, norare the TS-security management features of TS.I set up two different Exchange 2007 setups identical to the production setup above and tested against both servers. Just to have redundancy in testing.The cert I'm using is officially signed, and is working in Internet Explorer on those boxes without any complaints (e.g. to connect to OWA). Also it is tested with Active Sync via Windows Mobile 6.x mobiles. I'm able to create certs in a private cert authority and addthem toWindows XP/Vista/Servers so that they trust the certs I'm using in the lab.It is also possible to change the DNS setup in the lab so that the official signed certs on the proxy can be used and istrusted without any problems. Just to exclude any cert issues. There aren't any! (*REALLY* tested)I also tested this with and without proxy in the middle - theSQUID setup is a transparent reverse proxy and it's with NTLM-pass through. Aspersistent connections are neededfor NTLM and only supported in special releases of squid (from 2.7 STABLE4 on) I am actually using 2.7-STABLE6. Btw. there is no extra authentication done on the SQUID-side.I am terminating the SSL layer somewhere before the Exchange Server (SQUID) which allows me to sniff the network traffic that is occurring betweenSQUID and IIS on the Exchange box. I'm also able to sniff encrypted connections without a proxy in the middle. Also I run a sniffer on the Exchange box to see what's going on inside it (RPC-proxy -> Exchange).When I'm doing SSL offloading the required header ""Front-End-Https: On" is sent to the Exchange box and SSL offloading is configured in OA (both checked with network sniffer and management shell).Another thing I checked is that the NTLM-auth is done correctly:- Doing RPC over HTTP from any Vista + Office 2007 box works as expected and Outlook can connect -> NTLM-auth working- Doing the rpcping test, getting a positive reply -> NTLM-auth working- Reading the network traffic with ngrep and seeing the NTLM-handshake done correctly *AND* ending in a "200 ok" -> NTLM-auth working (This also happens on Windows XP boxes but brings up the password prompt in the end(!))So what did I test exactly? Connections I made through RPC-proxy over HTTPS are authenticated with NTLM-authentication. Mixed with the options above (squid/no squid, official cert/non official, SSL/no SSL, and so on ...), I tested this:Windows XP SP2 (x86), Office 2007 w/o SP -> not workingWindows XP SP2 (x86), Office 2007 SP1 -> not workingWindows XP SP2 (x86), Office 2007 SP2 -> not workingWindows XP SP3 (x86), Office 2007 w/o SP -> not workingWindows XP SP3 (x86), Office 2007 SP1 -> not workingWindows XP SP3 (x86), Office 2007 SP2 -> not working Windows Vista SP1 (amd64)-> Office 2007 w/o SP -> WORKINGWindows Vista SP1 (amd64)-> Office 2007 SP1 -> WORKINGWindows Vista SP1 (amd64)-> Office 2007 SP2 -> WORKING As SP2 for Vista amd64 German isnt out yet, I couldnt test it. What I figured out is if I enable anonymous authentication for the RPC-proxy on the /rpc-directory in IIS 7.0, the Windows XP boxes are able to authenticate with NTLM-auth to the Exchange Server without any problems. I guess this is why the auth on the RPC-Proxy isnt happening at all It is also possible to add the authentication basic to the IIS directory and it starts working with basic authentication without any problems. But as I mentioned above I need to have NTLM auth later in use with the Terminal Services and I dont think there are any NTLM-auth troubles on the SQUID-side because its working fine with any Vista box. I could add NTLM- and basic-auth but the Terminal Services are also running a similar service as Exchange does which is checking the auth parameters of the /rpc-directory in IIS and changes them if not matched with the settings in the configuration. So I can only use the least common denominator for authentication of both services and this is NTLM. Right now I think I found a bug that is somewhere inside Outlook 2007 / Windows XP or the RPC-implementation in XP which is used to connect to the Exchange Server. It seems to stop Outlook from authenticating against the RPC-proxy correctly. One thing that is not matching my theory is the proper connection of the rpcping utility that shouldnt work if theres an error in the implementation of RPC So Im banging my head against the wall for at least two days now and Im hoping for help Thanking you in anticipation! Best regards, Oliver Loch

Hi,a small update relating to my problem.What i know now is that the NTLM-authentication starts working right after resetting the IIS.It's working for a few Minutes and then stops from out of nowhere... When i wait for 10 minutes,the functionality comes back for about 2-3 minutes...After testing around it showed up thati can bring down theNTLM-authentication byconnecting to the RPC-proxy with an XP box that runs Outlook 2007 (service pack doesn't matter). It takes aproximately about 20 secs to stop. WhenI connect in the first 30 seconds after the reset of IIS, the XP boxes can connect to the RPC-Proxy via NTLM-authentiaction too (!).Working with Vista + Outlook 2007 boxes stop the NTLM-authentication from working about 3 to 5 minutes after the first connect.When it stops,neither the Vista or XP boxes can connect.The Basic-auth is still working...I sniffed the network traffic and saw only stepsone tofour out of six neededto completethe NTLM-handshake. Steps five and six are just not happening. So Istarted googling around and found a few things:- disabling kernel-authentication (in IIS MMC and via appcmd in shell) -> tested,changed nothing- changing the maximum worker threads of the DefaultAppPool from 1 to 2,3,4,5 -> Outlook starts hanging when connecting to the RPC-proxy and ends up unconnected.I definitely excluded any cert- or squid-trouble by taking them out of the "chain" and testing directly on the IIS.This is really strange - I have this behaviour in lab and in production use onthis oneServer...I've got other Servers running this setup and they're _ALL_ working fine. I don't get it ...If anyone got any idea ...Thanks!Best regards,Oliver Loch"Nothing says 'Obey Me' like a bloody head on a fence post!" - Stewie Griffin

Hi, I am facing problem in configuring RPC over HTTPS with squid 2.7stable6 as a reverse proxy Testing my setup with the following link https://www.testexchangeconnectivity.com/ and it returns this error Attempting to ping RPC Endpoint 6001 (Exchange Information Store) on server hubsexchange.airarabiauae.com Failed to ping Endpoint Additional Details An RPC Error was thrown by the RPC Runtime. Error 1818 1818 Any idea about the above error? will it be possible for you to send me your squid.conf file and steps take to setup on windows 2003 and IIS7? will be great full to you //Remy

Dear Oliver, We are facing the same issue. Did you get any resolution for this? If not kindly MSFTs put attention on this thread and let us know if this is a bug or some misconfiguration in our setup. We have a huge number of XP clients outside but always has same problem, but Visa and Windows 7 clients from outside can connect using NTLM perfectly. Any idea MSFTs please?

Hello! Any progress in that? I am trying to use IIS 7.5 (WS 2008 R2) with Application Request Routing 2.5 as reverse proxy. When I use ISA 2006 publishing works fine, but when I use ARR I am getting same RPC Ping error 1818 1818 in ExRCA. OWA, Autodiscover and ActiveSync works fine with ARR. Does ISA do something special what Squid, mod_proxy or ARR doesnt?