Despite our attempts at documenting various break/fix scenarios, it can often be frustrating when trying to locate the information you need to resolve an issue as quickly as you would like. I decided to share this information in an attempt to help you resolve the majority of issues that can prevent your users from successfully logging on to Outlook Web Access. It won't resolve 100% of the issues and it's not intended to. It's also not intended as a "complete" with step-by-step instructions for each scenario. Rather, in most cases it will help you approach the issue logically and determine your best course of action and which resources to review to learn more about the scenario as well as how to fix your issue. In any event, it's a good resource to peruse before picking up the phone to speak with technical support.


The following should guide you through eliminating the most common root causes for this type of scenario. If nothing else, working through these steps should provide you with enough information such that you can minimize your time on the phone should you still find it necessary to call technical support.


Probing questions


Before you can effectively troubleshoot this issue you should know, or confirm, the following information:


1. If users are receiving an error, what is the exact wording of the error message and does it include an HTTP (IIS) status code that can help you isolate root cause?

2. If a call stack is provided when clicking Show Details, does the exception provide any clue that can help you isolate root cause?


3. Is everyone affected or only some users? For instance, does the issue affect only users connecting from outside the network or everyone regardless of their location? If only users connecting over the Internet are affected, then there's a high probability that Exchange is fine and the cause of the issue is related to a firewall, proxy server, or hardware device like an SSL Accelerator or load balancer. NOTE: Another good test to run if you suspect root cause might be your firewall or network is to try logging on to OWA from the console of the Client Access Server itself.

4. If only some users are affected, does the issue happen from multiple workstations using the same user account? This should help you determine if the issue is user specific or machine specific.

5. If you still have Exchange 2003 mailbox servers in your org, does the issue affect Exchange 2003 and/or Exchange 2007 users who try connecting through the Exchange 2007 CAS?


6. Is the server users connect to a standalone Client Access Server or is the Mailbox role also installed on the same machine?

7. How many Active Directory sites are there? If more than one, which site has the Internet-facing CAS server?  Which site has the mailbox server where affected users are homed?

8. Is the CAS server in a perimeter network or DMZ?

9. Did it ever work? If yes, what changes have been made in the environment, i.e.
software updates, service packs, rollups, new hardware, firewall changes, etc?





Now that you have a clearer understanding of the issue and environment, let's eliminate the low hanging fruit.


1. If you're in a mixed environment with Exchange 2003 or 2000 and only users homed on Exchange 2003 are unable to log on, read the following with special attention to the Deployment Scenarios section:


Outlook Web Access and Exchange 2007, Exchange 2003, and Exchange 2000 Coexistence


2. If Exchange 2003 users connecting through Exchange 2007 receive, "Page cannot be displayed", followed by, "Cannot find server or DNS error", and the CAS role is co-located with the Mailbox role, then you will need to deploy a standalone Client Access Server. This is also documented in the coexistence documentation above and is necessary if you intend on having Exchange 2003 users use OWA to connect to their mailbox across the Internet.


3. If Exchange 2007 is deployed across multiple Active Directory sites with an Internet-facing CAS server in one site and other CAS servers in "proxy" sites, read our Redirection and Proxy documentation. Briefly, when you configure your CAS servers for this scenario you must have an external URL entered for the /owa virtual directory in Exchange Management Console. Authentication will typically be either forms-based (FBA) or basic auth. However, the CAS servers in the proxy sites need to be configured quite differently. The InternalUrl for the /owa vdir in the console should be the internal FQDN of the server and the External URL should be blank, or null. Authentication for /owa MUST be set to Integrated Windows Authentication which means you cannot enable FBA on the CAS servers in the proxy sites. If this isn't set up correctly and users with mailboxes in the proxy site are unable to connect, then you should see an event ID 41 for source MSExchange OWA on the Internet-facing CAS.


4. Several different issues can cause a 440 Login Timeout error. If users are seeing this, read the following Knowledge Base article:


941201          Error message when you try to log on to Exchange 2007 by using Outlook Web Access: "440 Login Timeout";EN-US;941201


