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!