Ben Ari's UAG and IAG Blog

Plenty of useful and fun info on UAG, Microsoft's remote access and reverse-proxy product.

Understanding and troubleshooting the activation process

Understanding and troubleshooting the activation process

  • Comments 2
  • Likes

Performing a configuration activation on a UAG server is one of those things that we wish we could do without, but understanding how it works and why it is so important can make this a bit more tolerable.

The reason for the activation process is that UAG is but one piece of a big puzzle. You, the administrator, see only the configuration console, but the real work is done by the UAG Filter – a DLL by the name of “WhlFilter.dll”, which you can see for yourself if you open the ISAPI filters Config page of IIS on the UAG Server (be careful there! Don’t make any changes to the Config, as it could destabilize your server!):

clip_image002

When a client interacts with a UAG server, it is actually talking to the IIS web server that’s running on it, and that’s where the filter comes in. Every request that’s received by that IIS is received by the filter, and that’s where the magic happens. The filter parses the request, and invokes additional pieces of code, if such are required. It is the code that contacts the internal server that you are publishing (like your exchange or SharePoint server) and fetches data from it. It performs various actions, like checking the URL for security and performing the HAT process on the content, and then delivers it to the client, which has no idea about all this labor going-on in the background, within a fraction of a second.

Another piece of this puzzle is TMG, which acts as the guard at the gate. It is the component that does the initial screening of traffic that reaches the UAG server. It’s there to get rid of unwanted traffic, and protect against several forms of attacks, like WinNuke, Half-Scan, UDP bomb and others. TMG also configures and protects VPN connectivity, so if you are using the SSTP feature of UAG, it has a major role there too. TMG also contains the infrastructure that’s used for Array management, so if you are using several UAG servers in an array, TMG is your buddy. TMG itself may configure various networking settings within the operating system, like the IP configuration of the NICs when using NLB, or the configuration of the Routing and Remote Access Service (RRAS) when using SSTP.

What all this means is that the configuration you set within the UAG console affects a lot of other components and settings, and that’s the purpose of the configuration activation process. When you run it, it performs these changes within TMG, IIS, and these, in turn, may make changes to other components.

If you want to see what’s going on back-stage while activation is in progress, click on the Messages menu, and select Filter Messages. Then, check the option “Information Messages” on the left and OK:

clip_image004

This will configure UAG to show what’s going on during activation in the bottom of the console window. Here’s a sample of such an output (I photoshopped it a bit, to make it all appear as one screen…):

image

It may be hard to see in the screenshot, but the process is comprised of the following:

1. The configuration file (EGF) is saved (if you’ve been manually saving it before activation…don’t bother)

2. NLB settings are configured

3. Configuring TMG rules

4. Configuring SSTP VPN settings

5. Configuring the SSL Tunneling component (a.k.a. “network Connector”)

6. Updating and creating local configuration files for the trunks

7. Updating and creating local registry entries on the server

8. Configuring settings for the File Access application

9. Configuring the IIS server with the sites for the trunks

10. Configuring DirectAccess

11. Waiting for TMG to synchronize the storage

Naturally, some of these steps may require no actual configuration (for instance, step 10, if you have not configured DA) and are just listed as check-points in the activation process. Others may take more time, like step 3, which typically takes a while. Depending on your actual configuration, the activation process can be as quick as 2-3 minutes and in some cases, take over an hour to complete. It can take a longer time if it has more to do. For example, UAG has to verify the various servers that are configured as part of your applications, and that takes a certain amount of time. If a server’s name does not resolve for some reason, it can cause the activation process to hang while UAG sweats it out. Additionally, each trunk has a corresponding website in IIS, so the more trunks you have, more work is required for configuring these sites.

Even though an activation is not something you do all the time, it can be annoying to have to wait a long time for it to complete, but before thinking something is wrong, keep in mind that in the real world, even strong servers typically take 5-10 minutes to activate, and a complex Config (one with many trunks, many apps or many services) would easily take 15-20 mins. If your numbers are higher, or make no sense to you, the 1st step would be to observe the steps shown with the “information messages” showing, and seeing where there are big gaps. For example, you might see that there’s a delay after step 5, which could happen if the Network Connector is heavily utilized. In such a situation, it may take the service (the WhlIOS service) a while to stop as it’s shutting down connections. The final step (TMG Storage sync) can also take a while if you have an array with several servers, as TMG is pushing the configuration to the other members sequentially).

Once you have identified a problematic stage, you can try to disable it, to prove it’s causing a problem. For example, if you see a significant slow-down during step 9 (IIS Config), there may be an issue with IIS or with one of the trunk settings. You could, in that case, try disabling some or all of your trunks, and try to home-in on a problematic one. If you have a small number of trunks (or just one), you can try disabling the applications on the trunks, to see if one of them may be slowing down the process because of a non-responsive server. As with any performance-related investigations, a good idea would be to keep track of your time. Start by measuring a baseline of the activation time when the UAG server is new and has little or no configuration, and measuring it regularly too. You may discover that what took 10 minute last month now takes 20, and this way, you can look at the changes that occurred between those two as a starting point.

Comments
  • Do other trunks get affected when activating / applying the configuration?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment