For most organizations, a UAG deployment is a lengthy process. Some applications are easy and quick to deploy, but some might take some experimentation and tweaking to get just right. For this reason, most organizations prefer to start by setting up their server in a test or temporary environment, and roll it out to production only at a later point in time. Some organizations even keep a non-production system online on a regular basis as a test platform for new applications, or as a way to verify new service packs or updates to products (incl. UAG itself) before committing them to the scrutiny of their users.

As we mentioned earlier, it is very important to have the test environment simulate the real world as closely as possible. We have seen many deployments where an administrator tried to conserve resources by having the UAG server use only one NIC and connecting it to both the logical "internal" and "external" networks. We have also seen many cases where the administrator connected the UAG's "external" interface to his corporate network, so they can leverage corporate PCs as test clients. Both of these scenarios are invalid, and can cause failure very early on. Even worse, they can lure the administrator into a false sense of security if things appear to be working out, but when the server is finally put in the line of fire, things could go sour in a heartbeat.

A single-NIC scenario (where both internal servers and clients interact with UAG from the same side) can be made to work in some cases, but it's not supported by Microsoft, and so should be avoided. A reversed-side scenario is a problem because UAG's firewall, TMG, defines the external network as "dangerous" and limits connectivity from it. TMG may block access to the domain controllers because of that, and this not only can prevent some applications from working, but it can also cause some of the fundamental services for UAG and TMG to fail, and ruin the party.