Troubleshooting OWA 2007 Publishing Rules on ISA Server 2006

1. Introduction


Sometimes troubleshooting publishing rules can be really challenging. The main reason for that is because of the thin line between the published server and the edge firewall (in this case ISA Server). Where is it broken? Is my ISA Server not allowing the connection from outside or my published server that is not answering the request from ISA Server?


The sequence of articles written by Jim Harrison about RPC over HTTP helped to clarify how the protocols works and also to troubleshoot the main issues that happen when publishing Outlook Anywhere through ISA Server 2006.


This post was actually born internally after many collaboration calls with Exchange Engineers and narrowing down if it was an ISA Server problem or an Exchange problem. We could identify the most commons scenarios of errors while publishing OWA through ISA Server 2006.


2. General Recommendations


The main recommendation is to use the official white paper that is a step by step configuration guide to OWA 2007 through ISA Server 2006.


2.1. Authentication Options


When you are publishing OWA 2007 through ISA Server 2006 you have two options for configuring FBA (Forms Based Authentication):


·         Option 1 (Most Common): Disable Forms Base Authentication on the Exchange OWA side and enable FBA on the ISA Server 2006 Web Listener.



Figure 1 – Authentication properties.


Note: When you have Basic Authentication selected on the OWA as showed above, make sure that the Authentication Delegation tab on the ISA Server 2006 OWA Publishing rule has the Basic Authentication selected.


·         Option 2 (Rarely Used): Do not authenticate on the ISA Server 2006 and use the Forms Based Authentication on the Exchange side:



Figure 2 – Second option for authentication.



2.2. Certificate Considerations


When you are publishing OWA 2007 you can still use SAN Certificate on the Exchange OWA side. However the FQDN name that appears on the To Tab on the ISA Server 2006 OWA Publishing rule needs to match with the first name on the SAN Certificate as show below:



Figure 3 – SAN Certificate details. 


Note: Other queries for the other names that are available on the SAN will not work since this version of the ISA Server 2006 (with Supportability Update on it) only uses the first name on the SAN Certificate. This feature is planned to be available on ISA Server 2006 SP1. We had a demo in early April/2008 about ISA Server 2006 SP1 in TechEd Eilat (Israel) and the initial plan is to release SP1 in late summer 2008 but issues could cause delay, so stay tune on .


For more information on SAN certification and Exchange Publishing rule read the blog Certificates with Multiple SAN Entries May Break ISA Server Web Publishing on Microsoft ISA Server Blog Team.


3. Troubleshooting the Most Common Scenarios


3.1. I can access the OWA page, authenticate using Forms Base but after the first authentication I receive another page asking for authentication again.


Make sure that you have forms base authentication enabled only on ISA Server or only on the Exchange. Review the session 2.1 for more information.


3.2. After authenticate on the OWA Forms Base Authentication I receive the error: Target principal name is incorrect.


Make sure that of the following:

·         The name on the certificate that is installed on the Exchange Server matches with the name on the To tab for the OWA Publishing Rule on ISA Server. Review session 2.3 for more information.

·         The Exchange Server name (usually the CAS Server) is correct on the To tab on the OWA Publishing Rule on ISA Server.

·         ISA Server 2006 can correctly resolve this FQDN for the correct IP.


3.3. I cannot even access the OWA Page, when I type the address on IE I receive the error: 403 Access Forbidden.


When you create an OWA 2007 Publishing Rule only the following paths are allowed by default:



Figure 4 – Default paths for OWA 2007.


When you type without use /owa or the other paths that are allowed by this rule it is expected to receive the 403 since ISA Server is restricting the paths for security purpose.


3.4. I’m typing the address on Internet Explorer, I can reach the FBA page, authenticate but after that I’m receiving the error: 404 Not Found.


Make sure that the ISA Server 2006 can reach the Exchange Server that it is using on the To tab. Try to validate using the following methods:

·         From the ISA Server ping the FQDN name of the Exchange Server that is in use on the OWA Publishing to make sure that is resolving to the correct IP.

·         Telnet from ISA Server to the FQDN of the Exchange Server and use the port that appears on the Bridging tab as show below and see if you receive an answer (telnet exc2007.contoso.msft 443):


Figure 5 – Bridging Tab.


·         If all tests succeed then enable logging on ISA Server (ISA Console / Monitoring / Logging) and create a filter where the source is the External network. Try to reproduce the problem and check if you see the error below:



