OWA displays html/script code rather than performing an action

When clicking anthing within OWA that performs any kind of function with the server, eg recipient checking, sending an email etc, I get a very bizzare error, it looks like its trying to display an error message but instead give a bit of HTML code in a dialogue box.

I've attached images of the errors as I cant copy and paste the text from them..

All three of these errors appear when tryinging to send an email, I think its trying to check the name in the to field, send the message and then cancel sending with these three errors, the message is still sent but its quite unusable at the moment.

I've searched for hours on the Internet, here and microsoft but cant really find anything pertinent except for an old article about msx 5.5 displaying script code rather than running scripts with a solution that doesnt apply to IIS on 2003.
adjusting.jpg
submitting.jpg
cancelling.jpg
dpeters_ansecurityAsked:
Who is Participating?
 
dpeters_ansecurityAuthor Commented:
Not to worry, I think we've fixed it,

http://support.microsoft.com/kb/911829

The symptoms arent quite what we were seeing, but not a million miles off, have applied to hotfix and it seems to work, the clients MUST clear thier temporary internet files for it to work!

Thanks again for looking.

Dave
0
 
dpeters_ansecurityAuthor Commented:
I should also add, I have tried recreating the Exchange OWA virtual directories following the MS KB article, still the same situation.

My next "clutching at straws" step will be to install a front end server (OWA is currently running the the single MSX server in this environment).

Seems silly to have to do this as its been working fine for several years!

Thanks
0
 
MesthaCommented:
Some version information would help.
I can take a guess, but that doesn't help anyone.

-M
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
dpeters_ansecurityAuthor Commented:
Whoops, sorry, MSX 2003, SP 2 (version 6.5, build 7638.2: service pack 2)

Running on server 2003 Standard Edition, SP2,

Thanks.
0
 
LeeDerbyshireCommented:
Have you installed anything other than Exchange on the server recently?  Does it do this from any client computer?  And for all users?  Can you post for us the IIS log entries generated when you perform the action that results in this behaviour?
0
 
dpeters_ansecurityAuthor Commented:
Hi Lee,

Nothing was added or changed on MSX, we did put a reverse proxy in place in front of the OWA server as a security measure but I'm quite doubtful that this would have "broken" anything in MSX.

The hotfix above seems to have fixed the issue, how the problem suddenly materialised I will probably never know, its certainly not the first time I've seen random problems crop up on OWA for apparently no reason at all!
0
 
LeeDerbyshireCommented:
Actually, I can imagine that a proxy is just the kind of thing that would break OWA, since they can change the IIS output sent to the client.  The client would be getting modified HTML source, but they prefer to take .js files (which OWA uses a lot) straight from the local cache.  The mixture of new HTML source with changed addresses, and the old .js files would, I imagine, cause just the kind of thing you were seeing.  Hard to be sure now, though :-)
0
 
dpeters_ansecurityAuthor Commented:
Ah I see, the problem was apparent when going direct to the server as well as via the proxy, If I understand what you said correctly it could be the cache on the client was "broken" not so much the server. I cant think that we tried clearing the cache before installing the hotfix.
0
 
LeeDerbyshireCommented:
Well, if bypassing the proxy produced the same error, it would seem to rule that out.  Unltimately, the best way to see what's happened would be to look at the page source in IE on a machine that has the problem.  Then you can compare it with a machine that now works okay.

Clearing the cache tends to solve problems related to different versions of .js files, which IE likes to reuse from cache whenever it can.  This is why you find new directories (named with each version number) created in the exchweb directory after each Exchange update.  Because the new files are in a different directory, IE reloads it.  If they placed updated files in the existing directories, IE would just get them from cache, and they wouldn't work the same.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.