How to Publish Lync Server 2013 Web Services with Windows Server 2012 R2 Web Application Proxy

Update 5/12/15 – Added information about disabling translation of URL values in request headers.
Update 11/12/14 – Added information about white paper published for Web Application Proxy for use with Lync Server 2013.

Update 8/30/14 – Added information about Lync 2013 mobility and multiple SIP domains.

With the discontinuation of TMG and with UAG not supporting all of the functionality of Lync, the choices for the Reverse Proxy role have been slimmed down a bit.  Utilizing an existing TMG environment, choosing to setup IIS ARR, or go with a third party product are the options available. Each has its pros and cons. With the release of Windows Server 2012 R2, another option for the Reverse Proxy role for Lync Server 2013 Web Services is possible. Included in Windows Server 2012 R2 is the Web Application Proxy role.  The Web Application Proxy Overview TechNet article provides high level information on the role and it's uses.  You can use the Web Application Proxy role to publish many different types of applications.  This blog post only focuses on publishing Lync Server 2013 Web Services.  One prerequisite for the Web Application Proxy that we won't discuss in this blog post is that you will need AD FS running on Windows Server 2012 R2 already installed and working in your environment.  For environments that aren't using AD FS currently, this may make using the Web Application Proxy role as the Reverse Proxy for Lync Server 2013 Web Services less appealing that another Reverse Proxy solution, but for environments that do leverage AD FS, the ability to combine services might make sense.

A white paper has been published that describes the requirements, planning and configuration of Web Application Proxy for use with Lync Server 2013.  You can download it here.


Installing the Windows Server 2012 R2 Web Application Proxy Role

In Server Manager, open the Add Roles and Features Wizard.  On the Select server roles screen, select Remote Access and click Next:

On the Select features screen, no additional features are needed, click Next

On the Remote Access screen, click Next

On the Select role services screen, select Web Application Proxy and click Next:

When the Add features that are required for Web Application Proxy? box pops up, select Add Features and then click Next:

On the Confirm installation selections screen, click Install:

When the installation is complete, click Open the Web Application Proxy Wizard:

On the Welcome screen, click Next

On the Federation Server screen, enter the appropriate information and then click Next:

Note: The rules we're going to publish for Lync Server 2013 aren't going to use AD FS, but the configuration for the Web Application Proxy requires that AD FS be setup and configured during installation of the role.

On the AD FS Proxy Certificate, select the certificate to be used by the AD FS proxy and then click Next:

Note: The certificate needs to be the AD FS certificate with the private key.

On the Confirmation screen, click Configure:

On the Results screen, make sure that the Web Application Proxy was configured successfully and then click Close:


Publishing Web Applications

Now that the Web Application Proxy has been installed and configured, you need to publish rules for the URLs that you want to pass through the proxy.

Open the Remote Access Management Console

In the Tasks section click Publish:

On the Welcome screen, click Next

On the Preauthentication screen, select Pass-through and click Next:

On the Publishing Settings screen, fill out the fields with the appropriate information and then click Next:

Note: For the Backend server URL field, remember to append ":4443" to the external web services URL and simple URLs.

On the Confirmation screen, click Publish:

Note: You can also use PowerShell to create the published web applications:

Add-WebApplicationProxyApplication -BackendServerUrl '' -ExternalCertificateThumbprint 'F689AA0EF22532B560C9DA09B9C15CD8190E26EA' -ExternalUrl '' -Name ' External Web Services' -ExternalPreAuthentication PassThrough

On the Results screen, ensure that the web application was published successfully and then click Close:

Repeat the steps in this section for the remaining Lync URLs that you want to publish:

For some rules you may want the ExternalUrl and the BackendServerUrl to be different.  If this is the case you will need to disable translation of URL values in request headers for that rule.  This setting can be disabled by running the following cmdlets using PowerShell:

$Rule = (Get-WebApplicationProxyApplication " External Web Services").ID

Set-WebApplicationProxyApplication –ID $Rule –DisableTranslateUrlInRequestHeaders:$True

Since some of the Lync 2013 mobile clients don't yet support Server Name Indication (SNI), you'll need to apply a default SSL certificate for the Web Application Proxy to use.  In the How to: Configure a Port with an SSL Certificate MSDN article, you can use a command similar to:

netsh http add sslcert ipport= certhash=f689aa0ef22532b560c9da09b9c15cd8190e26ea appid={f955c070-e044-456c-ac00-e9e4275b3f04}

In order to get the correct certhash and appid values, you can run the following command:

netsh http show sslcert

The results will be similar to below:

Find one of the web applications that you published and copy the Certificate Hash and Application ID fields to use in the netsh command above.  This will ensure that clients that don't support SNI are returned a certificate.  If you choose to bind to all IPs (, you'll need to make sure that all names for all the published web applications are listed on the certificate.  Once all of the web applications are published, you can test them to make sure everything is working correctly.


Lync 2013 Mobility and Multiple SIP Domains

