UAG as a Lync Reverse Proxy

​In a recent Lync project I needed to advice my customer on what reverse proxy to apply. On 12th of September Microsoft announced the end-of-life for my previous favourite, the Forefront TM​G. This was a well documented, proven and stable platform for both Lync as well as other web  applications/services needing to be published safely in the outer perimeter.

Being familiar with quite a few alternatives to offer (e.g. Citrix Netscaler, F5 BigIP etc) my immediate thoughts went to the successor of TMG, that is the Forefront Unified Access Gateway (UAG). This is also quite a capable platform for publishing Exchange, Sharepoint and Lync, although lacking some of the functions of TMG (like firewall capabilities). Still, it looked like a good choice for the customer in question, as they were talking about potential upcoming Sharepoint as well as wanting to publish Exchange in a more secure manner as well.

Continuing this post, I will first be sharing some insight on UAG install, independent of Lync. Being a trusted advisor often leads to getting the job assignment as well. In this case it was a prerequisite of mine that the customer had a reverse proxy in place prior to the Lync project. As thing were getting started, it turned out they wanted me to fix it altogether. How nice! 🙂 Another thing worth mentioning about the case was the fact that the customer was demanding support for IPv6 on the whole project. As for Lync, this is now possible through Lync Server 2013. I happened to know that UAG also supports Direct Access, which is an IPv6-only feature, so with this in mind the project went on.

​​​Part one – briefly on UAG server install

Getting to the UAG install: The customer prepared a server running Windows Server 2008R2, the only supported OS to my knowledge, domain joined and also separated between two firewalls with traffic on the out-/inside filtered like my previous post for TMG describes here. Remoting into the server, everything looked ok, so I went straight on with my job installing UAG and prerequisites. This would fail monumentally time and time again. Somewhere inbetween TMG and UAG phase of the install, I noticed that internet connectivity would disappear (the yellow warning sign on the network icon in the system tray would appear). Upon finishing the install, the server would complain about not being able to connect to the domain, and as such the Configuration Storage (holding the rules and policies running the UAG/TMG) would not be able to initiate.

This would send me off on a wild goose-chase, suspecting everything from the “not supported” VMware platform the server was running on, an existing anti-virus software running on the server, down to the fact that the install media would be corrupt. The answer turned out to be – none of the above. Here is a quick recap of my experience:

1. Verify the network connectivity

As it turns out, the UAG does not support the use of IPv6 ​besides when used for Direct Access (missing the official statement, this is according to my UAG expert colleague). In my case, due to the setup of the network infrastructure the domain connectivity would break beacuse only IPv6 was properly configured for this traffic. As soon as TMG services would start, the IPv6 traffic was being blocked. Because IPv4 traffic was not working properly, domain trust was broken. In the end, referring to my previous post and verifying what traffic to allow to/from the domain and the UAG was the answer.

2. Verify the network interface settings and bindings

Another thing about the network; one thing that bothered me was that both NIC’s on the UAG server would, initially, report internet access. The interfaces were being set up according to best practice:

External NIC: Default gateway, no DNS, no “Client for Windows” or “File/print sharing” capabilites

Internal NIC: No default gateway, using internal DNS servers, using static routes, leave everything else to defaults.

It turned out that Router Discovery/Announcement on the IPv6 internal gateway would provide an external route anyway. The key is to disable the discovery feature on the internal NIC, which can be achieved like this:
netsh interface ipv6 set interface “Internal” routerdiscovery=disabled​

3. Verify the domain connectivity

Use simple commands like nltest /dsgetdc:domain.com and even nslookup on SRV records like _ldap._tcp.domain.com to verify that you can successfully connect to internal domain resources you need, prior to beginning the install.

After a properly functioning network was in place, installing UAG is as easy as next-next-finish. Just make sure to run the initial wizard where you define your internal and external networks right. This is where you get paid for naming your network adapters properly from the beginning!

​Part two – publishing Lync web services

Ok, moving on to the Lync part of this. I had previously published Lync web services for another customer, using UAG. This was accomplished even before UAG SP1 update 1, where Lync was officially supported. By the same customer case I also remember trying to publish Lync Mobile services (lyncdiscover) withouth any luck, and ending up with unbinding web listeners from UAG platform and utilizing the “unsupported” do-it-through-the-TMG-part-of-UAG solution, like Kevin Peters did way back with OCS (blogpost here). Actually, the problems I encountered was in the early beginning of Lync Mobile, where the real problem was Mobile client parsing of the “root” document you are provided with on Lync Server 2010. Even though Microsoft still officially states that Lync Mobility is not supported on UAG, it will actually work.

This will not be a complete run-through on UAG configuration, but I will highlight some of the most important parts:

1. Publish your Lync Web Services (not Lync Mobile)

Like mentioned, as of UAG SP1 update 1 Microsoft would officially support Lync 2010 on the Forefront UAG platform. This was nothing more than a simple wizard providing the simple URL’s “automagically”. Although letting people off easier, this is actually one of the steps to check for validity. The wizard assumes that you go with the more standard way of the simple URL’s, that is using meet.<sipdomain> and dialin.<sipdomain> as well as your webext.<sipdomain> (or whatever name you would chose for your Lync External Web Services). Companies hosting more that one SIP domain would just as easily opt for the lync.contoso.com/<sipdomain>/meet/ alternative, saving some money on SAN certificate requirements.

Just make sure it is the right one!

Also: Make sure that the HTTPS trunk, or portal, where you choose to put your Lync services, is provisioned with a certificate containing all the public host names from previous screenshot as SAN entries. If not, you will be prompted with warnings when you activate the configuration, and the services just won’t work.

2. Publish your Lync Mobile (aka Lyncdiscover) service

Publishing Lyncdiscover is done the same way that the above mentioned wizard actually does it.

First, from the portal site click on “Add” on the Applications part. From here you will be guided through a wizard. Pictures only, no comments needed:

(of course, if you need to publish a service running on an HLB you should choose differently)

3. Alter trunk settings

Finally you will need to, potentially, make some adjustments to the HTTPS trunk settings. Because UAG is supposed to provide a way of publishing a web portal, for which you authenticate, you will be faced with a logon form. Since we want to let Lync users bypass this and access the services directly, there are a few things to do.

Under Advanced Trunk Configuration, on the Sessions tab, make sure that the following are selected:

Furthermore, on the Authentication tab, make sure that you clear the user authentication check box:

Last, but not least – on the portal/trunk site, under Initial Internal Application, make the published Lync Web App application be the chosen home page instead of the Portal:

At the very end: Don’t forget to SAVE and ACTIVATE your configuration.

By now you should be able to access your Lync Web Services, such as meetings and the dialin-site – as well as logging on with Lync Mobile!

This is using my iPhone Lync client, the UAG works for both iOS and Android as well. My previosly mentioned problems did not concern Windows Phone clients, so I guess that has never been an issue.

Finally, it is worth mentioning that this install was made for publishing a Lync Server 2013 version, although it works just as well for the 2010.

One thing I noticed in the Lync Server 2013 version, with Lync Mobile service, is that it no longer uses the URL https://lync.contoso.com/autodiscover/autodiscoverservice.svc/root to provide the token pointing to the “real” resource. I have used this URL many times earlier to determine if Lyncdiscover was available and functional, also as a way to “bypass” the fact that one had not yet a certificate with the lyncdiscover.<sipdomain> in place so that autodiscovery did not work. I have not looked into what the new mechanism is, but if I come across it I will share it with you.​

Advertisement