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 TMG. 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.
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: