Month: December 2013


Publishing Lync via Web App Proxy with multiple SIP domains


With the recent release of Server 2012 R2, and with it ADFS 3.0 and the Web Application Proxy (WAP) role, word on the street was we now had a replacement product from Microsoft to publish Lync, rather than using the now retired TMG or ISA products.

It’s an exciting time.

So naturally, the minute we upgraded our ADFS farm to 3.0 (as its a hard requirement for deploying WAP), I was straight into test publishing our Lync 2013 platform behind WAP.

Doug Deitterick over on the Microsoft UC Blog has done a great job of documenting how to setup and publish Lync via WAP, and Marc Terblanche has a great post that goes into a bit more detail around scripting the rules, along with some excellent information about the SNI challenge and how to assign a default cert for clients that don’t support SNI (very important to understand this one).

But in both cases, they’re publishing a straight-forward Lync lab, with a single SIP domain.  What happens in a real world scenario where you have multiple SIP domains associated with your Lync platform, and you need to publish them all – specifically, if you support mobility?

Unfortunately, the answer is slightly disappointing. You can’t do this via WAP. Yet.

When you have multiple SIP domains, there is a gotcha when it comes to publishing the Lync Discover URL that mobile clients rely on to auto-discover their sign-in server details. In a single SIP domain environment, you’d just have a URL and publishing rule for lyncdiscover.sipdomain.com:443 that points to lyncweb.sipdomain.com:4443. In a multiple SIP domain environment however, you can’t as the mobile clients for users on SIP domain #2 will fail to correctly redirect to the primary SIP domain. The reason for this is outlined below:

Mobile device clients do not support multiple Secure Sockets Layer (SSL) certificates from different domains. Therefore, CNAME redirection to different domains is not supported over HTTPS. For example, a DNS CNAME record for lyncdiscover.sipdomain2.com that redirects to an address of lyncdiscover.sipdomain1.com is not supported over HTTPS. In such a topology, a mobile device client needs to use HTTP for the first request, so that the CNAME redirection is resolved over HTTP. Subsequent requests then use HTTPS. To support this scenario, you need to configure your reverse proxy with a web publishing rule for port 80 (HTTP). For details, see “To create a web publishing rule for port 80” in Configuring the Reverse Proxy for Mobility.

 (quoted from ‘Technical Requirements for Mobility’ at http://technet.microsoft.com/en-us/library/hh690030.aspx)

Under TMG, this isn’t a problem, as you can simply create an additional publishing rule for each additional SIP domain on HTTP, which redirects clients to the Lync webservices on 8080. This allows the initial request to come in on HTTP, perform the redirection to the webservices endpoint, then perform subsequent requests directly, via HTTPS.

Why doesn’t this work with WAP? Because as at RTM, the WAP feature only allows you to publish HTTPS URLs. If you attempt to publish anything via HTTP, WAP will return and error and come to a hard stop.

From what I’ve heard, this is something Microsoft are working hard to bring to the product as they recognise it is a barrier to entry for Lync publishing, though whether that will be via an update or a future version I’m unsure at this time.

In the meantime, it looks like your TMG platform might need to stick around a fraction longer if you have multiple SIP domains in your environment. Fingers crossed you wont have to wait too long though.

JB

JB / The Daywalker

Ginger IT dude hanging out down in New Zealand, playing with technology since ages ago.

Currently Service Delivery Manager at Silicon Systems, formerly Skype for Business MVP, and generally into all things Microsoft (and a few things that aren’t).

When I’m not nerding out on technology, you can find me running ultramarathons, brewing beer, or in my woodshop building something.


On The Socials

Visit Us On LinkedinVisit Us On TwitterVisit Us On Facebook