Figure 6 – Failed connection attempt to the Exchange Server (error 10060).


The error 10060 showed above means that the connection timed out. Usually this error means:

·         Connectivity issue between ISA Server and the Exchange Server that is being used by this publishing rule.

·         The ISA Server is sending the package by for some reason the Exchange Server is not replying in appropriate manner.


Review the following:

·         There is any other firewall in between ISA Server and the Exchange Server? If it does, can we bypass that? If we can’t bypass, make sure that the ports are allowed in both ways. Use PortQuery to test that from the ISA to the Exchange Server.

·         A netmon trace on the internal NIC of the ISA and on the Exchange Server might show what is happening.

·         The IIS Logs on the OWA also will help to see if the traffic is hitting the OWA Server.



3.5. I’m typing the address on Internet Explorer, I can reach the FBA page, authenticate but after that I’m receiving the error: 10061 Connection Refused.


The error code 10061 means: A connection was refused by the destination host. This error means that ISA Server tried to contact the published server (in this case the Exchange Server) and this server refused the request for some reason.


This usually happens because ISA Server tried to contact the published server on a port that is not allowed on the destination server. Review the Bridging tab on the OWA Publishing rule to make sure that this port matches with the port that OWA is using on the IIS web site:


Figure 7 – IIS properties matching with the Bridging tab.


If you also use the ISA Server Monitoring Logging you will see the error below:



Figure 8 – Failed connection attempt to the Exchange Server (error 10061).


For more information about the error code see the ISA Server 2006 Logging Fields and Values article.


3.6. I can authenticate on the FBA page, I can see my OWA inbox but I’m unable to create a new message and the buttons on the toolbar doesn’t work. Everything works fine internally (bypassing the ISA Server).


Don’t set your mind to think that if works internally and externally doesn’t then the issue is on the ISA Server. There are some 3rd Party ISAPI filters (for example the one mentioned on KB 924228 ) that could be installed on the Exchange Server (Backend, FrontEnd, CAS or Mailbox Server) that can cause this behavior when the traffic crosses the ISA Server. A more in depth investigation will be necessary to determine the root cause in this situation.



4. Conclusion


As you can see these are the most common problems that might happen during the OWA publishing through ISA Server 2006. If you still have problem, a good advice before call Microsoft to open an incident is to use the ISA Server BPA and check if there is any recommendation on that. ISABPA does a pretty good job identifying mistakes o the configuration for the publishing rule and making suggestions on how to fix it.



Yuri Diogenes

Security Support Engineer – ISA Server Team

Microsoft Texas


Comments (5)

  1. Anonymous says:


    I’ve heard that when using Forms Based Authentication on the Web Lister for OWA, that doesn’t allow for using NTLM authentication for Outlook Anywhere, using the same web listener.  So basic authentication has to be used for Outlook Anywhere, which requires users to manually input their credentials.  Is that correct?

    Would I need to have an additional web listener configured with NTLM authentication for Outlook Anywhere access, besides the Forms Based Authentication web listener used for OWA?  Does it mean I would also need an additional public IP address?  Please advice.

    Thank you very much

  2. Anonymous says:

    We use ISA server 2006 with SP1 to publish Exchange OWA. Any path is specify when we start a session to the OWA server. For example :, in this case we cannot access the logon page on the CAS server.

    But if we use the url with /OWA path, we get OWA logon page.

    Why it’s works ? i don’y know because the FBA is enable on the both side, on the edge firewall and the Exchange CAS Server.

    It’s very amazing.


  3. Anonymous says:

    And what authentication i have to select on listener’s properties? HTTP Authentication: Integrated ?

  4. The reason for that is because the fallback from forms-based authentication is to Basic authentication, for non-browser clients (such as Outlook Client).

    More info on this behavior check the article:

    If you want to use NTLM for your Outlook Anywhere access than you need to use another listener with another IP, another rule and use KCD as delegation method.


  5. Boobalan says:

    Hi ,

    I am publishing OWA 2010 through TMG 2010. OWA and TMG authentication i made as Basic Authentication. And i pointed my "" A record to TMG IP( . alll the internal and external user are connectiong through TMG. I am getting OWA login page through TMG. Everything was working fine. But now i am facing problem in OWA login authentication, when i give domainusername and password its not logining in to OWA. Kindly help me.

    Thanks in advance.

Skip to main content