Vishal VasuYesterday I had a visit a client site for whom I support Exchange 2003 servers. They have an ISA 2000 setup and now want to migrate to ISA 2004/2006. The challenge was – how to do it. Even before that, they wanted to try out the publishing of Exchange Server’s Outlook Web Access over SSL from ISA 2004.
So, a new server was setup which had the ISA 2004 configured and which could talk to the current network so that the traffic from ISA can flow to Exchange server and vice-versa. The challenge was that their current FQDN did not point to the real IP which was set on the external interface of ISA.
In order to over come that situation where ISA would show a URL error, I set the client machine’s host header entry (which was outside the network) to point to the real IP of the new ISA server’s external interface. Next setup was to configure the new ISA to allow SSL Bridging between ISA and Exchange and configure it to use Forms Based Authentication (FBA).
After configuration of the above, I tried to access the FQDN from an external client and nothing happened. That was bad!!
ISA denied the request until I enabled “Require All Users to Authenticate” check box (which is not mandatory). This time I was happy to see the OWA screen on the client. But my worries did not end there. If I tried to login, OWA would not open the Inbox. Obviously the next step was to verify if ISA was able to authenticate the user credentials against Active Directory. Yes, checking the monitoring logs should that it could. So what was missing???
After some more hair pulling, analysis and some more hair pulling the loophole was found. ISA was not able to redirect the request to the Exchange Server for some reason. Added a host entry with the internal IP address of Exchange Server on the ISA Server and tried it once again.
Voila! We are there. Now the clients can enjoy their secure Outlook Web Access solution. Yes, the migration of ISA is still pending — but that’s a different story.
Vishal Vasu
