For initial troubleshooting, run the Microsoft ISA Server Best Practices Analyzer Tool. This tool scans configuration settings of the local ISA Server computer, and reports issues that do not conform to best practices. The ISA Server Best Practices Analyzer can run on ISA Server 2006 or ISA Server 2004. In Enterprise Edition, run the ISA Server Best Practices Analyzer on each array member. Microsoft .NET Framework 1.1 must be installed on the computer.

Install and run the ISA Server Best Practices Analyzer as follows:

1. Download from the Microsoft Download Center. Installation files are copied to the %SystemDrive%\Program Files\IsaBPA folder.
   
2. Run the tool. To do this, click Start, point to All Programs, point to Microsoft ISA Server, point to ISA Tools, and then click ISA Server Best Practices Analyzer. Then click Start a scan.
   

Each ISA Server Best Practices Analyzer error or warning message has an associated Help topic, with instructions about how to fix the issue.

For issues following installation or upgrade, check the following:

1. Ensure you have a publishing rule to allow external clients to access the Outlook Web Access site. Rules are created using the New Publishing Rule Wizard. For more information, see the following documents at Microsoft TechNet:
   
   • Using ISA Server 2006 with Outlook Web Access
     
   • Configuring ISA Server 2006 for Exchange Client Access
     
   • Secure Application Publishing
     
   • Publishing Exchange Server 2007 with ISA Server 2006
     
2. Check rule ordering. If there is a deny rule blocking access to the site, and this rule is ordered before the allow rule, the deny rule will be processed first. Rules should follow this order from the top of the rule list:
   
   1. Global deny rules. Rules that deny access to all users.
      
   2. Global allow rules. Rules that allow specific access to all users.
      
   3. Rules for specific computers.
      
   4. Rules for specific users, URLs, and MIME types.
      
   5. Other allow rules.
      
   6. Default deny rule, which is at the bottom of the list. Requests not matched by any other rule in the list are blocked by this default rule.
      
3. When you upgrade from ISA Server 2004 Standard Edition to ISA Server 2004 Enterprise Edition, and then to ISA Server 2006 Enterprise Edition, upgraded Exchange publishing rules do not have credential delegation enabled by default. Users allowed access with these rules will be prompted twice for credentials. Check delegation settings on these upgraded rules. For more information, see Microsoft article 935767.
   

If some or all users cannot connect to the Outlook Web Access site, check the following:

1. Syntax issues:
   
   • Ensure that the user is typing the correct URL.
     
   • Check that the user is specifying credentials with the syntax \.
     
   • Check that a user is typing a correct password, and that the CAPS LOCK feature is not turned on.
     
   • Ask the user to access another Web page to check that the browser is not the issue.
     
   • Log on to the mailbox from another non-administrator account to check that it is available. If the new account is working, compare the Active Directory® directory service configuration for that account with the user account that is not working.
     
2. Name resolution issues:
   
   • Internal clients on the same network as the Exchange server should not loop through the ISA Server external interface to access the published server. Instead, these clients should access the published server directly, and they must be able to internally resolve the fully qualified domain name (FQDN) of the published server. They may use an internal Domain Name System (DNS) server with a resource record for name resolution, or through means of a Hosts file on the client. Note the following:
     
   • SecureNAT clients (with a default gateway pointing to ISA Server) handle their own name resolution, and the internal DNS server that they use must resolve the site name.
     
   • For Firewall clients, specify the FQDN for direct access. For more information, see the section "Firewall Client Local Addresses" in "Internal Client Concepts in ISA Server 2006" at Microsoft TechNet.
     
   • Client computers making requests as Web proxy clients should be configured for direct access. For more information, see the section "Web Proxy Clients" in "Internal Client Concepts in ISA Server 2006" at Microsoft TechNet.
     
3. Rule configuration:
   
   • Check the properties of the Outlook Web Access publishing rule.
     
   • Check that the user is not being denied access by some other rule that is ordered higher in the rule list.
     

