• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1510
  • Last Modified:

Outlook Web Access 2003 - Random "Page Not Found" errors when viewing messages

I have a Small Biz Server 2003 server with Exchange 2003 and OWA enabled.  It's been working great for about three months now, but I'm now seeing very strange problems within the OWA session.

Using forms-based authentication, I can access the OWA logon page and sign in just fine.  I can click on a message in the Inbox and view it through Reading Pane or by opening the message.  But about 40% of the messages display a generic HTTP 404 "Page Not Found" error in the Reading Pane and when fully opening the message.

There's no pattern to which messages work and which don't, and the frequency varies by mailbox.  Another user can't view any new messages from the past 7 days, but all his older messages are accessible.

The Outlook 2003 client can access all the mailboxes and doesn't have a problem reading the messages that OWA can't display.

It doesn't appear to be a permissions issue (though I've been known to be wrong :) ), so I don't want to start messing around with permissions until I get a better idea of how it's even possible that seemingly random messages can't be displayed in OWA when IIS is accessing the same folder/share (\\.\BackOfficeServer\domain\MBX) to retrieve the message.
1 Solution

Seems like a problem with your IIS. Try restarting the IIS server where OWA is located, maybe this resolves your issue..
dane_mAuthor Commented:
I tried every level of restarting, from the IIS server, to the Exchange server, then to rebooting the entire SBS box, but nothing changed.  The same messages still show as "Page not found".

I think I found the pattern.  Any message with an embedded link has the "Page not found" error.  And for messages with attachments (but no links in the message body) I can try to open the attachment and get a "Page not found" error as well.

Sounds like a permissions problem somewhere in IIS.  Any ideas where to look?
dane_mAuthor Commented:
Fixed.  It was a permissions problem somewhere.  I went through the Exchange folders and reset everything to what I think is correct.  Speaking of which, I have yet to find a document that accurately describes the necessary permissions for the Exchange/Exadmin/ExchWeb folders in IIS for OWA to work.  Here's what I reset it to:

- All virtual dirs are SSL required.
- Using only one server, so added NetBIOS default domain on all virtual dirs.
- All permissions have been applied to respective child dirs.

Exchange - No anonymous, Basic auth (nothing else selected)
Exadmin - Anonymous, Basic auth (nothing else selected)
ExchWeb - Anonymous, Basic auth (nothing else selected)
Public - No anonymous, Basic auth (nothing else selected)

Do these permissions make sense?  Am I giving out too much anonymous access to some of these directories that would affect the security of the OWA site/server?

500 points to the best answer. :)
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

dane_mAuthor Commented:
Spoke too soon.  It's broken again.  I just restarted IIS to verify it would work on a reboot and it didn't like that.  OWA and IIS are a bit too finicky. :(

I'm certainly certain that all the messages not displayed in OWA have either embedded attachments in the message body, or embedded links.  Messages with attachments not embedded in the body will open up, but trying to open the attachment will result in a "Page not found" as well.
dane_mAuthor Commented:
I will never use the word "certain" again, when referring to Microsoft products. :)  Here's the latest:

I can't open a message that contains the following in the subject line:

Two or more periods (...)
A period and a forwardslash (./)
backslash (\)
Colon (:)
Percent sign (%)
Ampersand (&)

Information I've collected refers to this as character blocking as part of the URLScan application which can be installed with IIS.  But I never installed URLScan and it's not currently on the system.  The only unique factor I can find is that I'm running this on a Small Business Server 2003 box.

For troubleshooting purposes, I have installed the exact same configuration (Win2k3/Exch2k3/OWA) on another server, but used standalone Windows Server and Exchange software (not SBS).

The Win2003/Exch2003 server does not experience the character blocking that the SBS2003 server does, and neither have URLScan installed.

I'm guessing that SBS2003 is blocking these by default without the need for URLScan, so I'm looking for suggestions to where the character blocking can be disabled.

I found this on a forum, it might help. I'm still looking a bit more into it, but i never worked with SBS. I like to work with the complete products, this somehow works better... And as you might know by now, never trust Microsoft **** until it is tested and tested or about 10 years old, then it should be working.. ;)

Try as hard as you will to get your sbs2003 server to run remote web workplace and owa, you will not get very far if your isp has acess contol lists blocking inbound ports at the routers. Very responsible of them but not very fun for faultfinding.

For anyone that is having trouble getting SBS2003 web access running, ensure that the following inbound ports are open at the ISP, the firewall (if you have one) and the 2003 server:

21 FTP Enables external and internal file transfer
25 Exchange Server Enables incoming and outgoing SMTP mail
80 (http://) IIS Enables all nonsecure browser access, including: internal access to IIS Webs including the company Web, Windows SharePoint Web, Windows SharePoint administration Web, and server monitoring and usage reports Enables internal access to Exchange by OWA and OMA clients
110 POP3 Enables Exchange to accept incoming POP3 mail
123 (UDP port) NTP Enables the system to synchronize time with an external Network Time Protocol (NTP) server
143 IMAP4 Enables Exchange to accept incoming IMAP4-compliant messages
220 IMAP3 Enables Exchange to accept incoming IMAP3-compliant messages
443 (https://) Outlook Enables all secure browser access, including external access to Exchange for Outlook 2003, OWA, and OMA clients; required for external access to server monitoring and usage reports
444 Windows Share Point Services Enables internal and external access to the SharePoint Web
500 IPSec Enables external VPN connections by using IPSec
1701 L2TP clients Enables external L2TP VPN connections
1723 PPTP clients Enables external PPTP VPN connections
3389 Terminal Services Enables internal and external Terminal Services client connections
4125 (Note: you can change this port in RRAS) Remote Web Workplace Enables external OWA access to Exchange, plus internal and external HTTPS access to the client Web site
4500 IPSec Internet Key Exchange (IKE) Network Address Translation (NAT) traversal

Good luck and drop me a line if you have any questions on SBS2003.

Cheers, G.
David WilhoitSenior Consultant, ExchangeCommented:
Here's some default perm settings for IIS and OWA, I'll find something more and post it later...


dane_mAuthor Commented:
I found the solution.  It was the lack of Integrated Auth enabled for the Exchange vdir.  Still not sure why that caused these symptoms, but it's working now!  None of the MS KB articles or other info I found mentioned the need for Integrated Auth for OWA to work.  The odd thing is that I have another server that has Integrated Auth disabled on the entire web site and OWA works fine.  It might be an SBS thing.

Please close this question.  Thanks.
PAQed, with points refunded (500)

Community Support Moderator
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.

Join & Write a Comment

Featured Post

Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now