Following SP1 Update 1, UAG now supports publishing of Lync. This, however, has some important considerations that need to be followed, with regards to the trunk configuration and the certificates.
Even though the Lync application can be added to ANY trunk, a common scenario is the need to invite guests to a meeting. Naturally, few organizations can provision a login to each guest, so in such a case, it may be beneficial to create an unauthenticated trunk for the Lync application. Since you typically would have other apps (like SharePoint or Exchange) only for corporate users, you would want these on a regular, authenticated trunk, and publish the Lync application on a separate trunk, which has been set to be unauthenticated:
If you indeed proceed with an unauthenticated trunk, keep in mind that you need to set two registry keys to enable a pass through authentication:
Set both keys to 1, and then activate your configuration, and perform an IISRESET.
Another consideration is the certificate. Most organizations prefer to use Wildcard certificates, as they a more economic solution when there’s a need for multiple public hostnames. However, Lync publishing has some limitations regarding wildcard certificates. To publish lync to the internet, the organization would require a SAN certificate (a single certificate which has multiple hostnames embedded into it). The SAN certificate would have to accommodate for the following 4 URLs:
1. The UAG’s trunk URL
2. The Lync’s primary publishing URL
3. The Lync’s meet URL
4. The Lync’s dialin URL
In addition, you may want to include additional names, if the UAG will be used for additional applications like SharePoint. However, when purchasing the certificate, it’s important to make sure the primary URL in the certificate, which appears in the certificate’s subject field, is the Lync’s URL (2 above) and not the other names. For example, here’s a certificate that has been configured correctly:
Above, “blrext.future.in” is the primary public URL for Lync (left) and “uagtest.future.in”, “meet.future.in” and “dialin.future.in” are the UAG public hostname and the secondary URLs for Lync (right). Here they are in the UAG configuration:
Naturally, if you use two trunks on the UAG, you can have a regular wildcard certificate for it, and the specially-created SAN cert for the Lync trunk.
For more information, the following link discusses the certificate fields for Lync publishing: http://technet.microsoft.com/en-us/library/gg429704.aspx
Props to Yan Mintz and Robby C. for their help with this guide!
Where does the public host name "clrext" come into play here? In your last screenshot you have 3 unique names highlighted, uagtest, blrext, and clrext, but I don't see clr mentioned at all in the article or in your SAN list.
Answer to RenhsrakJ: This was a type in the image, and I've replaced it with the correct one. Thank you for bringing this to my attention!
I am new to TMG and UAG, so excuse me if I'm not even close on this, but you're including the public host name in the SAN certificate due to you wanting to go through the portal address instead of the primary publishing URL. Can you not use the primary publishing FQDN of Lync (ie...lyncweb.domain.com) as the public host name and wouldn't need to have yet another name in the certificate?
UAG needs it's own, separate public hostname, that's different than the names used by the application. This allows UAG to identify requests that pertain to UAG's administrative website (InternalSite). You can access Lync by using it's public hostname, but the UAG needs the hostname as well.
I have this resolved thanks to your reply with the exception of when I go to the site now from the Internet, I am having to append the url with the the /dialin to get to the page even though the application url clearly has that in there. Any ideas?
I'm afraid UAG does not have the ability to do this when connecting to the URL directly.
Is the requirements for a non-wildcard cert for Lync specific to UAG? Because we are publishing Lync via TMG with a wildcard certificate just fine. That would be disappointing.
Matt B, I am running this configuration with a wildcard cert and it works fine for Lync 2010 and Lync mobile clients (I do have a SAN cert for the Lync edge server though). I have not tested other devices (such as Lync phones). Hope this helps.
Hi. Can the same wildcard cert be applied to multiple trunks? I would assume as different needs will require different authentication methods and each trunk can only have a single type of authentication that it would be necessary to apply the wildcard cert across many trunks. So, will a single wildcard cert be enough to accomplish any type of publishing needs on the UAG?
I am thinking of Lync in particular. It would be easier to be able to use a single wildcard cert on the UAG so I don't have to worry about what needs to be included in the SAN for different trunks publishing OWA, Outlook Anywhere, Sharepoint, Intranets, etc.
I would then only need a particular SAN cert on the Lync Edge since that will have externally facing IPs to accomplish other Lync client needs.
Does that make sense?
One last question regarding certs. I currently use ISA 2006 to publish my Exchange services (OWA, ActiveSync, Etc.). Both my ISA2006 and Exchange Server have certs installed so they can communicate. Am I correct that when using UAG to publish Exchange services like OWA, Outlook Anywhere, ActiveSync, etc. that I no longer need certs on the Exchange box since once a client reaches the UAG box traffic from the UAG to Exchange can be over standard http?
To Bill and others, the blog comments are not the appropriate platform for asking technical questions, esp. outside the scope of the article. Please post your questions on the UAG support forum at social.technet.microsoft.com/.../forefrontedgeiag or contact me directly via the Email Blog Author link on the top right of the page.
You recommend publishing Lync into a separate trunk. How do you address the issue of the Lync trunk going on the same IP and port as the other trunks (exchange)?
This issue we had is that is that the Lync iPhone client will not be able to access EWS via UAG to retrieve calendar info. Even with passthrough enabled, it will not work and is unsupported.We had to use a third-party reverse proxy solution for EWS to function correctly.