When configuring a UAG server, almost everything is done using the UAG console, and typically, that would also be the primary tool for viewing the configuration. Many companies who need to have a documentation of their configuration turn to grabbing screenshots of every possible configuration screen, which could be tedious and time consuming.
One thing that could save time and effort is the fact that the UAG configuration is stored on the server in a text file called UAG.EGF. The file is stored on the UAG’s local hard drive in the folder <UAG Path>\common\conf, and can be opened and viewed by any text editor. A typical file would look like this:
The screenshot shows part of the configuration of one of the applications on a trunk. The formatting is not very easy to read, but UAG also comes with a utility that can convert the EGF file into a standard XML, which is a lot easier. This utility is ConfigMgrUtil, and you can find it in <UAG Path>\utils\configmgr\ConfigMgrUtil.exe. To use it, open a CMD prompt, and run the utility with the toxml parameter to perform the conversion. The parameter needs to be followed by the target name (xml) and the source name (the EGF). For example:
The resulting file can be opened by any XML viewer, including IE itself. For example:
Even this format is not as easy to read as the administrator’s console, but with some time and patience, it all makes sense. For example, under the EgfSettings/repository_settings/RepositorySettings/repository_entry_settings_list tree, you can find the configuration of the repositories you have defined on the UAG. Under the EgfSettings/connections_settings_list/ branch, you can find your trunks, and under them, your applications (in the filter_settings/app_settings_list/AppSettings under each trunk). By carefully inspecting the XML, you can retrieve each and every repository, trunk and application settings configured on your server.
Look, but don’t touch!
If you think that just because the data is in a text file, you can simply edit it at will…then you would be wrong. The primary storage for the configuration is actually TMG, and any configuration change is stored in TMGs storage mechanism, where it’s protected from harm (that storage is also used to sync the configuration across the members, if you are using an array of servers). If you try to edit the EGF file directly, UAG will simply discard the changes as it retrieves the file back from TMG. This is also why one must ACTIVATE the UAG configuration upon making changes, because until you perform the activation, the configuration is not stored yet, which also means that a restart of the UAG services or the UAG console would revert it back to the version stored in TMG. In some extremely rare situations, there’s an inescapable need to edit the EGF file manually, such as when there’s a distinct corruption of the file. For such a situation, UAG has a special registry key called IgnoreTMGStorage. When that key is set to 1, UAG will pull the configuration from the local file, instead of the one in TMG, and that allows editing of the file as well. I won’t document the procedure with any more detail here, as it’s extremely risky. If you edit the EGF file incorrectly, even a single line-break or space in the wrong place could end up trashing your configuration completely.