Problem solve Get help with specific problems with your technologies, process and projects.

Troubleshooting OWA problems

This article explains OWA symptoms that point to potential IIS configuration issues and how to resolve them.


Outlook Web Access is highly dependent on Internet Information Server. An improperly configured IIS server can cause OWA to malfunction for some or all of your remote users. In this article, I explain which symptoms point to potential IIS configuration issues and how to resolve them.

The symptoms

Obviously, not every OWA problem is going to be IIS-related. So the first step in the OWA troubleshooting process is to recognize the symptoms that frequently point to an IIS-related issue.

IIS is almost always to blame if users are unable to change passwords through OWA (either when they log in or from the options page after login). IIS is also typically to blame if users cannot access the OWA login screen. Of course, failure to access the login screen can also be caused by a malfunctioning Internet connection or an incorrectly typed URL. Finally, if users attempt to access OWA and receive a VBScript Runtime Error, a Directory Listing Denied error, or an HTTP 500 Internal Server Error, then IIS is almost always at the root of the problem.

Verify that the default Web site is properly configured

The first step in finding a resolution is verifying that the OWA server's default Web site is configured correctly:

  1. Open the Internet Information Services Manager tool.

  2. Navigate through the console tree to Internet Information Services -> your server -> Web Sites -> Default Web Site.

  3. Right click on the Default Web site and select Properties.

  4. Click on the Home Directory tab.

  5. Make sure that the Remove button isn't grayed out. If it is, then it means that the default application associated with the Web site has not been established. If this is the case, then click the Create button to create the default application.

  6. Now, switch to Properties -> Directory Security tab.

  7. Locate the tab's Authentication and Access Control section and click the Edit button. This will cause Windows to display the Authentication Methods dialog box.

  8. Verify that the Enable Anonymous Access and the Integrated Windows Authentication checkboxes are selected. (If you are using IIS 4.0, then the Integrated Windows Authentication check box doesn't exist. You will have to use the Windows NT Challenge / Response checkbox instead.)

  9. While you are at it, verify that the appropriate user account has been assigned to the Enable Anonymous Access section. Under normal circumstances, the account will be IUSR_servername.

Configure the Exchange virtual folder

If the Default Web site seems to be configured properly, then your next step in troubleshooting OWA is making sure the Exchange virtual folder is set up properly:

  1. Return to the main Internet Information Services Manager screen and expand the Default Web Site container.

  2. Locate a folder named Exchange beneath the Default Web Site.

  3. Right click on the Exchange folder and select Properties -> Virtual Directory -> Application Settings.

  4. Verify that a Remove button exists. If it doesn't, then you will need to click the Create button to create an application named Exchange.

  5. Now, select the Directory Security tab and click the Edit button found in the Authentication and Access Control section.

  6. Make sure that Anonymous Access and Integrated Windows Authentication are both selected.

  7. Finally, select the Documents tab and verify that the Enable Default Content Page checkbox is selected and that LOGON.ASP is the top document on the list.

    If LOGON.ASP isn't the top document, then scroll through the document list to see if LOGON.ASP exists. If it does exist, select it and then repeatedly click the Move Up button to move the document to the top of the list. If LOGON.ASP doesn't exist, use the Add button to add it and then use the Move Up button to move the LOGON.ASP file to the top of the list.

Troubleshoot password change problems

If you have followed the steps that I have outlined so far, then your users should be able to access the OWA login screen. It is still possible that users may not be able to change passwords through OWA though. The number one cause of this problem is a missing Iisadmpwd folder. IIS 5.0 and 6.0 do not create this folder by default. It's up to the administrator to manually create the folder:

  1. Open the Internet Information Services Manager console and navigate through the console tree to the Default Web Site.

  2. Expand the Default Web Site and look for the presence of a folder named Iisadmpwd. If the folder doesn't exist, right click on the Default Web Site and select the New -> Virtual Directory. Windows will open the Virtual Directory Creation Wizard.

  3. Click Next to bypass the Wizard's Welcome screen.

  4. You will be prompted to enter the virtual directory's alias. Type Iisadmpwd and click Next.

  5. Now enter the path that corresponds to the virtual directory. The path should be \WINNT\SYSTEM32\INETSRV\IISADMPWD (where WINNT is the path to your Windows directory).

  6. Click Next.

  7. You will now be asked for the access permissions for the virtual directory. Make sure that Execute is selected and click Next, followed by Finish.

  8. The last step in this process is to check to make sure that the virtual directory that you have just created is set to allow anonymous access and Integrated Windows Authentication. The procedure for doing so is exactly the same as what you used to check the permissions on the Exchange virtual directory.

Check your security policy

The final portion of the OWA troubleshooting procedure involves making sure that your security policy does not prohibit password changes:

  1. Select the Local Security Policy command from your OWA server's Administrative Tools menu.

  2. When the Local Security Settings console opens, navigate through the console tree to Local Policies -> User Rights Assignment.

  3. Double click on the Log on Locally option in the details pane to reveal the Log on Locally properties sheet.

  4. Verify that Log on Locally permissions are assigned to the IUSR_servername and to the IWAM_servername accounts. While you are at it, make sure that both the Local Policy Setting and Effective Policy Setting options are selected.

  5. Now verify that the IUSR_servername and the IWAM_servername accounts also have Log on As Batch Job and Access This Computer From The Network permissions. After doing so, OWA users should have no problems changing passwords.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at


What must I do if I receive the following error: "HTTP/1.1 507 Insufficient Space to Store Resource"?
—Andrej L.


I don't know a lot about this, but I can tell you that it is an IIS error, not an Exchange error. The error is related to the DAV module not having sufficient space within a storage allocation. The most common cause is that a quota has been set.
—Brien Posey, tip author

Do you have comments on this tip? Let us know.

Related information from

  • Outlook Web Access Administration Guide
  • FAQ: Outlook Web Access
  • Outlook Web Access Reference Center
  • Please let others know how useful this tip is via the rating scale below. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to If we publish it, we'll send you a nifty thank-you gift.

    Dig Deeper on Outlook management