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?
Troubleshooting
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
http://technet.microsoft.com/en-us/library/bb885041.aspx
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"
http://support.microsoft.com/default.aspx?scid=kb;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
http://support.microsoft.com/default.aspx?scid=kb;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
http://support.microsoft.com/default.aspx?scid=kb;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