5. If users see "Service Unavailable" when they try to connect, it's possible you intentionally or inadvertently installed the 32-bit version of the.Net Framework. To resolve this issue, refer to the instructions for Asp.Net version 2, 64-bit, in the following Knowledge Base article:


894435          How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version of ASP.NET 2.0 on a 64-bit version of Windows;EN-US;894435


6. If users report seeing a blank page when connecting to OWA, this might be due to
a recent rollup being applied that didn't install correctly. For more information,
see kb 935490 which applies to all rollups and not just Rollup 2.


935490          Description of Update Rollup 2 for Exchange 2007;EN-US;935490


I hope this helps! As I mentioned earlier, this won't help you resolve every single OWA logon issue. But it's a good place to start and some of the procedures may lead to solutions that aren't documented here.


- Joe Turick


Not applicable
Hi guys,

just fyi, Windows 7 (latest build 7000, beta) breaks Outlook 2007 outlook anywhere connections.  The basic auth box will come up, but it refuses to authenticate.  RPCdiag shows nothing, so it doesn't appear to be getting past authentication at all.  OWA works just fine with ie8.
Not applicable
same with Outlook 2003...
Not applicable
Just an update - NTLM authentication works, but Basic auth doesn't...
Not applicable
sound like a good troubleshooting guidelines when troubleshooting OWA. good resources.
Not applicable
I don't have OWA login issues, I have OWA STAY login issues.  I'm using a ISA Server 2006 and Exchange 2007 and my users often have to re-login, especially when they do something that spawns a new window.  Would like a posting on how to diagnose this.
Not applicable
When do you fix the bug that makes OWA look on different browsers than IE look like shit?
If you don't fix this in the next SP, we're off Exchange, after using it since v5, I'm really sick of telling my users to "must use IE" to get just the basic features which every web service allows them to use.
Implement it, or loose another customer.

Not applicable
Same problem here too, i use and can't connect once I've installed windows 7.

I hope there is an update for this soon!
Not applicable
Same problem. Windows 7 with Outlook 2007 RPC over HTTP not authenticating on hosted Exchange. I am also hoping for a quick fix to this key functionality.
Not applicable
Same problem here with win7beta1+outlook2007 and  
Not applicable
Just got done installing Windows 7 and Outlook 2007 running into the problem above trying to connect to my Exchange server.
Not applicable
ok I got it working after 2000 tries and searching all over the place.
instead of just using the email address for the username I had to use it in this format
user:  <domain><exchange SAMS id>

for ihostexchange it was
so if my email was
if your email was
Not applicable
ok I got it working after 2000 tries and searching all over the place.
instead of just using the email address for the username when you need to authenticate you need to use this format
user:  <domain><exchange SAMS id>

so if my email was hosted by it would look like this
user: ihostbilly_qwertyuiopasdf

sorry if it's a bit confusing. maybe it will help someone.
Not applicable
I have confirmed that the work around that Billy Kalambas stated, works.

I used the format:
<domain><exchange SAMS id>

and was able to log in finally.
Not applicable
If you use firefox, try IEtabs add-in to view your OWA site.  You get the full featured OWA site inside firefox!
Not applicable
Im feeling like the biggest idiot on the planet right now. Im running out of time for this deployment. I have spent the last week non stop on this problem. 40 to 50 hours. I have done every fix I could find on the internet. And I mean everything. recreating

all Certs, Reinstalling CAS, reinstalling and repermissioning OWA, etc. In need CAS to CAS proxying working and I just cant get it to work. The error I keep ending up at when I expect it to work is the SSL error.



User host address:


EX Address: /o=xxxxxxxx/ou=First Administrative Group/cn=Recipients/cn=testuser1

SMTP Address: testuser1@xxxxxxxx

OWA version: 8.1.340.0

Second CAS for proxy:



Exception type: Microsoft.Exchange.Clients.Owa.Core.OwaProxyException

Exception message: The CAS server is most likely not configured for SSL (it returned a 403)

Call stack

No callstack available

Im pulling my hair out on this. I dont usually fail at fixing a problem. But I must be missing something.