I get asked occasionally whether or not Windows Server 2012 R2 Web Application Proxy will work when you're using the Lync 2013 mobile clients and have multiple SIP domains in your environment.  When I originally wrote this blog post I only had one SIP domain configured in my lab, so I never tested this.  I decided to add another SIP domain and test it out to see whether or not it would work.  The short answer from my quick testing in my lab is that, yes, you can use Windows Server 2012 R2 Web Application Proxy for mobility with multiple SIP domains.  Just keep in mind that you may need to fill out some additional fields in the Lync 2013 mobile client.  In my lab, when trying to sign in with a user provisioned with a SIP URI from the second SIP domain:

Unfortunately, the sign in failed with "We can't sign you in. Please check your account info and try again.":

All I needed to do to resolve this error was to fill out the User Name field under Advanced Options:

This isn't an issue with the way Windows Server 2012 R2 Web Application Proxy works.  It is because my sign-in address doesn't match my UPN in AD.  This causes an issue when trying to authenticate with the WebTicket service.  With the User Name field filled out correctly, this time the sign in completed successfully:

This was a quick test with the Windows Phone version of the Lync 2013 mobile client.  As I get time to test the other version of the Lync 2013 mobile client, I will post any interesting findings.  Make sure that if you are going to be using Windows Server 2012 R2 Web Application Proxy and you have multiple SIP domains you thoroughly test the different Lync 2013 mobile clients for all of the mobile OS versions you will be supporting.



You can use the Operations Status section of the Remote Access Management Console to monitor the Web Application Proxy:

From there you can open the Event Viewer and look at the Admin event log or view the Performance Monitor counters:


While the Web Application Proxy role in Windows Server 2012 R2 may not be as feature rich as a traditional Reverse Proxy, if you're using AD FS today and want an easy way to publish Lync Server 2013 Web Services, it's worth a look.

