Background: I am running ISA 2006 Std on Windows Server 2003 Std SP2. The exchange server is 2003 enterprise, on windows 2003 enterprise SP1. The certificate was generated by our internal enterprise CA. The exchange server was previously setup on another site and has been relocated to our new office, no network details changed in this transition. OWA was working at the previous office (simple SPI firewall used). Server running ISA was added to the domain after ISA was installed.
Whenever I browse webmail.xxx.co.uk the only page I am presented with is the dreaded http 500 internal server error. Could anyone point me in the right direction or provide a starting point for monitoring?
The CN of the certificate and the "To" address on the firewall rule are identical. I am not quite sure what I did in the end, but it seems to be working now. I was originally trying to access OWA via http://webmail.xxx.co.uk (as I had been internally) and then realised that there was no redirection to https setup on the firewall rule/web listener, and that I also needed to add /exchange on the end for it to work (had a redirect page setup for internal access to IIS).
Now to scour these forums again to get my activesync working (i'm sure I read somewhere that ISA 2006 supports OWA and activesync on the same web listener), and also to see if I can drop the /exchange and have it seamlessly redirect.
Well after quite a few frustrating days I finally have my OWA and EAS up and running, though I am not quite sure if it is in the most secure fashion. The only way I could get it to work was to uncheck the "redirect requests to SSL port" on the OWA/EAS rule bridging tab and place a checkmark in "redirect requests to http port"
When redirecting to SSL was in play I would always get "Error Code 10061: Connection Refused" after putting in the OWA login credentials and on my Windows Mobile 5 device activesync would throw a 0x85010014 error.
Appreciate if someone could let me know if the method I have used is a security hazard, I hope not as I was starting to lose hair over this problem!
Sounds like you have SSL to HTTP bridging going then. The solution would be to fix the certificate situation on the OWA Web site. The name on the TO tab must match the name on the OWA Web site certificate, and that name must resolve to the IP address of the OWA site on the internal network.
Thanks for the response. I think your response there has just put the last little piece of the jigsaw puzzle into play. The name on the To tab matches the name on the OWA web site certificate, however internal DNS has been configured with an A record for the name to point to the internal interface of ISA, thus allowing internal users to use the full "webmail.companyname.co.uk". So this name would not resolve to the OWA site from ISA.
I should point out that the internal (AD) domain name is the same as the external (public) domain name. The exchange server has multiple IP addresses configured, though it's DNS name is mail01.companyname.co.uk. If I try and set the default website to use a specific IP address rather than "all unassigned" OWA fails.
This does make sense. And you can leave your internal DNS to point to the internal interface of the ISA Firewall so that you have a split DNS that supports ISA FBA for both internal and external users.
Why? Because ISA 2006 allows you to configure the name that used on the certificate and then point to the IP address of the server that you want to publish. Run through the OWA publishing rule wizard and you'll see what I mean. This means that unlike ISA 2004, which was dependent on the name on the TO tab to resolve to the published server, in ISA 2006 you can enter the name on the Web site certificate and then point it to the actual IP address of the published server.