Outlook Web Access (OWA) is an indispensable application in many organizations because it allows users to check their e-mail from anywhere in the world using only a Web browser. Unfortunately, OWA doesn’t always work the way that it’s supposed to. In this Daily Drill Down, I’ll show you what to do when OWA breaks down.
What OWA does
An OWA environment is nothing more than an IIS-based Web application with an interface to the Exchange stores. Clients access the OWA site by making a request to the IIS server over port 80 (HTTP) or port 443 (HTTPS). Once the initial request has been processed, the IIS Server asks the client for authentication credentials. The OWA Server takes these credentials and attempts to authenticate the client. Once they’re authenticated, clients can access their Exchange e-mail accounts.
Problems with OWA
Problems with OWA can usually be traced to one of the following areas:
- The client’s Web browser
- The client’s connection to the IIS Server
- An IIS problem
- An Exchange problem
Any one or any combination of these problems can keep OWA from functioning. Naturally, some of the problems that I just described are a little tougher to troubleshoot than others. Therefore, I’ll start with the easier solutions and build up to the more complex troubleshooting issues.
Client problems
There are many different types of OWA problems, but what the client gets often yields clues as to the nature of the problem. For example, a message stating that a Web site can’t be found means something completely different from a message indicating that the page isn’t displaying correctly.
If the client receives a message stating that the OWA Web site can’t be found, there are a number of possible causes to investigate. I recommend troubleshooting such a problem by first trying to access the OWA server from another computer. If other computers can access the OWA site, then the problem is likely with the computer in question’s Internet connection and not with OWA.
On the other hand, if none of the computers that you attempt to access OWA through can attach to the OWA server, then you have a more serious problem. The WAN connection linking the OWA Server to the Internet may be down; IIS could be malfunctioning; or there could be an invalid DNS entry that’s pointing the OWA server’s FQDN to an invalid or incorrect IP address. I’ll discuss these problems in a bit more detail later on.
Another possibility is that the client is able to access the OWA site, but the site displays incorrectly, or the user isn’t allowed to log in. Again, begin the troubleshooting process by trying a different computer. This particular problem is often due to someone using an unsupported Web browser to access OWA. However, if you discover that none of your test computers can authenticate into the OWA Server, it’s likely that you have an authentication problem on the server end rather than a Web browser problem.
IIS connection errors
IIS connection problems and other IIS-related malfunctions are among the most common causes of OWA errors. It’s a lot of work to thoroughly troubleshoot IIS problems, but the necessary steps aren’t especially difficult. I recommend beginning the troubleshooting process by going to the OWA Server and verifying its connection to the Internet. If you can surf the Web from the OWA server, you can rule out a connectivity problem.
Next, go to a computer outside your network and attempt to ping your OWA server. Try pinging first by IP address and then by FQDN. If both pings fail, it probably means that your firewall is set to block ICMP packets and that the server won’t respond to a ping. If this happens to you, I recommend trying the ping test from behind your firewall.
A failure of both pings could also mean that there is no connectivity between the machine that you’re pinging from and the OWA server. This won’t apply in this particular case, though, because you’ve already established that the communications link is good.
If the ping by IP address is good but the ping by FQDN fails, then you likely have a DNS problem. Remember that DNS servers resolve FQDNs to IP addresses. Therefore, if a ping by IP address is successful, you can verify that the communications link is good. If this is the case, then the only thing that should cause a ping by FQDN to fail is if the FQDN isn’t being resolved.
Firewall problems
So far you’ve verified that you’ve got a good communications link and that the DNS server is doing its job. If your clients are still unable to connect to the OWA server, it’s probably either due to a firewall problem or an IIS failure.
Testing for a firewall problem is easy. Just try to access the OWA server from behind your firewall. If both the OWA server and the client machine exist on your private network behind the same firewall, you can use the client machine to test the OWA server without the firewall interfering. If the test is successful, then the firewall is your problem. Verify that ports 80 and 443 are open to inbound traffic.
IIS problems
If the firewall doesn’t seem to be the source of your problems, then there’s a really good chance that IIS is causing the problem. To test IIS, begin by selecting the Programs | Administrative Tools | Services commands from the Start menu. When you do, Windows will open the Service Control Manager. Go through the Service Control Manager and verify that the following services are running:
- World Wide Web Publishing Service
- IIS Admin Service
- Protected Storage
- Remote Procedure Call (RPC)
This is also a good time to verify that the various Microsoft Exchange-related services are running as well.
Once you’ve verified that the necessary IIS services are running, open Internet Explorer directly on the OWA Server and enter the OWA Server’s IP address into the browser. If the OWA session starts, IIS is working correctly. If you can’t get OWA to start by entering the IP address, verify that IIS is configured to use the correct IP address.
To verify that IIS is configured to use the correct IP address, select Internet Services Manager from the Administrative Tools menu. When the Internet Information Server console opens, select the OWA Web site from the console tree. Before continuing, verify that the word Stopped doesn’t appear in parenthesis next to the Web site name. If it does, simply right-click the site and select the Start command. If you receive an error message, your OWA site probably has an IP address conflict with another site on the server. To solve this problem, read the following instructions for verifying the IP address, and then try to start the site again.
Verifying the OWA site’s IP address
To verify the site’s IP address, right-click the OWA site and select Properties. On the site’s property sheet, select the Web Site tab and verify that the IP address is correct. By default, the IP address will be set to All Unassigned. However, the All Unassigned setting should be used only for the default Web site. The OWA site should have a dedicated IP address. While on the Web Site tab, you should also verify that the OWA site is configured to use port 80.
If all of your settings are correct but you still can’t access the OWA Web site, the best thing to do is to implement a sample Web site to verify IIS’s functionality. To do so, open the Control Panel and double-click the Network And Dial Up Connections icon. When the Network And Dial Up Connections window opens, right-click your main network connection and select Properties.
On the connection’s property sheet, select the TCP/IP protocol from the list and click the Properties button to reveal the TCP/IP property sheet. On the TCP/IP property sheet, click Advanced to reveal the Advanced TCP/IP Settings property sheet. On the IP Settings tab of the Advanced TCP/IP Settings property sheet, click the Add button under the IP Addresses section and add a unique IP address to the server. Click OK on all of the open windows to close them.
Now, create a directory called Test on your hard disk and place a few random HTML files into it. Be sure to name one of the files INDEX.HTM. At this point, return to the Internet Services Manager. Right-click the server name in the console tree and select New | Web Site. This will launch the Web site creation wizard.
Click Next to bypass the wizard’s introduction screen. You’ll then be asked to enter a description of the site. Enter the words Test Site and click Next. On the following screen, select the IP address that you added to the server from the Enter The IP Address To Use For This Web Site drop-down list. Verify that the site is configured to use TCP port 80, and then click Next. On the following screen, enter C:\TEST as the path to the home directory. You should also make sure that the Allow Anonymous Access To This Web Site check box is selected. You’ll then see a screen asking what permissions should be set for the home directory. Accept the default choices by clicking Next, followed by Finish.
When you’ve completed the test site, you’ll see it appear in the IIS tree with the words Stopped in parenthesis next to it. Right-click the new site and select the Start command from the shortcut menu. The site should now be started.
Next, open Internet Explorer and enter the new site’s IP address followed by INDEX.HTM. For example, if you assigned the address 147.100.100.100 to the site, the format would be http://147.100.100.100/index.htm. If you can access your test site, then IIS is functional and you likely have an authentication problem.
If you discover that IIS is malfunctioning, I recommend reinstalling it. You can do so through the Add/Remove Programs applet in the Control Panel. IIS is located in the Windows Components section.
Authentication problems
The authentication portion of Outlook Web Access tends to be one of the trickiest parts to troubleshoot. When troubleshooting authentication problems, it’s helpful to keep in mind that when your users use OWA, they aren’t telling OWA which Exchange server their mailboxes exist on. Instead, OWA is performing an Active Directory query during the authentication process. This query tells OWA which Exchange server to connect the user to.
It’s quite possible that the Active Directory query could be causing the problem. The easiest way to find out is to enter the URL of the OWA site into the Web browser in a way that conveys the name of the user’s mailbox. For example, if you normally enter http://server_name/exchange, try entering http://server_name/exchange/user_name instead. If this technique works, then the problem could be due to the OWA server’s TCP/IP settings not referencing a DNS server that’s aware of your Active Directory. The other possibility is a problem with the authentication protocol, which is what I’m about to show you how to fix.
When it comes to Windows 2000 authentication, the NTLM authentication protocol is more secure than basic or anonymous authentication. However, in an OWA environment, you must use basic authentication. NTLM doesn’t work if your clients are communicating with the server over HTTP or HTTPS. Likewise, anonymous authentication does work, but it would give everyone in the world access to your server. Therefore, basic authentication is your only real choice.
To verify what type of authentication is being used, open the Internet Services Manager, right-click the OWA Web site, and select Properties. Select the Directory Security tab on the OWA site’s property sheet, and click the Edit button found in the tab’s Anonymous Access And Authentication Control section. When you do, you’ll see the Authentication Methods dialog box. Verify that the Anonymous Access check box is not selected. Now, take a look at the Authenticated Access section and verify that only the Basic Authentication check box is selected. As you look at the various check boxes, you’ll notice an Edit button just to the right of the Basic check box. Click the Edit button and verify that the correct authentication domain is selected.
At this point, close all of the open windows by clicking OK in each. You’ve now specified that the OWA Web site will use basic authentication exclusively, and that a specific domain will perform the authentication. The final step in the process is to verify that the OWA server can communicate with the domain that you’ve specified.
You can start out by attempting to ping domain controllers in the specified domain from the OWA server. If the pings are successful, the next step is to verify that the OWA server is configured to use the same DNS server as all of the domain controllers. Unless all of the servers use a common DNS server (or linked DNS servers), the OWA server may have trouble accessing Active Directory information from the domain controller.
If you’re still having trouble
OWA is a handy Web application, but it doesn’t always work the way it’s supposed to. If you’re still having problems, Microsoft has an excellent document on OWA troubleshooting at Microsoft’s Exchange Web Site.