Comments (35)

  1. Anonymous says:

    I fixed the issue with warnings about “The HTTP response…expected interval: 300 seconds” On the WAP server run Set-WebApplicationProxyApplication “your app name” -InactiveTransactionsTimeoutSec 930

  2. NeighborGeek says:

    @Aaron @Anonymous – I was seeing the same events. Looking in the details of the events, I see that the URL listed actually contains "timeout=900". If that means 900 seconds, then the command suggested by Anonymous would make perfect sense, setting the
    timeout for the response to just longer than the request’s timeout. On the other hand, it seems highly unlikely to me that the timeout referenced in the URL is supposed to be 900 seconds… more likely 900ms. I can’t imagine a case where a web request would
    wait up to 15 minutes for a timeout.

  3. Interesting option, I haven’t been considering much outside of ARR or HLB reverse proxies recently. Thanks for posting this.

  4. CoolPra says:


    Is this only available in R2? Not in 2012 Standard?


  5. NeighborGeek says:

    On the other hand, I did go ahead and run the command, and extending the timeout does seem to have cleared up the errors. I can’t help but wonder though if setting it to 350 or 400 seconds might have been enough.

  6. Ed (DareDevil57) says:


  7. Increasing the timeout value to 900 sorted the issue out for me. The other warning i see is Connection to the backend server failed. Error: (0x80072ef1). This seems to be a bug as my internal/external names for OWA are the same. Fix, run this command:
    Get-WebApplicationProxyApplication [app name] | SetWebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders -DisableTranslateUrlInResponseHeaders

  8. dodeitte says:

    @Chris Buchholz

    There isn’t a requirement for the WAP servers to be domain joined or not domain joined in order to publish Lync Server 2013 web services.

  9. Gulab says:

    Good work!

  10. Yoavc says:

    Thanks for the information.

    As you have correctly mentioned this option is mainly suitable for those using AD-FS . I believe that implementing ADFS just for publishing Lync will not be the best choice for most organizations.

    Organizations looking for a simple reverse proxy deployment you can consider Bastion (runs both on Win & Linux).

    This reveres proxy also comes with a lyer of dedicated Lync security features such as blocking Dos and Brute Force  attacks, adding Two factor authentication and avoiding AD credentials usage on device.

    See more on

  11. Sven says:

    Thank you for this post – is this supported for publishing Lync 2010 as well?

  12. dodeitte says:


    It should work, but I haven't tested it with Lync Server 2010, so I can't say for certain.

  13. says:


    I presume the setup is an?

    –  Windows 2012 Server on the LAN domain joined running ADFS

    – Windows 2013 Server n DMZ in workgroup running ADFS proxy

    Would you have to cards on the ADFS proxy server for external and internal traffic?

  14. Khaled says:

    why do i need to implement ADFS proxy when you used pass thruogh authintication ?

    as per MS when you use pass thruogh authintication so the clients are going to authinticate directly on the published server am i right ?

  15. dodeitte says:


    Because the setup for the Web Application Proxy role requires it.  You are correct that the rules that are created for Lync use pass-through.  This is why it might not make sense to use if you're not currently leveraging ADFS for other applications.

  16. dodeitte says:

    Correct.  The ADFS server would be a domain joined machine and the ADFS proxy would be in the DMZ.  You can use multiple NICs for the ADFS proxy if you'd like, but it's not required.

  17. aaron says:

    I have successfully publish Lync using WAP, but I continually get a warning on the WAP server as follows: "The HTTP response from the backend server was not received within the expected interval. Expected interval: 300 seconds."  This is for the LyncWeb published app. Is there a means to adjust timeout values on the WAP server to resolve this warning? Are other seeing this behavior? Thanks

  18. Cormang says:

    Has anyone been able to successfully publish SharePoint 2010 using Server 2012 R2 ADFS and WAP? I’ve tried adding Non-Claims Aware Trust but after authenticating with ADFS I’m presented with an HTTP 500 error. If I publish SharePoint using Claims Aware Trust, I authenticate with ADFS but then I’m presented for my Windows credentials again (because SharePoint uses Windows authentication) but I’m actually able to see the SharePoint site – no HTTP 500 error.

  19. Anonymous says:

    Pingback from End of an Era: Proxy and Exchange | Just A UC Guy

  20. mike says:

    Your sharepoint site must be configured for Kerberos and you must have an SPN for the account that runs the app pool of the sharepoint site. Hope this helps.

  21. Anonymous says:

    Nous attendions avec impatience les nouvelles Roadmap des solutions qui composent la gamme Forefront

  22. Anonymous says:

    Pingback from How to publish Lync and SharePoint on Linux? – MobilityShield

  23. Anonymous says:

    Pingback from Publish Lync 2013 web services using Windows 2012R2 | Vatland

  24. David Cano says:

    Great article!

  25. Anonymous says:

    Pingback from Publish Lync 2013 web services using Windows 2012R2 | Vatland

  26. Jason says:

    Regarding the certificate used, we’re trying to publish OWA, ActiveSync, and Lync via WAP and get away from the TMG that is currently deployed. The WAP document has explicit instructions for OWA and Exchange:

    In that document, you’ll see clear directions on the names needed for the certificate. I know that it is possible to use a SAN cert with and, for example. Can we leverage that same SAN cert and include all of the Lync URLs in that
    same cert? My guess is that you can, but I’m looking for clarification.

  27. Chris says:

    Thanks for the article, Doug. I’ve implemented ADFS and WAP and published the URLs for Lync. However, when I browse to the URLs externally, I’m presented with a certificate warning as it appears the SSL tunnel isn’t being terminated and re-established
    on the WAP server and instead is just tunnelling all the way through. Upshot is, my client doesn’t trust the certificate on the internal server. Any idea what’s going on here?

  28. Andrew Shin says:

    It’s good to have another option. I wonder if this is "supported" Lync publishing method by Microsoft.. but thanks for the post!

  29. David Parrish says:

    So, the more I read about Rvs Proxy and Federation the more confused I’m getting. My company was purchased by another. We want to federate and communicate with Lync 2013. We both already have in house deployments.
    So do I use a 3rd party to federate "connect" our lync users for IM, presence, other features or can one of the companies simply setup MS ADFS services?

  30. Joakim Silverdrake says:

    David, ADFS doesn’t have anything to do with Lync federation.
    In order to federate between two different Lync environments you will not need anything special. You only need to make sure that federation is enabled in both Lync environments.

    If you want to merge the two environments into one then there’s a bit more work involved.

  31. Chris Buchholz says:

    Is there a away to keep the WAP servers domain joined and still publish Lync? We are running into a problem now where the WAP servers are in a workgroup, but to correctly publish SharePoint 2013 the WAP servers need to be domain joined! we are not in the
    position of having several WAPs , some domain joined and some not, in order to publish, and since they all look at the same ADFS, worry this is going to cause some odd behavior.

    What solutions have you seen for this?


  32. Kanta Prasad says:


    Super Post … Keep up the Good work.

    Is there a way to install WAP without ADFS ?

  33. Rizz says:

    I wish to implement the same with Lync 2010 on premise. currently it is with ISA 2006/ any input?

  34. Peter Brooks says:

    Thanks for this useful post! I have one quibble:

    Based on this article from TechNet (, I think you have the translation Enable / Disable information backward.

    You wrote: “For some rules you may want the ExternalUrl and the BackendServerUrl to be different. If this is the case you will need to disable translation of URL values in request headers for that rule.”

    But that article indicates the opposite. If the two URLs are different, translation must be ENABLED (the ‘DisableTranslateUrlInRequestHeaders’ parameter must be set to $FALSE) in order to cause the WAP to translate between the two disparate URLs.

    1. dodeitte says:

      Both articles are correct. That TechNet article is saying that if you want WAP to translate between the two URLs to set the parameter to $false. In my post, I’m saying that I don’t want WAP to translate between the URLs, as I’m defining the internal URL for the BackendServerUrl parameter. That is because you don’t want WAP to rewrite the host header information. If you do, then the IIS rewrite rules on the Front End Servers will interpret this traffic as internal, as it matches the rules for the internal IIS website. So the goal is to have the traffic show up at the Front End Servers with the external URL, without having to mess with hosts files on WAP pointing an external URL to an internal IP address.