Where am I?

Many organizations use an array of UAG servers, with some load balancing technology that might land an incoming user on any one of the servers in the array. In such a situation, a common need is to know to which of the multiple UAG servers the user has actually connected. This can be useful when trying to troubleshoot a problem, and needing to know which server to inspect for the source of the problem (or run a trace on).

Thanks to the PostPostValidate technology I discussed in another article, you can have UAG “mark” a session visibly. In case you don’t remember, PostPostValidate is a custom hook that allows you to run your own piece of code following a successful logon to a UAG server. To get what we need with this feature, all we have to do is set UAG to run some code that will mark the session with the server name in a way that allows us to see it.

To do so, the 1^st step is to gather the server’s name. We want to avoid hard-coding it into the custom file, because we would want it to replicate automatically across the array (as part of the activation process), so it should be the same file on all servers. The wscript.network COM object allows our code to dynamically get that information. The 2^nd step is injecting this into the stream. One way to do so would be as a custom HTTP Header, but that is less useful, because the header is not normally preserved. If we did so, we would be able to see the data as part of the response to the Validate.asp page, but afterwards it will no longer be there. A better way would be to use cookies. Cookies are stored in the browser, and if we use a session cookie, it will be kept as long as the session is running and the browser hasn’t been closed.

One challenge with creating cookies is avoiding UAGs cookie signing mechanism (HAT). Normally, UAG would sign the cookies name, and this would obfuscate it from seeing it clearly. A trick to get around that is specifying the cookie’s DOMAIN. To do so, simply use ASP to specify the cookie’s domain, and set it to be identical to the trunk’s main domain name (just the domain, not the FQDN). For example, my trunk is uag.createhive.com, so I specify the domain as “.createhive.com”:

To use the above code, put it in a file called <Your trunk name><1 for HTTPS trunk, 0 for HTTP trunk>PostPostValidate.inc , and place it in <UAG Path>\Von\InternalSite\Inc\CustomUpdate. Then, activate your configuration, and presto – from now on, every session should have a cookie listing the computer name that the user is connected to. You can use a tool such as HTTPWatch or Fiddler to observe these cookies. If you don’t have these, another simple way is this:

1. Press F12 on the keyboard, to open the Developer tools window (don’t worry…it’s not JUST for developers…)

2. Open the Cache menu

3. Click View Cookie Information.

4. In the new tab, look for your cookie:

One thing that this trick doesn’t solve is a situation where the user is actually moved from one UAG server to another in the middle of a session. This is not a normal situation and would typically result in multiple problems. Unfortunately, there is no clean and supported way of detecting such a situation. These are the limitations of this technique.