Here’s another post in my “revisited” series. This time I am revisiting my previous post about how to use the Forefront UAG as a Reverse Proxy for Lync. At the time I wrote that post (Dec 2012) the Lync server UCWA and Lync 2013 mobile client had not yet been released, and the Modern UI/MX Lync App was not that much applied either. My later experience with these applications have been incompatible with the use of UAG like I described it, and when a colleague contacted me the other day on how to go about using the UAG I decided to do a little follow-up on this.
I have come across an excellent article on the matter by Marc Terblanche/Kloud blog. I had discovered some of the details in his blog myself when trying to make the Lync 2013 mobile client work, but only managed to get it working partially. For instance, I would get continuous error messages on lost server connectivity, although communications were still going through. It would almost always output IM’s double-up, and when signing out it would fail stating that “others might still see you as available”. The Modern UI/MX App was not able to sign in either. So even after trying to upgrade to UAG SP3 (which wasn’t around when I first deployed UAG) I could still not make it work, and I even tried it at two different customers.
So, trying to help out my customers getting a working solution for Lync with all features, and trying to avoid having to reinvest in a new reverse proxy solution – this is what I ended up with:
-
Set up UAG as described in my previous blog post. Basic install is still applicable, but remember those Service Packs!
- Use the unsupported but fully functional underlying TMG to publish Lync Web services through the UAG server
- Use the UAG part for publishing Office Web Apps server.
By this approach I got all of the functionality that I struggled with while using the UAG working flawlessly. Even regular Lync Web services (such as the Lyncdiscover part used for authentication of Lync 2013 desktop app login) became much more responsive immediately.
The two last points do deserve some more detail.
To go about using the TMG part of UAG you will first have to release the UAG’s hold of all the IP listeners on the server. Kevin Peters has a nice post on this, but to summarize:
- Open a command prompt with elevated admin rights
- run the command
netsh http add iplisten ipaddress=127.0.0.1
(this will “release” the hold of port 443 for “any IP”) - run the command
netsh http add iplisten ipaddress=10.20.30.40
(replace 10.20.30.40 with an IP designated for use on the UAG server itself, such as Exchange, Sharepoint or Office Web Apps publishing services) - repeat the previous until you have added back all of the addresses that will still be hosted on the UAG through HTTP(S) trunks
By now you should still have at least one IP address available, not being tied back to the use through UAG. This IP you will apply for your Lync Web Services listener, which we will now use TMG console on the UAG server to implement.
I will not go into detail on how to set up the TMG rules to publish Lync Web services, including meet, dialin and Lyncdiscover. Follow the Technet article and you should be okay. When you are finished setting up the rules, I like to return to the UAG console and do a “save and activate” to kind of capture the configuration of what you now have entered into TMG in the data store.
When it comes to publishing the Office Web Apps server the TMG part of UAG server cannot be used for this. There are some HTTP settings required for this that do not come as part of the “ripped” version of TMG residing underneath UAG. Instead, just follow the Technet article on how to use UAG for this, and you will be fine. The previously mentioned Kloud blog post suggested publishing Office Web Apps the same way that Sharepoint is being published, With some tweaks on the portal settings. I was not successful on this either, and Microsoft even has a supported way of doing it by publishing as a Web Application – so go with that and prosper!
Now, I have to stress that this is by no chance a supported deployment strategy by Microsoft. But for customers that have made the investment in UAG, maybe even replacing previous TMG solution after the End-of-Life announcement was made a year ago, it may be a feasible solution. After all, Microsoft quite clearly state that they do not support publishing Lync web services through the UAG console either.
September Blog artikler fra Atea konsulenter – LyncAtea.no
Nice article! 🙂
Please not that if you use the same UAG Server as a DirectAccess host, using this approach to decouple the binding between IP-adress and UAG/TMG, the DirectAccess Monitor in the UAG Web Monitor stops working.
And by this I mean that the different DA roles pops up as unhealty in the UAG Web Monitor.Also no DA sessions will be shown.