Last Tuesday night I was helping out a friend from my team that was handling a case where customer was unable to access Outlook Anywhere from outside network. As usual, everything works inside, so who’s to blame? Of course ISA Server, it is the only thing different, right? Will see…
To better isolate the problem we eliminated tests using Outlook Client and just tried to access the RPC URL using IE (example: https://mail.contoso.com:443/rpc/rpcproxy.dll) and the result was the error below:
Figure 1 – host not available error.
We used Fiddler and we got an interesting result, see below:
Figure 2 – Fiddler result.
Since this is a real traffic I’m hiding some of the legitimate URLs, but the point in the different colors are:
Expected traffic using the external URL (for example mail.contoso.com)
Non expected traffic using internal URL (for example mail.contoso.local)
What this means? This means that ISA is for same reason losing the host name during this conversation, which is exactly what error 64 means: "The specified network name is no longer available", which is a win32 error originally called ERROR_NETNAME_DELETED.
At that time the question was: who is changing this name and sending it to ISA? Since the answer was not on our side (we saw on netmon trace that CAS was doing that) we collaborated with an Engineer from the Exchange Team that after some other troubleshooting steps fixed the issue by using the following article:
Note: the error 400 mentioned in the above article is the same as the one that we received from the CAS server (by looking the netmon trace).
Very interesting case where “again” everything works internally but doesn’t work externally. But again we proved the point that ISA was not causing this issue with a very useful help (as usual) from the Exchange folks.
PingBack from http://blogs.isaserver.org/shinder/2009/01/29/error-64-rpchttp-through-the-isa-firewall-its-not-the-firewalls-fault-case-669874521/