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 used.
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 are 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. UAG’s trunk URL
2. Lync’s primary publishing URL
3. Lync’s meet URL
4. Lync’s dialin URL
In addition, you may want to include additional names, if the UAG trunk 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 any of the other URLs. 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), respectively. Here they are in the UAG configuration:
Naturally, if you use two trunks on the UAG, you can have a regular wildcard certificate for the trnuk that does not publish Lync, and the specially-created SAN certificate 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
Blog post written by Erez Ben Ari
Props to Yan Mintz and Robby C. for their help with this guide!
I cannot see the entire Registry key. Is it a Problem of the screen resolution of my Netbook?
regards Marc Grote
Is a support of Lyncdiscover is on the roadmap for publishing through UAG ?
Im not happy with this article. It provides a general idea how to set it up.
But the certificate requirements are not explained and not necessary to be provided with the SN for the trunk.
It will for sure generate a warning during setup, but UAG do not make use of any of those SNs for Lync.
It also would be a huge joke, since if we had multiple domain names, we need per domain name one trunk, this means also we would need to order multiple certificates. this is beyond an cost efficient solution!.
This also includes a unique IP address for each trunk
I will soon write a entire blog how UAG can be used, maybe I will publish it in our TechNet blog too.
We are right now testing it in a customer scenario where we have around 7 domain names (SIP domains)
I will also address this issue at the Product Group for Lync