Lync 2013 EWS With Forefront TMG 2010 Issues

I recently performed a Microsoft Lync Sever 2013 migration and following this process I noted that Lync 2013 clients connecting from external networks were continually prompted for Outlook authentication in order to retrieve data from Exchange Web Services (EWS). After investigating the issue, it appears this occurs when utilising forms based authentication for the /Autodiscover/* and /EWS/* virtual directories when utilising an SSL web listener in Forefront TMG 2010. In order to resolve the issue a separate global IP address was obtained and assigned to a web listener that does not perform any pre-authentication and simply passes the authentication request directly to Exchange Server 2010. The reason a separate global IP address and web listener was utilised, is that should you be using a single web listener for all Exchange services you will need to disable forms based authentication for OWA, Outlook Anywhere and Exchange ActiveSync, in most environment this would not be a desirable approach, however using a separate listener purely for autodiscover and EWS satisfies most security requirements. The following steps were performed in Forefront TMG 2010 to resolve the issue.

1. In Forefront TMG 2010 right click “Firewall Policy” -> “New” -> “Exchange Web Client Access Publishing Rule”.

2. When the wizard invokes enter a name for the publishing rule such as “Exchange Web Services” and click Next.

3. On the select services page click the drop down item and select the appropriate version of Exchange Server for your environment, and then check to select “Outlook Anywhere (RPC\HTTP(s))” and then also select “Publish additional folders on the Exchange Server for Outlook 2007 clients” and then click Next.

4. On the Publishing Type page ensure that “Publish a single website or load balancer” is checked and click Next, on the following Server Connection Security page select “Use SSL to connect to the published web server for server farm” and click Next.

5. On the Internal Publishing Details page in the Internal site name dialogue box enter the fully qualified domain name of your Exchange Client Access Server and then click Next.

6. On the Public Names page enter the the fully qualified domain name used for external autodiscover, for example and then click Next.

7. On the Select Web Listener page click “New” and then enter and appropriate name for the listener and click next, on the following page select “Require SSL secured connections with client” and then click Next.

8. On the Web Listener IP address page, click External and then “Select IP Addresses” and continue to select the new global IP address that is to be used for Exchange Web Services and then click Next.

9. On the Listener SSL Certificate page click “Select Certificate” and then choose your third party SSL certificate for Exchange Services, this certificate must include the subject alternative name of, once selected click Next.

10. On the Authentication Settings page click the drop down item and select “No Authentication” and thenclick next and then next again past the Single Sign On page and the click Finish.

11. Back in the main publishing rule wizard, ensure the newly created listener is selected and then click Next. On the Authentication Delegation page click the drop down item and select “No delegation but client may authenticate directly” and then click Next, on the following User Sets page click Next and then Finish to create the publishing rule.

12. Once the rule has been created right click it and select properties and select the paths tab and remove the /OAB/* and /rpc/* entries and click OK. Following this change click Apply on the Firewall Policy page and wait for the TMG configuration store to update accordingly.

13. The Exchange Web Services rule is now created, and should look like the following as detailed below, please click to enlarge.

14. If the publishing of the rule has applied correctly, when connecting with your Lync 2013 client externally you should now longer be continually prompted for Outlook credentials and additionally under the configuration information section of the client, which can be accessed by holding down the control (Ctrl) key and then left clicking the Lync 2013 task tray icon and selecting “Configuration Information”, the EWS status should now say “EWS Status OK”.

That’s it, hopefully your EWS external access now works as intended.                             


  1. Following your instructions did not solve my problem. I still have the same problem for credentials pop-up on Lync2013 users connecting outside (thru Edge). If you create a new firewall rule with paths (/Autodiscover/* /EWS/*) and and put it on the top of firewall rules my client still goes to other firewall policy rules for OWA. Should EWS and AUTODISCOVER path on OWA rules be deleted?

  2. Hi, do you mind telling me how you set up the dns records once you created a separate IP and listener?

  3. Hi Bostjan, the new rule you created for AutoDiscover and EWS, did you enter their external facing name in the “Public Names” tab in TMG. For example the new rule you created should have public name of, this name should then be removed from your original firewall rule. Thanks.

  4. Hi Doug, the external DNS A record of should be pointed to the new IP address that has been assigned to the new listener, this should be all that is required. Thanks.

  5. Thanks. This was very helpful, but I have not been completely successful.The problem I am seeing is that the autodiscover is working correctly, but the ews external url is “\ews” (and I think this is typical) so it seems that tmg is still using my other publishing rule and listener to respond to the ews path and request. How did you solve that? Thanks!

  6. Thanks! I got this partly working, but the issue I have is that the ews folder is under the default site of “”…so That means that even though autodiscover is now using the correct listener and publishing rule, the ews is using the old rule and thus FBA. How did you get around that? thanks again.

  7. Hi there.
    Ok, we have three rules for OWA, and two rules for LYNC:
    Rules for OWA has been done as MS recommends them.
    After issuing problem with Lync 2013 credentials pop-up we have deleted EWS and AUTODISCOVER path on OWA rule, and add thoose PATH’s to new rule.
    Can you please update your instructions with more printscreens of TMG rule.
    Our EWS is OWAADDRESS/EWS on Exchange and not AUTODISCOVER/EWS, I am a little bit confused about this.
    Now the current situation is that credentials window does not appear anymore, but after removing EWS from OWA rule, client’s with outlook have problem because they can’t use free/busy status anymore.
    Lync2013 client outside LAN does not recieve credential warning anymore, but EWS is still shown as not deployed.

  8. Hi Doug, have you manually removed the /ews/* path from the original Exchange publishing rule? You should also have an external DNS record for, which should point to the new IP address of the new listener. This name should be added as a public name under your new web listener. Thanks.

  9. Thanks, yes, I have same issue as Bostjan. when I removed ews from original rule, outlook anywhere clients could not get to mailtips. I had to re-add ews to that rule. the issue is that ews is under the domain, not, so the new rule with dedicated listener does not help with the ews portion. I now have 3 rules. One for autodiscover with a new listener and ip for “”, one for ews with the old listener, but changed to add “all users” and “no delegation but client can authenticate directly” for “” and a 3rd that is the original owa publishing rule and listener with the FBA for “ The ews listener appears to work because by setting the users to “all users” it forces the listener to have “no authentication” per the warning that pops up when you click apply.

    Everything is now working with the exception of an error 32054 on the Lync FE for LS Storage Servic “Storage Service had an EWS Autodiscovery failure” that occurs whenever a Lync mobile client connects.

  10. Maybe I will use the same thing that Doug did, but before that I would like to check something about creating the new rule:

    ? Forward original host header should be enabled ?
    ? request appear to come from original client or Request appear to come from the forefront tmg ?
    ? link translation should be enabled/disabled ?

Leave a Reply

Your email address will not be published. Required fields are marked *