Last week I worked on an interesting case where I was lucky enough to have a buddy here from MS Texas available to help me out on an issue related to Entourage. Before I introduce him, let’s consider a scenario (described in the figure below) where Entourage clients were unable to access their mailbox when are located in the external network (Internet) passing through ISA Server 2006.
Notice that in this case there are two CAS Servers in NLB and for the internal MAC users they were able to access their mailbox without any problem.
Since the initial assessment done by the Messaging Admin concluded that internal MAC clients were able to access their Exchange mailbox, we had to understand what it was ISA role on this error. The initial troubleshooting on the ISA Server side in this type of case is always to get the live logging and see what ISA is reporting about this error. For this particular scenario ISA was logging that the error 405 was coming from the CAS server (IIS) as shown below:
|0.0.0.0 Entourage/12.19.0 (PPC Mac OS X 10.5.7) Yes Reverse Proxy mail.contoso.com TCP POST Internet - - - Req ID: 0594a3b3; Compression: client=Yes, server=No, compress rate=43% decompress rate=0% ; FBA cookie: exists=yes, valid=yes, updated=no, logged off=no, client type=public, user activity=yes - - - 4/8/2010 12:52:35 AM 0 234 1181 1443 0x40000000 0xe00 4/7/2010 9:52:35 PM XX.XX.XX.XX 10.10.10.17 443 https Allowed Connection OWAPub 405 Method Not Allowed anonymous External http://mail.contoso.com Web Proxy Filter|
In order to confirm that, we went to IIS logs and confirmed that it was IIS sending the 405. It was during this time that I asked for assistance to one of our Entourage SME here at MS Texas, Austin McCollum. Rapidly Austin noticed that the reason why IIS was sending this 405 was because the connection attempt was sending a request to the /owa vidir rather than /exchange (which is the one used by Entourage). Although the client was configured to send the request to mail.contoso.com/exchange, there was a redirect rule on ISA Server (created by the Admin) that was redirecting all the traffic from mail.contoso.com/exchange to mail.contoso.com/owa. This redirect rule was created by the ISA Administrator in order to automatically redirect clients to the OWA vdir since all his infrastructure was Exchange 2007 (and used to be Exchange 2003). This is not a necessary step, better to rely on Exchange to handle that.
After fixing this problem we were confident that the issue will be resolved…NOT!! Again, we got 405 and again it was coming from CAS (IIS). However at this time it was going to the correct place /exchange. Austin used his article http://blogs.technet.com/austinmc/archive/2009/04/17/connecting-entourage-with-exchange-2007.aspx in order to fix other configuration issues, however the 405 persisted and for our surprise the /exchange vdir had not authentication selection, nothing, nada...hence it fails to authenticate. We enabled basic authentication and after that everything started working.
3. Why it was working internally?
The question that really got into our mind was why this was working internally and if you look to the network diagram you will see that the topology is composed by a NLB on the CAS side. What it was happening was that internal clients were were hitting the CAS Server that had no authentication problem on /exchange vdir. Also, since they were not passing through ISA, they didn’t face the initial problem with the /exchange redirect.
True teamwork here, Thanks Austin !!