The case of the missing and reappearing files and registry keys

Today I figured I would address an issue that has been encountered by some UAG administrators – the “haunted” UAG server.

Why haunted, you ask? I’ll tell you why. Because settings you configure in CustomUpdate files or registry keys, rather than in the UAG Management console, mysteriously disappear after you have applied them (and sometimes even after you’ve seen them affect your UAG configuration as expected). An additional symptom is the opposite behavior – a file or registry key that you deleted, suddenly reappears uninvited.

Before you run and call the nearest exorcist, let me try and explain why this happens, and you will see that it actually has nothing to do with tales from the darkside.

As you are probably aware, UAG stores its entire configuration in the TMG storage, an Active Directory Lightweight Directory Services (AD LDS) instance. The storage includes all the configuration settings from the UAG Management console, as well as configuration files, both default and CustomUpdate, and UAG-related registry keys. Each activation performed from the UAG Management console collects all of these settings into a “package”, which is then pushed into the TMG storage. These configuration settings are then extracted from the TMG storage, unpacked, and applied to either a standalone UAG server, or to UAG servers in a UAG array.

However, not all configuration changes in UAG seem to require activation. Some configuration settings are read by UAG components at runtime. For example, a custom .INC file that you just placed in the correct CustomUpdate folder will immediately be used by the relevant UAG .ASP script. The opposite is also true – if you delete or rename a CustomUpdate file from the relevant directory that too immediately changes the behavior of your UAG server. This behavior might lead you to believe that you do not need to activate the UAG configuration.

Another example is changing UAG functionality by means of a registry key. Let’s assume you read here that in order to configure UAG to perform Kerberos constrained delegation to a backend web server using UPN, you need to modify the KCDUseUPN key. Since making this registry modification will not take effect without you taking some further action, you would probably restart “the UAG services”. If you have some experience with UAG, you might correctly decide to restart the Microsoft Forefront UAG User Manager service, since this is the service responsible for both front-end and back-end authentication. So you do this, and a few dependent services are restarted too. All is well, and UAG seems to behave as expected.

So when does the mystery begin? Usually, it begins after your UAG server is rebooted. We hear UAG admins claiming “It used to work! I didn’t change anything. I only rebooted the server!” And they are, of course, right. So what’s to blame for removing files that were there before the reboot, for placing deleted files back on the hard drive, or for reverting changes to registry keys?

The culprit is the Microsoft Forefront UAG Configuration Manager service. Every time this service starts (and it starts after a reboot), it fetches the last stored configuration from the TMG storage, and applies it to the UAG server on which the service is running. This ensures that a server that has been powered off starts with an updated configuration that matches the configuration currently saved in TMG storage. This is particularly important in an array, where array changes controlled by the array manager might have occurred while an array member is switched off.

This, therefore, is the reason that you need to remember to activate the configuration after you make any changes to UAG files and registry settings, in order for these changes to be stored in the TMG storage. You do not necessarily need to activate immediately. You can first test the changes. But once you decide to keep the settings, remember to activate, or else the next time you reboot your server (and by that time may have forgotten you ever made changes), your UAG server will revert to a configuration that does not contain the changes, and you’ll be left wondering who or what possessed it.

Author:

Ran Dolev, Senior CSS Engineer, Microsoft Forefront UAG

Reviewer:

Rayne Wiselman, Senior Writer