1. Introduction

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.

image

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.

2. Troubleshooting

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 !!