What’s the deal with “Public host name”?

As you may have noticed, some of the application templates in UAG have a setting for a “public host name”…like this:

This is known as an “application specific hostname”, or A.S.H for short. You can find this option in the Exchange 2007, Exchange 2010, SharePoint, CRM, ADFS V2, FIM, OCS, RMS and Lync application templates, as well as the “Other Web App(Application Specific Hostname) ” template.

Many users don’t understand the significance of this setting, and are therefore unsure what to set it to. Many simply set it to be the same as the portal’s public hostname, and that could lead to serious problems. Using this correctly is important, not only to allow the apps to function properly, but also to allow you to take advantage of the generic template, to publish applications that are sensitive to UAG’s host address translation (HAT) mechanism.

The purpose of using a public host name in this context is to allow UAG to associate an incoming request to one of the applications defined on the trunk. As discussed in the HAT article, the process of finding the application and backend server a request pertains to can be done based on the HAT signature, but for some applications, we need to use the ASH mechanism instead. One situation this is useful is where the application’s code is too complicated for the UAG HAT mechanism to properly process, such as what happens with SharePoint. Another situation is when the application itself cannot handle the HAT process properly.

When publishing certain applications, such as SharePoint or CRM 2011, you don’t really have a choice – you have to use a public hostname. In the case of SharePoint, this public hostname must also be different than the trunks. It’s kind of hard to miss, as the server will warn you loudly:

The reason this is disallowed is that if you did use the same public hostname, then UAG would not know to which application a request pertains when it comes in. This also means that when you do choose a different public hostname, you can’t publish another application that uses it (and UAG will warn you about that too, if you try). However, UAG has a “backup” mechanism, which allows it to recognize a request based on its path. If requests sent for this application would all use a unique path, then it will be good enough, and allow UAG to recognize it even if it’s coming in on the same public hostname. This comes in handy when publishing Exchange, for example. Requests for the OWA application always come as https://<server>/owa, so this application can be published with the same public hostname as the one used by the trunk. Same goes for Outlook Anywhere (where each request is for https://<server>/rpc/rpcproxy.dll) and ActiveSync (where each request is for https://<server>/Microsoft-Server-ActiveSync).

If you are attempting to publish your own application, and considering using the application-specific hostname template, then simply figure out the application’s URL patterns. If they start from the root of the site, then you can still use the Application-specific template, but you will need a separate and unique public hostname. If they are all on a specific path (or collection of paths), then you can use the portal’s hostname, and you have to specify all these paths on the application’s Web Servers page. For example:

If you do need to have a unique public hostname then remember that when choosing your public hostname, it has to have the same domain as your UAG’s trunk. For example, if the trunk uses “uag.contoso.com”, you can use “empdb.contoso.com” and “employees.contoso.com”, but not “empdb.worldgrovebank.com” or “empdb.apps.contoso.com”.

Another thing to keep in mind is that when you use a public hostname that is unique, any request posted to it has to reach UAG, and so this hostname needs to publicly resolve to the same IP used by the UAG trunk. If it resolves to some other server, or nothing at all, you will be able to login to the UAG portal, but the apps itself won’t launch and shoe instead an “internet cannot connect”. To address this, add a public DNS entry for this URL.

Lastly, if the UAG portal is an HTTPS one (as most organizations use), then it has to have a certificate, and that certificate has to accommodate the additional public hostname as well. One way to get that is to purchase a SAN certificate (which has several hostname in a single certificate), and another is to get a WILDCARD certificate. A Wildcard certificate is defined for a certain pattern, such as *.contoso.com, and will be fine. Generally speaking, SAN certificates are more expensive than regular ones, and wildcard ones are even more costly. If you’re publishing just one app on the UAG portal, perhaps a SAN certificate is fine, but the more applications you publish, the more financially viable it is to get a wildcard certificate.

