UAG is offered to the public in two distinct distributions. A company can choose to purchase the product in the form of an appliance, or as a downloadable ISO image file, which can be burned to DVD or mounted as a virtual DVD drive and installed from. If you have elected to go with an appliance, then there's nothing to worry about with regards to requirements, but if you are to install it yourself, there are more things to consider.
UAG is a server product, and can only be installed on a Windows Server 2008 R2 or later. Windows 2008 R2 is only available as a 64 bit system, so that will affect the hardware requirements that are discussed a little later in this chapter. Since UAG is ultimately just a piece of software running on Windows, this might be tempting for some organizations to try and conserve resources by assigning multiple roles to the UAG server. For example, a company might want to use the TMG included with UAG to publish some internal servers, or try to use TMG's web-caching features to speed up a user's access to the web. Microsoft strongly discourages that notion, and for a very good reason. The reason for this is because UAG is not just a program – it's a service that interacts with many other components. For example, when you publish an application on the server, UAG pushes the configuration directly into TMG, as well as IIS, so any changes the administrator makes to any of these components manually could interfere and conflict with those done by UAG. This could lead to various breaks and interruptions in functionality, and in a worst case scenario, could seriously jeopardize the security of the system. For example, misconfiguring TMG's Local Address Table (LAT), which lets TMG know which IP addresses are within the internal network, and which are not, could lead it to think that a connection attempt from the external network (the internet) is actually coming from the internal one, and trust it falsely. In this case, it could let an attacker sneak in unnoticed. What's even more problematic is that if an administrator makes changes to components that they are not supposed to, it makes it difficult or impossible for Microsoft to support. You can think about this like a warranty sticker. Just like the fact that opening up your stereo's case and fiddling with the wires would void the warranty, messing around with the "wires" of a complex software product can make the product unsupportable.
If you run into a problem, Microsoft's support can't guess what you've done and can't possibly check every setting in the entire system. They can inspect UAG's configuration and Networking configuration, but might not be able to find the real cause, as it's lurking away in some other configuration dialog that is not normally used.
The official guidelines dictate that UAG needs to be installed on a "clean" server, with no other applications installed on it. This might be somewhat over-protective. This doesn't mean you can't have an Anti-Virus running on the server—on the contrary, having an AV product is a great idea. However, to decrease the likelihood of an installation failure, it's best to start with a server that's clean, if possible. "Clean", in our book, doesn't mean a server that was loaded with stuff, and that stuff has been uninstalled. If your organization mandates certain software to be installed on every server, like a remote-management agent or hardware-specific software, these should not be seen as a deal breaker, and installation should still run smoothly. Keep in mind, though, that if it fails, Microsoft Support may request that you retry it with a clean server.
Another requirement for installation of UAG is Administrative rights. This should be a no-brainer for most administrators, though we have seen cases where it has been missed. The computer can be a stand-alone server, or a Domain member, but if it is a domain member, then the installation needs to be done while logged on to the server as a domain user with local administrative permissions.
It's very important to correctly define the computer's Network configuration, computer name and domain membership before starting the installation, as some of these settings are difficult or impossible to change afterwards. You should have two Network cards installed – one for the "external" network, and one for the "internal" one. The external could connect to the DMZ, and you can rename the network cards at any point, but the following need to be configured:
IP addresses for each network interface
Subnet mask for each network interface
DNS for at least one of the network interfaces (most organizations would use their internal DNS, and so configure that only on the internal NIC)
Default Gateway on only one of the interfaces, usually the external interface.
If the computer name is some random string generated by your system deployment automation, make sure you set the server name to a permanent one, and if it is to be a domain member, join it to the domain first.
An installation option favoured by many organizations these days is a virtual-machine based installation . This has many advantages – it allows easy change control via Snapshots or saved-states, as well as setting up a warm backup server easily. One must keep in mind, though, that this might have an impact on the server performance, as a guest machine is inherently weaker than its host, and this might introduce risks, especially in the Network Performance arena. When considering using a virtual machine, one must keep in mind that not all virtualization platforms are the same. Certain platforms are incompatible with UAG, so you should consult the Windows Server Virtualization Validation Program (SVVP) to make sure yours is supported. Don't take this lightly, as using an unsupported platform can cause serious problems. The SVVP validation website is here: http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm
Lastly, many organizations have their server hardware located in remote or secure server rooms, with management being done remotely. If that is the situation in your case, keep in mind that the installation of UAG affects the server's networking, and the installation might sever communications with the computer, since as part of the UAG installation, TMG is installed and launched. You might find yourself thrown off the RDP session and unable to reconnect to the server. We recommend you prepare a plan to gain physical access to the server in that case.