All in all my E2K3 setup FE/BE w/OWA is working great, except for this one pesky little detail. Every once in a while, say 1 or 2 messages per day when you click on them in OWA the preview or if you try and open them you get:
The page cannot be found The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
If you typed the page address in the address bar, make sure that it is spelled correctly. Open the Web site home page, and then look for links to the information you want. If you believe you should be able to view this directory or page, please contact the Web site administrator by using the e-mail address or phone number listed on the Web site home page. File not found
The link takes you to an MS page talking about IIS, but none of the featured articles seems particularly pertinent to my situation. All servers are new W2K3 installs...
RE: "The page cannot be found" on some messages - 30.Mar.2004 11:23:00 PM
Guest
I have been experiencing this as well. My servers are Win2003/Exchange2003, one back-end and one front-end. The front-end is also the internet smtp server and is published via ISA. Several users routinely get "page cannot be found" errors when using OWA but the message displays properly using the mapi client. I found one kb article (Q257891) that seems close but does not resolve the issue. My internal AD domain is <domainname>.net and my primary email domain is <domainname>.com. The @domainname.com address is specified as the primary address in the default recipient policy.
It turns out that the messages that I cannot view contain at least one of the following in the subject line: One or more periods at the end of the subject The percent sign (%) The ampersand (&)
Those appear to be the only characters causing this problem. I tested with dot slash, backslash and colon and had no problems. It appears that these characters are blocked by default for security purposes.
RE: "The page cannot be found" on some messages - 24.Apr.2004 11:47:00 PM
Guest
I'm having the exact same problem with the "Page not found" error on messages with blocked characters in the subject line.
What I can't figure out is what is blocking the characters, as I don't have URLScan installed.
The server with this problem is running SBS2003. I have another completely separate server running its own domain with Exch2003 and OWA, but using standalone installations of Windows Server and Exchange (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. Any ideas?
Well, that makes total sense that URLScan would do that. And if you are running E2K3 on W2K3 then IIS 6 includes URLScan by default. I guess you could say it's a built-in feature of IIS 6 in that's locked-down out of the box. The article in the post above should help you in tuning the URLScan tool to let these messages through. In my experience so far, the only messages that have been blocked have been spam anyway. I recently installed Symantec AV for Exchange v4.0 (E2K3 support) and it includes some primative spam filtering and since I haven't see many of these messages.
quote:Originally posted by James Price: And if you are running E2K3 on W2K3 then IIS 6 includes URLScan by default.
That's the thing, URLScan is not included with IIS6 or Win2k3 by default. There are some basic functions in URLScan from v2.0 (which runs on IIS5 and earlier) that have been included in IIS6 as built-in functionality, but the DenyURLSequence function is not a built-in feature of IIS6.
That's where I'm stuck. There is no urlscan.ini file (or a urlscan folder in inetsrv) on my SBS2003 server to modify.
I have the exact same Exchange/OWA configuration on a non-SBS server which is working great. It's definitely something that Microsoft, in its infinite wisdom, has set as default in SBS2003 IIS, totally forgetting about the need to allow these characters for OWA to work properly.