Today, a little UAG-related gotcha I wanted to share with you. Consider the following:
- Multiple SharePoint web applications are published under the same trunk
- All web applications are served by the same back-end SharePoint servers (the ones you define in the “web servers” tab for each published application)
- AAM and other required configurations were made according to best practices
Then you’re likely to face the problem described below:
- Through the UAG, you attempt to directly access to http://webapp02.mydomain.com/sites/mysiteonwebapp02/
- You’re redirected to the portal for authentication
- You authenticate successfully
- Alas, you are redirected to http://webapp01.mydomain.com/sites/mysiteonwebapp02/ and a naughty 404
Why such a behavior? Well the explanation we received from the support is the following: When compiling and activating its configuration, UAG builds a list of unique web servers on a per-trunk basis instead of per-web application. Therefore, it is likely that although you’re trying to access the correct web application directly and authentication happens successfully, you may be redirected to the first web app in the list that has the same web servers defined.
I did not have time to test but it is likely to face the same issue when publishing any type of web application (IIS…) as long as they meet the configuration stated above.
Fortunately, the MS support proposed 2 workarounds:
- Publishing each web applications under different trunks. Wow, heavy isn’t it? No to mention possible problems with DNS domain conflicts…
- Creating a DNS alias (or entry in the HOSTS file of the UAG) for each web server hosting each web application such as webapp01-srv01, webapp01-srv02, webapp02-srv01, webapp02-srv02 and so on in a way that each entry is actually perceived as globally unique for the trunk
Apparently, this behavior considered by design, is unlikely to be fixed in a coming update or service pack.
PS: Big thanks to @jlebutte for his help!