Remember how the arrow buttons on the main trunk configuration used to move the applications up and down on the list? Normally we don't need to move the applications. One situation where this may be needed is when there is an application conflict because of two applications that use the same internal web server.

When UAG receives a request from a client, UAG tries to match it against the list of applications, from top to bottom. If a match is found (based on the web server name, path, and port number defined in application properties), it is processed (based on that particular application's properties and its related advanced trunk configuration), and UAG does not continue down the list, even if there are additional applications that are configured with the same web server, path, and port number.

To understand the importance of this, consider an example in which you are trying to publish SharePoint and Exchange OWA, which are hosted on the same internal server. Although it's not a very common configuration in the real world, it is ideal to illustrate the problem we are about to discuss. The SharePoint and Exchange OWA applications are configured on the UAG trunk so that SharePoint is listed above OWA. When a user tries to access OWA via UAG, their request may fail in some situations. That's because by default, the SharePoint application allows access to the root path and everything below it (the application path is defined as "/"). With the SharePoint application listed above the OWA application, all the requests are matched with it and no request for OWA will ever hit the OWA Application. Failure may occur in some situation where the trunk URL Set (usually referred to as URL rule set and discussed in detail in Chapter 10) for SharePoint does not allow some specific OWA requests.

To address this type of a problem, you can change the order of the applications on the list, but this is not always simple. To make an informed decision (as opposed to guesswork that could result in applications being blocked or applications being less secure than they should be), consider the paths and URL rule set of your applications, and make sure there is no conflict in any scenario.

For our example, the fix is to move the SharePoint application below the Exchange OWA application. Now, requests for the OWA application will match the OWA application because it allows specific paths like /OWA or /Exchange. Since these paths are not used by SharePoint, when the user accesses the SharePoint application, the root path or path for a particular site collection will match the SharePoint Application, and both will live together happily. Keep in mind that Exchange and SharePoint are just examples and there is no cheat-sheet for deciding which application types should be listed above others. In case you have to troubleshoot a similar issue and you are not able to figure out the correct order because of a long list of applications, the UAG Web Monitor comes in handy.

The UAG events will show which request matches which Application Type and in most cases, it will also indicate if there is a failure because of the URL rule set not allowing a specific request. These events are viewable using either the Web Monitor or Windows Event Viewer (in the Application Log with a source of Microsoft Forefront UAG). Monitoring the UAG server will be discussed in more detail in Chapter 9.