ISA Server provides support for publishing Outlook Web Access with a single network adapter. In this configuration, check the following:

1. Ensure that ISA Server is configured with the Single Network Adapter network template.
   
2. When you install ISA Server on a computer with a single network adapter, ISA Server is only aware of two networks: the Local Host network that represents the ISA Server computer itself, and the Internal network, which includes all unicast IP addresses that are not part of the Local Host network. Ensure that the Web listener you select in the Outlook Web Access publishing rule is configured to listen on the Internal network.
   

For connection issues, check the following:

1. To check whether the connection issue is associated with a specific client computer, try to connect to the Outlook Web Access site from an alternative computer.
   
2. If no computers can access the Outlook Web Access site, check that the site is available and running.
   
3. Check the following DNS and name issues:
   
   • External Internet clients require a valid public DNS entry to resolve requests. The domain name can be registered with a public DNS server to resolve the name to the appropriate IP address of the ISA Server computer (usually the IP address of the external adapter).
     
   • The name specified in external client requests for the Outlook Web Access site must match the FQDN specified in the Common Name field of the server certificate used by ISA Server to authenticate to the client.
     
   • Checks to verify name resolution include the following:
     
   • To test the deployment, you can specify the name resolution information in the Hosts file. When you connect to the Outlook Web Access site (for example http://mail.fabrikam.com/exchange), a logon page should appear, allowing you to input credentials.
     
   • Use the Nslookup.exe command-line tool to check that the external Web site name is resolved as expected. For more information, see "Nslookup" at Microsoft TechNet.
     

For logon issues or authentication problems, check the following:

1. Use the full URL when connecting with Outlook Web Access, for example, http://servername/exchange/username. With Outlook Web Access, users do not need to know the full URL to their mailbox to log on. They type http://servername/exchange and when prompted by the browser, enter their user name and password. Exchange then uses the user name and password information to look up the full URL path to the user's mailbox in Active Directory, and then routes the user to the correct mailbox. When you connect using the full URL, Exchange does not perform the Active Directory lookup. If you can access the mailbox using the full URL, but cannot access the mailbox by logging on with the shorter URL, the access problem may be related to authentication.
   
2. Set the authentication method to Basic. This is particularly useful for access problems due to improperly configured permissions. For security reasons, never select Basic authentication as your only authentication method unless you also use Secure Sockets Layer (SSL) encryption. If using Basic authentication with no other authentication method allows you to access the mailbox, the access problem may be caused by Integrated Windows authentication or Anonymous access. Integrated Windows Authentication refers to authentication mechanisms registered on the Exchange server, such as NTLM and Kerberos.
   
3. Check HTTP errors. Users may receive a number of common HTTP errors when accessing an Outlook Web Access site, including the following:
   
   • 401 Access Denied and 401 Logon Failed. Indicates that the user name or password is incorrect. Verify that the password has been specified correctly, and that the CAP LOCKS feature is not turned on. Ensure that the name is specified with the syntax "\". If the user account was recently created, it may take a few minutes for it to be properly initialized.
     
   • 403 Access Denied. Indicates that the user authenticated successfully, but cannot access a resource. For example, the user attempted to access the server with http://, when https:// is required. Ensure that the Exchange virtual directory that the user is trying to access is available.
     
   • 404 Not Found. Indicates that an item requested does not exist in a specified location. This can happen if an item has been denied. In addition, ensure that users are typing a correct URL to access a resource.
     
   • 405 Method Not Allowed. May indicate that the running of scripts or executable files is not allowed, and you attempted to run an .asp page or access a .dll file.
     
   • 500 Internal Server Error. May indicate that the Exchange server is unable to contact Active Directory. It may also indicate general Internet Information Services (IIS) authentication issues. It can also occur when the user browser supports Kerberos authentication, and the difference in clock settings between the client computer and the Exchange server is greater than five minutes. Try synchronizing the time.
     
4. Check whether forms-based authentication is enabled on both the ISA Server computer and the Exchange computer. It should be configured only on one of them.
   
5. Check that users can authenticate in accordance with the authentication settings specified in the publishing rule. For example, if a rule has a condition allowing access only to a specific group account, ensure that users that require access belong to the group.
   
6. Check the bridging configuration of the rule. For example, if bridging is configured to redirect HTTPS requests over HTTPS to the published server, ensure that the Web listener used by the rule is listening for HTTPS requests.
   
7. If there is an issue for users who type http://www.address.com instead of https://www.address.com, ensure that redirection settings are configured as required. In ISA Server 2004, you can create a Web page that provides a link that users can click to take them to the https site. In ISA Server 2006, you can enable HTTP to HTTPS redirection in ISA Server Management, as shown in the following procedure.
   To enable HTTP to HTTPS redirection

   1. In ISA Server Management, click the Firewall Policy node.

   2. On the Toolbox tab, right-click the Web listener used by the rule that allows users access, and then click Properties.

   3. On the Connections tab, ensure that Enable HTTP connections on port and Enable SSL (HTTPS) connections on port are selected.

   4. Select one of the following options:

      • To redirect all traffic handled by this listener, select Redirect all traffic from HTTP to HTTPS.
        
      • To redirect only requests from authenticated users, select Redirect authentication traffic from HTTP to HTTPS. This option is useful when you are publishing a secure Outlook Web Access site requiring authentication and a non-secure site with anonymous access using the same Web listener.
        

If a problem arises when requesting a certificate, do the following:

1. Ensure that you are requesting a certificate correctly:
   
   • Use the Certificates Microsoft Management Console (MMC) snap-in to request a certificate from an enterprise certification authority (CA) when ISA Server is a member of an enterprise CA domain. Otherwise, use the Web enrollment site to request a certificate. The CA root certificate of the enterprise CA is automatically entered into the Trusted Root Certification Authorities store for all computers in the same domain as the CA. If the ISA Server computer is not a domain member, manually place the CA certificate into the Trusted Root Certification Authorities store on the ISA Server computer.
     
2. If you receive a message that the CA is not started or there is a permissions problem, this may indicate an issue with DCOM that is required to acquire a certificate. As a workaround, do the following:
   
   • Disable the RPC setting as follows:
     If ISA Server is requesting the certificate, edit the system policy rule.
     If an internal host is requesting the certificate from another network through ISA Server, edit the access rule allowing DCOM traffic between the different networks.
     
   • Whether it is ISA Server requesting a certificate or an internal host requesting a certificate from another network, after clearing the Enforce strict RPC compliance setting, you need to create a rule to allow all traffic or a rule for a custom protocol.
     To edit the RPC setting in the system policy rule

     1. In ISA Server Management, click the Firewall Policy node.

     2. On the Tasks tab, click Edit System Policy.

     3. In the Configuration Groups list, select the Active Directory group.

     4. On the General tab, clear the Enforce strict RPC compliance check box.

     To edit the RPC setting in the access rule

     1. In ISA Server Management, click the Firewall Policy node, and then select the required rule.

     2. On the Tasks tab, click Edit Selected Rule.

     3. On the Protocols tab, click Filtering, and then click Configure RPC Protocol.

     4. Clear the Enforce strict RPC compliance check box.

     5. On the Configuration node of ISA Server Management, click Add-Ins.

     6. Right-click RPC Filter in the details pane, and then click Disable.

     7. Repeat this procedure for any other access rules that are configured between the networks. Ensure that you enable all settings again after requesting the certificate.

If you receive the error message: "500 Internal Server Error – The target principal name is incorrect", check the following:

• The name of the server certificate used by ISA Server to authenticate to the external client must match the name that the external client types in the browser to reach the ISA Server computer.
  
• If you are using HTTPS to HTTPS bridging (where the client authenticates to ISA Server over HTTPS and ISA Server forwards the request to the published Web server over HTTPS), the name of the server certificate that the published server uses to authenticate to the ISA Server computer must match the internal server name specified on the To tab of the publishing rule properties.
  
• If you use the same server certificate to authenticate the ISA Server computer to the client and the published Web server to the ISA Server computer, the URL typed by the client and the internal name of the Web server must be the same as the common name of the certificate. To resolve the issue, either obtain a new certificate that matches the required name, or modify the internal name and external name to match the common name on the certificate. Ensure that ISA Server can resolve the internal name of the published Web site. If you modify the name on the To tab, one way to ensure that the name can be resolved is to add a Hosts file entry on the ISA Server computer (WINNT\system32\drivers\etc\hosts) to map the name and IP address of the published site.
  
• If you are using a wildcard certificate on the ISA Server computer, note the following:
  
  • When using HTTPS to HTTP bridging in ISA Server 2004, you cannot use a wildcard certificate to authenticate to the back-end Web server. Instead, on the internal Web server, create a new certificate that matches the name of the internal Web server, as specified on the To tab in the Web publishing rule.
    
  • Use of wildcard certificates on the back-end server is supported in ISA Server 2006.
    

If you receive the error message: "500 Internal Server Error - The certificate chain was issued by an authority that is not trusted", do the following:

• Check that ISA Server trusts the CA that issued the certificate used to authenticate the published Web server, as described in the following procedure.
  To check certificate trust

  1. In Internal Explorer, click the Tools menu, and then click Internet Options.

  2. On the Content tab, click Certificates.

  3. On the Trusted Root Certification Authorities tab, check that a certificate for the CA appears.

• Ensure that there is a trust relationship defined between the installed certificate and the issuing CA. To do this, on the Certification Path of the certificate properties, you should see a hierarchical relationship, and a note that states: This certificate is OK.
  

If you receive a message that the certificate cannot be found, this indicates that the certificate was not imported to the correct certificate store, or that you did not choose to export the private key during the export certificate process. Do the following:

• Check that the certificate was imported under the Local Computer account and stored in the Personal certificates store.
  
• Ensure that the certificate has a corresponding private key on the Details tab of the certificate properties. If it does not, you will not be able to bind it to a Web listener when you create the Web publishing rule. If it is the certificate you imported to ISA Server from the Web server, export it again from the Web server, and repeat the import to the ISA Server computer.
  

If you receive a message that it is the wrong type of certificate, check that the relevant usage of the certificate is correctly configured. To do this, in the MMC Certificates snap-in, right-click the certificate, and then click Properties. Select Enable only the following purposes, and make sure that Server Authentication is selected.

If you receive a message about the validity of the certificate, check the validity information on the General tab of the certificate properties.

To troubleshoot issues with e-mail through Outlook Web Access, do the following:

• If you are authenticating using SecurID credentials and you receive an invalid SecurID passcode message when you try to access a file or application for download by clicking the Information bar in Internet Explorer, add the URL of the file or application to the trusted sites list in Internet Explorer. For more information, see "You are repeatedly prompted for credentials when you use SecurID authentication to access a document or program that is published by ISA Server 2006" at Microsoft Help and Support.
  
• If you cannot download attachments and you receive an attachment blocked message, ensure that the setting to block attachments is not enabled, as described in the following procedure.
  To verify block attachments settings

  1. In ISA Server Management, click the Firewall Policy node.

  2. On the Toolbox tab, click Network Objects.

  3. On the toolbar beneath Network Objects, click Edit.

  4. On the Preferences tab, click Authentication.

  5. Verify that the forms-based authentication method is selected, and then click Configure:

     • If Outlook Web Access clients are not allowed to receive attachments on public computers, select Clients on public machines.
       
     • If Outlook Web Access clients are not allowed to receive attachments on private computers, select Clients on private machines.
       

This section summarizes common issues that you may encounter.

Identical certificate on each array server

Modifying the forms-based authentication page

Common Name field of certificate

500 Internal Server Error – The target principal name is incorrect

Publishing multiple SSL sites using the same IP address and port

500 Internal Server Error – The certificate chain was issued by an authority that is not trusted

No certificates configured on this server

Multiple common names on certificate