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 'https://test-ls15-se.test.deitterick.com:4443/' -ExternalCertificateThumbprint 'F689AA0EF22532B560C9DA09B9C15CD8190E26EA' -ExternalUrl 'https://test-ls15-se.test.deitterick.com/' -Name 'TEST-LS15-SE.test.deitterick.com 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 "TEST-LS15-SE.test.deitterick.com 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=0.0.0.0:443 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 (0.0.0.0), 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.
Monitoring
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
Anonymous
January 01, 2003
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 930Anonymous
January 01, 2003
@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.Anonymous
January 01, 2003
Interesting option, I haven't been considering much outside of ARR or HLB reverse proxies recently. Thanks for posting this.Anonymous
January 01, 2003
Hi,
Is this only available in R2? Not in 2012 Standard?
Cheers
CoolPraAnonymous
January 01, 2003
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.Anonymous
January 01, 2003
thanksAnonymous
January 01, 2003
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 -DisableTranslateUrlInResponseHeadersAnonymous
January 01, 2003
@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.Anonymous
October 29, 2013
Good work!Anonymous
October 31, 2013
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 www.LyncShield.comAnonymous
November 05, 2013
Thank you for this post - is this supported for publishing Lync 2010 as well?Anonymous
November 06, 2013
@Sven It should work, but I haven't tested it with Lync Server 2010, so I can't say for certain.Anonymous
November 11, 2013
The comment has been removedAnonymous
November 17, 2013
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 ?Anonymous
November 18, 2013
@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.Anonymous
December 09, 2013
The comment has been removedAnonymous
December 13, 2013
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? ThanksAnonymous
December 15, 2013
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.Anonymous
December 18, 2013
Pingback from End of an Era: Proxy and Exchange | Just A UC GuyAnonymous
January 20, 2014
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.Anonymous
January 25, 2014
Nous attendions avec impatience les nouvelles Roadmap des solutions qui composent la gamme ForefrontAnonymous
May 08, 2014
Pingback from How to publish Lync and SharePoint on Linux? - MobilityShieldAnonymous
June 10, 2014
Pingback from Publish Lync 2013 web services using Windows 2012R2 | VatlandAnonymous
June 11, 2014
Great article!Anonymous
June 11, 2014
Pingback from Publish Lync 2013 web services using Windows 2012R2 | VatlandAnonymous
July 17, 2014
The comment has been removedAnonymous
July 21, 2014
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?Anonymous
July 29, 2014
It's good to have another option. I wonder if this is "supported" Lync publishing method by Microsoft.. but thanks for the post!Anonymous
January 16, 2015
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?Anonymous
January 21, 2015
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.Anonymous
March 13, 2015
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?
thanksAnonymous
March 27, 2015
Wow...
Super Post ... Keep up the Good work.
Is there a way to install WAP without ADFS ?Anonymous
June 03, 2016
I wish to implement the same with Lync 2010 on premise. currently it is with ISA 2006/ any input?Anonymous
August 25, 2016
Thanks for this useful post! I have one quibble:Based on this article from TechNet (https://technet.microsoft.com/library/dn383995.aspx), 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.- Anonymous
August 26, 2016
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.
- Anonymous
Anonymous
June 03, 2017
hi dodeitte ,thanks for this useful article.can you please say some things about how to configure our NIC for this scenario?thanks