Exchange 5.5 OWA - Cannot View E-mail

How about:

http://support.microsoft.com/default.aspx?scid=kb;en-us;q166239

Also, somewhat date but applicable:

http://support.microsoft.com/default.aspx?scid=/support/Exchange/Content/Whitepapers/owa_tshoot.asp&SD=GN&FR=0

Jason,

Your first comment is in relation to not being able to access OWA.  I'm able to do that.  I read through the article again and it isn't relevant to this issue....but I double-checked the permissions as it mentioned towards the end.  Thanks.

Regarding the second comment you left, I've been working from this page as I've tried to troubleshoot this issue, but thanks for the confirmation that I've at least been looking in the right place.  None of that has seemed to work.  About 4/5ths of the way down there is a section titled, "HTTP 404 File Not Found...."  I've followed that advice, downloaded the file through the FTP link there, installed it, restarted the services (as the instructions say to), and it didn't make any change....still the issue persists.  There are two links there for other articles (Q192930 XWEB: OWA Error 404 Opening Messages After Applying 5.5 SP) and (Q166239 XCLN: Err Msg: HTTP/1.0 404 Object Not Found).  These look promising, but the links don't work anymore and I can't seem to find them by searching the knowledgebase.

Jason,

Correction.... the "Object not found" link works, but the one above it does not.

I'd look into this... it "should" have been fixed witht the service pack you have... but it may not have been. It's an easy test, just rename the old on so you can revert back if it's a no go.

"HTTP 404 File Not Found Error Opening Messages or Unable to Render Error Opening Messages
This error may occur after you install Exchange Server 5.5 Service Pack 1. There is a calculation and check done on the files in the Webdata directory to determine if the object requested is a file or directory. If some flags, such as Archive, are set on the directory, it may cause the calculation routine to be incorrect and produce the wrong URL. If this is the case, you may encounter the above listed errors. A fix to correct this problem is available at the following URL, and will be included in Exchange Server 5.5 Service Pack 2. The update is for the Cdohtml.dll file.

Ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/<language>/exchg5.5/postsp1/CDOHTML-fix"

English link:

ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg5.5/PostSP1/CDOHtml-fix/

Jason,

I've looked that article up on the net and it appears that it is in relation to the hotfix that the FTP link above it references....so I've already done that as well.

Thanks.

ATTENTION:

Some very important information that I was not aware of until just now.  I have been accessing the client's exchange server remotely.  Don't ask me why (idiocy, I suppose) but I never tried logging on to a user's mailbox through IE on the Exchange Server itself...I've only tried it from a remote location.  When I bring up IE and go to the local IP (http://192.168.1.51/exchange), I am able to log in to an account and VIEW the E-MAIL!!!  When I do it remotely as I have been doing, if I click on an e-mail message within the inbox, I get a 404 File Not Found error....but when I do it remotely, I click on the same e-mail and "POP" up it comes...I can see the text.  Now what exactly does THIS tell us?

CLARIFICATION:

I said, "....but when I do it remotely, I click on the same e-mail and "POP" up it comes..."  What I meant to say was "...but when I do it locally, I click on the same e-mail and "POP" up it comes..."  Sorry for the confusion.

Using IE on the exchange server it still has to go to the OWA server to get the web page so it looks like their firewall may be the problem. What firewall is it?

or the version of I.E. on the remote client... I asuume another remote PC has been tested.

Andy:  I'm not familiar with the firewall...that is handled by another tech with our company.  However, I would rule this out because I am able to view the calendar contents, the contact lists, able to send mail from the OWA logon remotely, etc.  Viewing an e-mail is the only issue.

Jason:  It has been checked on at least three different machines.  Two seperate Win2Kpro machines and an XPpro machine.  All with IE 6...we don't have anything less than 6 on any of our machines.

OWA uses port 80. Assuming this port assignment was never changed, it is not the firewall.

Stumped...

Can still be the firewall. The URLs required to retrieve email are very long, our websense box was blocking me from accessing an external OWA server and increasing the max URL length fixed it, check if it works with OWA from the local workstations.

just to beat a dead horse...

Please list the cdohtml.dll version number...

Also, are there multiple copies of this dll on the box... and not the same version? If so, which one is the box using?

Andy makes an interesting point... if he has experienced it, it is worth a look.

ADDITIONAL:

I am able to connect remotely to the PDC (remember, the Exchange server is on a BDC) and go to the site through the browser to the local IP address/exchange and am able to view the e-mail from there as well.  HOWEVER.... if I remotely access the PDC from here, get onto the browser, enter the EXTERNAL IP/exchange, I am no longer able to view the e-mails.  As I see it, when I log onto the OWA through the local IP/exchange, I am going through the IIS set up on the BDC because it goes directly to that network card on the Exchange Server.  But when I go to the external IP, it goes to the network card on the PDC which means it is using the IIS that is on the PDC and the IIS on the PDC shows the Exchange server in a virtual directory on the BDC.  In other words, under the Microsoft Management Console (IIS), under the "Default Web Site", there is an entry in the right pane that reads, "EXCHANGE".  The path for that reads "\\exchange\exchange\exchsrvr\WEBDATA".  Under the Microsoft Management Console (IIS) on the BDC (the exchange server whos name is "EXCHANGE"), the right pane also reads, "EXCHANGE", but of course the path for that is "c:\exchsrvr\WEBDATA".

I know this sounds stupid but try stopping the WWW service and see if you can still access OWA from a remote location. It's possible that OWA is installed on another box or on the Exchange server as well as on the OWA server and that installation hasn't been servicepacked and the firewall points to the the wrong IP address.

Jason,

I have that file listed three times on the Exchange server.  One is in C:\temp\eng\server\setup\i386\bin and it is version 5.5.2653.23.  Another is in c:\exchsrvr\bin and is version 5.5.2404.0.  And the third is in c:\microsoft patches\exchange pack and is also version 5.5.2404.0.  I went ahead and looked...the one that I downloaded from Microsoft with the link you have mentioned above was version 5.5.2404.0  The original one I had in place (now called cdohtml.old inside the c:\exchsrvr\bin) was version 5.5.2653.23.  Apparently, the fix from Microsoft places an older version of the file in there....not what I would have expected...I would have expected that I would be installing a newer version in place of an older version.  Hmmm...strange.

Andy: please elaborate.  There are only two actual servers...the PDC and the BDC.  Both have IIS running.  The PDC is the file and print server.  The BDC is the Exchange Server and also where OWA is installed and running.  Which one are you suggesting I stop the service on (PDC or BDC)?...and are you saying the World Wide Web Publishing Service?...is that the one you're referring to?

There is a recent hotfix, not for this issue directly, but it has the latest version of that DLL... and a good idea to apply. Wanna give it a go?

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS03-047.asp

09/16/2003 11:50 5.5.2657.67 536,848 CDOHTML.DLL %EXSRVROOT%\bin

It can be done now, with little to no production impact...

Restart Requirement:

No. However, the security patch will restart Microsoft Internet Information Services (IIS), the Exchange Store, and the Exchange System Attendant Services. For this reason, install the patch when no users are logged on through OWA.

I thought that patch was for the OWA server, how can it stop Exchange from running. Have you applied Exchange SP4 to the PDC/OWA server?

Jason: I'll give it a try right now...

Andy: SP4 has been applied to the BDC/OWA server.  (PDC does not have exchange server nor OWA installed on it)

But it says   >>We have set OWA up so that the IIS on the PDC<<  in the question??

Andy:  I'm sorry, I think I wasn't very clear.  I think the statement you're referring to is, "We have set OWA up so that the IIS on the PDC sees the virtual directory on the BDC where Exchange is located.".  Probably what I should have said is "We have set up IIS on the PDC to see the OWA through the virtual directory on the BDC where Exchange (and OWA) is located."  Sorry for the confusion.

I am sorry, I should learn to read. Didn't notice the bit about redirecting to OWA on the Exchange server. Don't know enough about IIS to be sure but probably some patches need to to be applied to one and some to others. It may explains why everyone can access each others calendars as well. Don't think it's a valid way of doing it.

Jason:  That hotfix didn't work.  I'm still in the same boat.

We've at least ruled out the dll issue, that's something.

I don't think this is the issue either, because I trust you tried more than one email message, but we'll mention it.

make sure the subject of the email does not contain one or more of the blocked characters listed below, OWA doesn't like them:

Two periods (..) or a single period at the end of the subject
A period and a forward slash (./)
backslash (\)
Colon (:)
Percent sign (%)
Ampersand (&)

I quoted that above, FYI. So  I can't verify/vouch the accuracy...

IIS Lockdown ever applied on any of these boxes?

Inclined to believe it's a permissions issue of some kind... I'm reaching here...

Inspect the permissions on the various webdata folders.

Make sure the logon locally permission hasn't been altered...

I just finished, literally, my 5.5 to 2000 migration, so i don't have anything to look at here anymore.

Jason: On your first comment, "yes", I already saw that issue on the net.  It doesn't make any difference which e-mail you try to open (ie, whether it has :, %, &, etc. in it or not).  On your third comment, "IIS Lockdown"?  Could you elaborate? I don't know what IIS Lockdown is.  And on your fourth comment, "YES", I too believe it is a permissions issue....so that's the direction I've been heading.  However, I either don't know where to look or I'm overlooking it.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/locktool.asp

IIS lockdown is a security tool, if you don't know it, you most likely didn't apply it. But it does things to IIS permissions... not a windowsupdate item though, so we can likely rule that out as you don't recognize it.

Have a spare box laying around that we could JUST install OWA on?

Jason: Unfortunately, no.

Jason:  You are correct, I have not used the lockdown security tool.

What authentification method are you using in IIS?

RECAP:

Just a recap for anyone reading this.  We can access OWA locally, using the 192.168.1.51/exchange in the browser, mailbox permissions seem to work (i.e., you can't log onto someone else's mailbox) AND you are able to view all e-mail messages when you click on them (no matter which box they're in ... inbox, deleted, sent, etc.).  However, when we try the same thing using the external IP/exchange, we can log into anyone's mailbox with any valid username and password, AND when you click on an e-mail message in any box, all you get is a 404 Page Not Found error.  The External IP is related to the PDC and the Exchange Server and OWA are on the BDC.  The default webpage in IIS on the BDC is stopped (it was previously on, but it doesn't seem to make any difference one way or the other) and the EXCHANGE entry under the default web page on the IIS on the PDC points to a virtual directory (\\Exchange\Exchange\exchsrvr\WEBDATA).

What I find important from larger quote below:
"If Exchange and IIS are on separate computers, only Basic (Clear Text) and Anonymous can be used"

"Password Authentication Methods - The WWW service on the IIS server must be configured for the appropriate password authentication method. This is dependent on how you intend to set up your Exchange and IIS servers. If both Exchange and IIS are installed on the same computer, you can use any of the three supported authentication methods. If Exchange and IIS are on separate computers, only Basic (Clear Text) and Anonymous can be used. Windows NT Challenge/Response (also called NTLM) authentication cannot be used if a browser other than Internet Explorer will be used for Outlook Web Access. If you are going to use the Windows NT Challenge/Response method for authentication, then any resources your clients need to access must reside on the local IIS/Exchange server. This will include the mailboxes, any Public Folders, Free/Busy data, organizational forms, and so forth."

Jason:  Basic Authentication (clear text).

Jason:  Just to elaborate....the issue persists whether it is on NT Authentication or Basic.

Running out of ideas... short of uninstalling OWA and reinstalling OWA.

Basic Authentication on both the PDC and BDC correct?

Jason: Yes.  Basic Authentication is chosen on both PDC and BDC.  (and believe me, I feel your frustration my brother....I've only been working on this for about a week!  Arrrrgh.)

SOLUTION:

Well, if you can't work through it....work around it.  I figured out a workaround.  We have a proxy server installed on the PDC which acts as websharing and a firewall.  (before you get ahead of yourself, there was nothing in the firewall causing the problem)  Within the Proxy server, you have the option of mapping routes for various ports.  Since we don't host our own website, there was no reason for us to keep everything going through the PDC for HTML purposes.  Also, since we have been able to get the local ip/exchange access to work for OWA, that told me that the BDC IIS was set up properly.  So, I shut down the default website on the PDC, forwarded port 80 in the proxy server to the BDC's local IP, and started the default website on the BDC.  Now, when someone goes to the external ip address from outside the network, the proxy server will be listening for that request on port 80 and automatically forward it to the BDC where Exchange Server and OWA are located....and if the add on the familiar "/exchange" to the IP, it will take them to the OWA login screen.  Once here everything is working great...no one can log onto anyone else's mailbox AND you can read the e-mails in all of the boxes.  (someone wanna give me a high-five?)

Put anonymous authentication as well on the IIS
"IIS must be configured to allow Anonymous logon, and Basic (Clear Text) should be set as the authentication method".

This is redundant to a comment already made, but you never verified that anonymous logon is being allowed....at least I didn't see it in the thread.

D

Well, since we are on one box now, try and tighten up that security by experimenting with better auth methods... glad to hear this is resolved.

"If both Exchange and IIS are installed on the same computer, you can use any of the three supported authentication methods."