One of the common errors seen by many UAG users, usually following a new installation, is the error message “The configuration cannot be loaded from Forefront TMG storage. An unrecoverable error has occurred. The application will close”.
This is particularly frustrating on a freshly installed server, when there’s seemingly nothing to do.
The reason for this error is, at it indicates, that the UAG configuration console is unable to communicate with TMG, which is the firewall that protects it. There is more than one reason for this, but the most common one is that TMG itself cannot communicate with the computer’s domain controller. This might happen if the networking configuration of the computer is such that once TMG comes up, it blocks communication to the network in which the DC is. There’s no single solution for this, because that depends on the network configuration. For example, if the UAG server is on the DMZ, and the DC is inside the corporate network, it could be the cause.
When UAG is installed on a computer, it automatically installs TMG, and it then configures TMG with the entire IPv4 address range, except 127.x.x.x, as the “internal” network:
This should allow it full communication to the internal network until you get a chance to run the UAG getting Started Wizard, which reconfigures that based on your selection of which Network Card is the “real” internal network. However, if the networking is configured incorrectly, it could still cause a problem. For example, if the default gateway or subnet masks are misconfigured, it could disrupt configurations. We’ve also seen cases where the administrator has been successful in launching the UAG management console, and ran the getting-started wizard with the wrong settings, causing the “internal” network to be configured incorrectly, thus blocking access to some or all resources on the internal network.
Another scenario where a similar issue can occur is if TMG itself is off – if its services are not operational for some reason. One common reason for this is an organizational group policy that prevents them from running. For example, a group policy may block the RRAS service, on which TMG relies. In such a case, the TMG services won’t come up, and launching UAG will give out the same error. The solution is to make sure the UAG server is excluded from such group policies. Ideally, it should be excluded from ANY policies (even if to simply save you the time-waste of trial-and-error). One thing that’s important to keep in mind is that excluding the computer from group policy does not necessarily “clean” it up. Policies are applied as registry settings, and just disabling them after they have been applied to a computer may not reverse the settings.
Another situation where this could happen is if there’s some hardware problem that prevents TMG from working properly. For example, certain virtualization technologies do not emulate Network Cards properly, causing TMG to fail. TMG should work fine on all hardware platforms, but if you are running it as a virtual machine, you can check if the VM software is compatible. The 1st step would be to check if all TMG services have started successfully. This is done using the Event Viewer – look for TMG services that are set to “automatic” but are stopped:
If this is the situation, you can check your version of the VM software using this URL:
If you suspect your server’s hardware may be unusual, you can check the Windows Server Catalog for compatibility:
If the TMG services are all up then inspect the computer’s routing table, IP configuration and the IP range that’s set as the “internal” network (see screenshot above). Think of the configuration, and try to trace (in your mind or with a network map) the network route from your UAG to its DC. A common for administrators to configure both NICs with the same network Config (IPs on the same network segment), disable one of the NICs, set a default-gateway on the internal NIC instead of the external, or on both NICs. Keep in mind that UAG is a router…and it’s network configuration has to make sense, and allow it to route traffic from the users on the external side, to servers on the internal side, and back. UAG can often “survive” and even work with a wrong configuration, but even so, it’s a good idea to only use the server in a supported configuration.