If you’re just experimenting with this, you might not be able to get a public DNS record, and if so, that’s not the end of the world. You can get around this by adding this mapping on the test-client’s HOSTS file. It may not be practical to do this on every user’s computer, but it’s a good way to toy-around until you’re happy with the results.

Beyond the fact that application-specific hostname publishing can make some applications work, which wouldn’t otherwise, it’s important to know that this method also gives you another advantage. With this method, the users can access a specific application directly by typing in its public hostname in a browser, rather than going through the UAG Portal. In such a situation, UAG will receive the request, and notice the user hasn’t authenticated yet. It will redirect the user to the login page, and after that, back to the applications URL, which will open up directly. Very cool and practical!

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  There's a guide right here, on my blog! blogs.technet.com/.../lync-publishing-on-uag.aspx

• Anonymous
  January 01, 2003
  Thanks for getting me on the right track.  I'll contact support.

• Anonymous
  January 01, 2003
  More info..This is a SP2010 implementation.  If the external and internal names are the same and using 443 end to end, would I still use the SP2010 application template?

• Anonymous
  January 01, 2003
  If the application public host name is resolving to same IP as the UAG's IP trunk wouldn't that just bring you back to the trunk portal page?  I think I'm missing something here.

• Anonymous
  January 01, 2003
  Current config UAG Trunk public host name: uag.xyz.com Application address: uag2.xyz.com Application public host name: uag2.xyz.com Application URL (Portal Link Tab): uag2.xyz.com Host file entries on test PC setup for uag.xyz.com and uag2.xyz.com to go to same IP. From test PC browser I type https://uag2.xyz.com.  I get the signon for UAG trunk.  Enter credentials.  Looks like UAG is getting to app(I get the uniquesig in URL), but then I get 'IE cannot display the web page'.  I presume that this should have presented me with the internal content from uag2.xyz.com page.  correct? Sorry for all the questions.  This is my 1st attempt of using UAG and SP2010.

• Anonymous
  January 01, 2003
  When a user goes to the public hostname of an app directly, UAG will redirect the user to login, and afterwards, back to the original URL. Then, UAG will attempts to fetch the root of the app from the backend server. If you need to access the app on a different page, you can either configure a redirector on the app server, or use the UAG portal to launch it instead of using the public hostname directly. For SSL, you need one certificate, but it has to contain both the trunk's hostname and the apps. An ideal solution would be a wildcard certificate, but you can also use a SAN certificate, if you need to reduce costs. You cannot use two seperate certs, though - has to be all names in one.

• Anonymous
  May 10, 2012
  The comment has been removed

• Anonymous
  May 11, 2012
  Question 1: No, it will not. When UAG receives the request, it looks into the host headers (which are the URL the user actually typed) and try to match it against the list of predefined apps it has. Once one is locateed, UAG will provide access to it, rather than the portal. Question 2: Yes, you still should. You just don't have to configure AAM for anything, as there is no need for content translation.

• Anonymous
  May 11, 2012
  I'm afraid I cannot troubleshoot this any further via this channel, Bingdude. My guess would be that the SharePoint is sending a redirect to some other URL (possibly an HTTP instead of HTTPS). The only way to see that would be with a tool like Fiddler or HTTPWatch. I suggest you open a support case to work through this. Ben

• Anonymous
  May 16, 2012
  You mentioned Lync, and I'd LOVE to see a quick tutorial on publishing Lync web services via UAG.  I know that it's been supported since UAG 2010 SP1 Update 1, but I have yet to find anyone who has successfully deployed it in the wild.  Scouring the Internet I have yet to find any kind of tutorials and walkthroughs for configuring it other than the most generic of instructions from TechNet.  There are tons of articles on publishing Lync through TMG, but nothing on UAG at all.

• Anonymous
  May 17, 2012
  I have uag.company.com (for Trunk) and app.company.com (for Sharepoint App). Everything works fine. I have two question: What happens when someone types app.company.com? My App must land external user on specific Page and not the home page. How can I make sure of this? Second, How many SSL Certs do I need? Thanks Ray