OWA Site Appears Garbled and Mailbox Stuck on “Loading”

I spent my holiday weekend putting together an article series on how to use the ISA 2006 firewall (now in beta version) to publish OWA and RPC/HTTP Sites using a single IP address. This is a very nice feature that was frequently requested among ISA 2004 firewall admins, because you couldn’t publish both the OWA site and the RPC/HTTP site using a single IP address if you had Forms-based authentication enabled on the Web listener. I also demonstrate in the article series how to use the new ISA 2006 Web Farm Load Balancing service. This feature allows you to publish a Web farm of servers performing the same role without the need to use NLB.

Just as a preview, here’s a quick look at the lab setup:

img14

When setting up the lab, I found I was having a problem with what I thought was the OWA Web Publishing Rule. The OWA site looked garbled with incorrect fonts, buttons that didn’t work, and the Mail page was stuck on “loading”. Now, I’ve learned my lesson regarding troubleshooting issues that might seem to be related to the ISA firewall: 99% of the time it isn’t the ISA firewall’s fault. Of course, I had some doubts because I’m using beta software and you never know what works and what doesn’t.

So, the first step was to check if the OWA site worked for clients on the default Internal Network. It turned out that the same problem was seen for the internal clients too. The next step was to figure out why connections to the front-end Exchange Servers garbled the OWA client’s Web page. I wasn’t sure where to start because I know that I’ve had this configuration working before with Exchange 2003 SP2 and hadn’t done anything differently this time.

I had to come up with an hypothesis. Since it appeared to be a Web related problem, I checked the folder contents for the /Exchange, /Exchweb, and /Public folders on both the front-end and back-end Exchange Servers. There I noticed that there was a folder on the back-end Exchange Server that didn’t appear on the front-end Exchange Server. The folder had the name /6.5.7651.9

Why was that folder on the back-end Exchange Server and not on the front-end Exchange Servers and did it have anything to do with my problem? The next step was to do a Google search. I used the following search string:

http://www.google.com/search?hl=en&q=%226.5.7651.9%22+exchange+server

On this page I found a link that looked like it would fix things:

http://72.14.209.104/search?q=cache:d4vs1UMDFSIJ:msexchangeteam.com/archive/2006/04/28/426707.aspx+%226.5.7651.9%22+exchange+server&hl=en&gl=us&ct=clnk&cd=5&lr=lang_en

If you scroll down to near the bottom of the page you’ll see that someone mentioned that if you copy the 6.5.7651.9 folder to the front-end Exchange Servers, all would be fine. Guess what? It worked!

MORALS OF THIS STORY:

  • 99% of the time problems that might be attributed to the ISA firewall aren’t the fault of the ISA firewall
  • Always begin troubleshooting service issues by confirming that the service is functional in the first place
  • Develop hypotheses on what might be wrong, and follow those up with Web searches

Technorati Tags: , , , ,

HTH,

Tom

Thomas W Shinder, M.D.

Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/

Book: http://tinyurl.com/3xqb7

MVP — ISA Firewalls

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top