Doug Deitterick's Blog

Information about Skype for Business, Lync, OCS, and Exchange UM.

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

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

  • Comments 32
  • Likes

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.

  • Good work!

  • 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

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

  • @Sven

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

  • Hi,

    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?

  • 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 ?

  • @khaled

    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.


    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.

  • 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

  • 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.

  • 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

  • Cormang, 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.

  • Great article!

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

  • @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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment