Microsoft Forefront UAG 2010 Administrator's Handbook

Even though installing a UAG server is quite straightforward, it is very important to plan your deployment ahead of time and prepare your hardware, software, and network correctly. Failing to do so might end in an installation failure, or even worse—a situation requiring a lengthy re-planning of the integration, not to mention explaining all of this to "the guys upstairs".

When planning the installation, one must keep in mind that a UAG server is fundamentally a router. It has an external side that would be the access point for connecting clients from the internet, and an internal side through which the server can fetch data from internal corporate servers. While it is theoretically possible to use the server with a single network card, this option is not supported, and will not work for most of UAG's functionality. UAG includes Forefront TMG (Threat Management Gateway) 2010, Microsoft's well known enterprise-class firewall; therefore it is possible to have the external interface connected directly to the internet. Nonetheless, many organizations choose to play it extra-safe and place the server behind an additional firewall, which can also improve UAG's performance by eliminating junk traffic that might otherwise burden it. This, of course, requires careful planning of the routing, as well as opening the proper ports on the firewall to allow traffic to take its course.

UAG is designed to enable remote access in two primary roles: application publishing and VPN. A regular proxy is a server that resides at the edge of an organization's network, like a guard at the building's reception. The regular proxy fetches data from the outside world for the company's employees, much like a guard would escort a guest to an employee's office. A reverse proxy does the exact opposite—it fetches data from within the internal network, and delivers it to people on the outside. A regular proxy is usually about speeding things up, but also about protecting the network from uncontrolled access, while a reverse proxy is mostly about security. This is especially so for UAG, which might slow things down a bit, but provides a high level of security.

The benefit to an organization is that, using reverse proxy publishing, employees working from home or on-the-go can access the organization's internal applications from wherever they are, while still maintaining the organizational network safely and securely. Those of you who know their firewalls must be thinking "But...any firewall can do this!" That is correct – almost all modern firewalls allow various forms of server publishing, but UAG adds additional levels of security. Firewall server publishing is usually quite simplistic – an administrator specifies the internal IP and port, and the firewall listens and forwards the requests and responses to and from the internal servers. From a security standpoint, this is almost equivalent to allowing the users to interact directly with the internal server, as the firewall inspection usually takes place at the TCP packet level only. Sure, it can recognize and stop some common Denial of Service (DoS) and other attacks like Port scan and half scan, but hardly any application-level attacks. UAG, on the other hand, is much cleverer:

The second major functionality of UAG is VPN, which allows remote users to connect to the organization's network in a way that emulates them being connected directly to the network while at the office. This sort of connection can allow them to do anything they could do in the office, and provide the most advanced work environment (pyjamas notwithstanding). This functionality was included with previous versions of UAG under the name Network Connector. Network connector, or NC for short, was a VPN ability that was based on encrypting the connection with SSL, and was a proprietary technology developed by Whale Communications. At the time, Windows Servers also had built-in VPN abilities, but only based on the PPTP protocol, which is considered to be not very secure, and L2TP, which is quite secure, but difficult to deploy because of its complexity.

Today, with UAG, multiple VPN technologies are included. NC is still there, though it has been renamed to SSL Network Tunneling. SSL Network Tunneling is also limited to classic client operating systems like Windows XP and Windows Vista. A new addition is SSTP, which is a more modern incarnation of SSL-VPN for Windows 7 users The most important remote-access technology included with UAG is DirectAccess ( DA for short), which offers a new and unique seamless VPN-like integration. With DA, users are virtually connected to the corporate network as soon as they connect to the internet, with no interaction or any need to configure components and launch diallers. All these will be covered in detail later in the book.

UAG's core functionality is as an ISAPI filter and extension, as well as various mechanisms to control other parts of Windows. ISAPI (Internet Server Application Programming Interface) is a technology that allows programmers to build add-ons for websites, enriching their functionality. UAG is heavily reliant on ISAPI to do its job, and integrates itself into Internet Information Services (IIS), Microsoft's Web server components that ships with Windows. This integration gives UAG its "face"—users logging in see a website that is generated by UAG, and UAG's ISAPI filter and extension are the components that fetch data from internal servers and show it to the user.

To do this, UAG has a mechanism that allows it to manipulate the IIS configuration directly. It creates one or more sites in IIS, and integrates itself into them by registering its ISAPI filter. Since the UAG ISAPI components are integrated into the IIS website, content going to and from the site goes through these, and they can manipulate the data directly and efficiently. To learn more about ISAPI, read the following article: http://msdn.microsoft.com/en-us/library/at50e70y(VS.80).aspx

If you take a look at IIS on a fresh UAG installation, you will notice that the Default Website contains some new virtual directories, such as " InternalSite", which has been created by UAG. This virtual directory hosts the login screen that users see, as well as other pages like the log-off page, error pages, and others. "InternalSite" also includes the various authentication mechanisms, the client detection and installation system and more. It looks darn good, if you ask us. As you'll start configuring portals on UAG, new virtual directories will appear under the Default Web Site of IIS running on the UAG server, the PortalHomePage virtual directory. This directory hosts, as its name suggests, the web resources that together compose the homepage or landing page of the portal, which end-users reach after successfully authenticating to UAG. This page displays links to all the published applications through this portal, as well as a UAG-specific toolbar.

The building blocks of UAG are Trunks and Applications. You can think of trunks as an organizational unit that can contain multiple applications. Depending on an organization's needs, the server can publish a single application, several applications within a trunk, or multiple applications within multiple trunks. An application is typically an internal server that is published through UAG, although the term can also be used to describe something that is not a website. For example, UAG has a "SSL-VPN tunneling" application, which creates a VPN connection from the user's computer to the organizational network, and allows direct access to internal resources.

If you have never seen a UAG server at work, the following screenshots offer a quick peek. Home users type into their browser a URL they are given by the networking team, and reach the illustrated login page. Even before reaching this page, their computer is checked to see if it meets the organization's security policy. For example, the organization might require that the computer is running an updated copy of Norton Anti-Virus as one of the conditions for entry:

Once users enter their password and it has been successfully verified, they are taken to the "portal" page, which lists the applications that have been published by the networking team. The middle section of the screen shows the icons, and there is also a frame on the left of the screen that shows the same applications. The top of the portal shows additional action buttons:

Users may select to launch the SharePoint application. This looks like any ordinary SharePoint page, but it's actually being displayed by UAG. Users get to it without having to type in their username and password again, since UAG has performed single-sign on to the SharePoint server, using the credentials that it has already collected from the users. On the left, the application tool bar remains, although it can be collapsed to free up screen real-estate. The top bar also stays there and contains the Log Off button, the Home button and more:

When finished, users click on the Log Off button on the right-hand side of the portal bar, and disconnect from the portal. This not only disconnects them, but also wipes clean temporary files that have been downloaded to their computer while working. For example, if they opened Office document attachments from the site, these will be wiped securely, so even if their computer is stolen, that data will not be recoverable by the thief:

When working with some services, such as OWA and SharePoint, UAG has the ability to manipulate the data stream received from the backend server, and add functionality to it. For example, in the case of SharePoint, as seen above UAG rewrites the functionality behind the Log Off button, so that when a user clicks on it, it not only logs off from SharePoint, but also from the UAG portal itself. This is designed for convenience, of course, this way the user does not have to press Log Off multiple times. In fact, for SharePoint and OWA, UAG also rewrites the data that comes in from the server and hides the log-off buttons that these servers normally show, so that the user can have only one button to click. This manipulation is called Application Wrapping, and it's also customizable by the server's administrator. With a good understanding of HTML and other web development technologies, as well as careful planning, an administrator can affect the way anything that goes through UAG looks. For example, the organization's logo can be added to pages, or specific text messages can be shown. Some customers have even used this technique to replace whole pages with others, to "cover up" information that they wanted to keep confidential.

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:

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.

Since UAG is installed on top of Windows Server 2008 R2, the hardware requirements are combined with those of R2. The primary requirement for R2 is having a 64 Bit processor and 32 GB of free disk space, and that's easy enough to get these days. UAG's minimal requirements are that the processor is a dual-core one, running at 2.66 GHz or faster, 4 GB of memory, and an extra 2.5 GB of disk space.

In reality, UAG can run on weaker systems, so if you just need to install it temporarily for a proof-of-concept or for training purposes, you could get away with a lot less (though installing it on a Commodore-64 is really taking it too far). For production environments, the stronger the better, especially with memory size, as going with the bare minimum may limit the number of concurrent users the server can handle.

If you were hoping to learn here how many concurrent users the server can support, you're in for a disappointment. While some other server software has a very linear model for client support, UAG's performance varies significantly by the type of applications that are published and the way users use them. For example, RDP applications transfer a lot of data back-and-forth between the client and the target internal server, so that would put more stress on the UAG server compared to a typical intranet, mostly-text web portal. The only way to know with a reasonable amount of certainty how many users your server can support is with a baseline performance analysis. That would include analyzing typical user activity and simulating multiple users in a test-environment, while using the built-in Performance Monitor to see how things are going. Doing performance analysis is not easy, and there's always a risk of miscalculating, but be wary of skipping this just because a sales person claims your server can support "thousands" or "millions" of users. We have seen quite a few deployments where the customer found out too late that they require more servers, and that was not only costly, but also quite frustrating and embarrassing to all parties involved

We already mentioned the Networking requirements earlier, but it's worth repeating. A UAG server is a router, and as such, needs two Network cards. If you are deploying on a virtual machine, this is rather easy, but if it's a physical, make sure you have two real NICs in place. There's no harm in having additional cards, although one must carefully plan the IP, Mask and Gateway settings so as to not arrive at a configuration that will prevent the routing mechanisms of TMG from making the correct decisions as to where to send packets and block dangerous or inappropriate traffic.

We assume a network administrator does not need this book to learn how to physically secure a server, but there is one hardware aspect that should be kept in mind. Many organizations place their servers in a secure location – a dedicated server room (a.k.a. The Dungeon), which is sometimes even isolated from the main company campus. This is not a bad practice, but keep in mind that during installation, remote-desktop connection to the server might be disconnected, so it's worthwhile to keep an option to reach the server physically. Another thing that's good to keep in mind is that UAG is designed to serve clients connecting from outside the organization, and so using it from "inside" is unsupported and will not work for the most part. Some features can be tested from the internal network, and some can even be tested by launching a browser on the server itself, but we strongly recommend that any organization plan for a "real" test client.

From a networking perspective, placing is even more important. Most organizations place the server in their DMZ, and have one firewall in front of it, and another behind it. This is not a bad idea, even though UAG does include its own robust firewall – TMG. Regardless, if any additional networking hardware is in the picture, care must be taken to allow the right traffic to flow. The frontend firewall needs to allow traffic to the UAG server's external IP from any IP, and allow ports 443 for Secure portal trunks, and port 80 for non-secure trunks or HTTP to HTTPS redirection trunk (those are used when the portal is on HTTPS, but you want to avoid forcing your users to type the elusive 'https' prefix to the URL).

The backend firewall needs to be configured to allow UAG to communicate with whatever servers it needs to publish, as well as traffic to its domain controllers, and to the authentication servers used by UAG to authenticate end-users. In some scenarios that require the use of digital certificates, access to a Certificate Authority is also required. Keep in mind that if UAG is used to publish non-HTTP or non-HTTPS servers, additional ports may need to be opened. For example, if RDP access to internal servers is required, port 3389 needs to be allowed.

If load balancers are to be part of this dance, it introduces quite a few other considerations. For example, how is stickiness going to be preserved? Different load balancers have different mechanisms, and those need to be accounted for to make sure that once a user has connected to a UAG array member, they will not be handed off to another one, mid-session. UAG's session information is not shared across members of a UAG array, so if that happens, the user will be redirected to login again, and depending on what they were doing, may lose data.

Another important consideration to take into account is DNS. Clients that are connecting to UAG from the public internet will need to connect to the server using a host name, and not an IP address. Depending on an organization's DNS hierarchy and server placement, this may affect the deployment. This is especially true if SharePoint servers are to be published, as they require their own additional DNS mapping (more about that in Chapter 4). The UAG server needs to be able to resolve internal hostnames, so Port 53 needs to be open on the internal firewall, if one exists. If load balancing, either front or back, is done, the effect it has needs to be planned as well, to make sure UAG has access to all the relevant internal servers.

From a networking perspective, one must carefully plan the IP addresses assigned to the server, especially when NAT needs to be used on either the external or internal side. During the installation of UAG, the TMG firewall is also installed, and it includes a set of access rules that define the internal and external networks. An administrator should avoid assigning temporary or invalid IP addresses to the server, if possible. If the plan is to have the server hosted in a temporary test environment before deploying it to the production environment, do your best to simulate the real environment as closely as possible. A common bad practice that often leads to problems is configuring the external side of the UAG server so that it's facing into the internal corporate network. This sounds attractive as it would let you do testing with internal corporate computers, but it could lead to impossible routing scenarios, and is strongly discouraged. A good practice would be to dedicate a computer or a virtual machine to be used as a test client, and physically connecting it to the same subnet as the external interface.

As stated before, UAG is, fundamentally, a router, so the Subnet Mask and default gateway are also very important. A default gateway should be assigned to the external interface of UAG only, and the subnet masks and IP addresses need to be carefully planned so that there is no overlap. If the internal network contains additional IP ranges that are outside the IP range assigned to the internal Network Card, these may need to be added to the Server's routing table in the form of static routing rules. All this should be done before the product is installed, so that the TMG server does not end up being inoperational due to network configuration conflicts or blocking traffic it should not be blocking.

An important consideration for UAG is whether to have the server as a domain member or not. From a security perspective, the less connection the server has to other infrastructure, the better, and so most organizations would prefer to have the server be a stand-alone server (member of a workgroup that is). However, some UAG features and scenarios necessitate domain membership. Also, even when not a domain member, UAG usually needs to provide it's users with access to the published applications based on the user's domain membership. In that case, even though the server does not have to be a member, it does need the type of access a domain member would need in order to authenticate the user. For example, free passage for the RPC (Remote Procedure Call) protocol is necessary to let UAG query a user's group membership.

As mentioned before, the following specific scenarios do require explicit domain membership:

We will discuss these scenarios in further detail in Chapter 6, and Chapter 11. Please note that if your plan is to use this server for DirectAccess, then you might need to address some additional requirements. In that case, don't start the installation before reading Chapter 11.

UAG supports several types of remote connectivity that are beyond simple application publishing, and these sometimes require additional considerations. The first such scenario is, of course, DirectAccess—a.k.a. the VPN Celebrity of 2010. DirectAccess configuration is pushed out to clients using Group Policy, so this has to be factored in as well. Just having a group policy active is not enough, of course. UAG will create the proper policy, but collateral policies may need to be adjusted. For example, the local Firewall service on each client needs to be on (although the Firewall itself can be off). If your organization's group policy has been defined to set Firewalls to off, you might have to go in and change that.

Another consideration for DirectAccess is to have an elaborate infrastructure of digital certificates, also known as PKI or Public Key Infrastructure set up, in order to satisfy the requirements that are imposed by the highly secure IPSec tunnels, which are the fundamental tunnels used by DA. The UAG servers need to have digital certificates with their public hostnames, and the Certificate Authority (CA) that issued those needs to be trusted by the clients. In fact, you will have to have each client computer connect to the corporate network at least once to obtain the DirectAccess Group Policy, so if you were counting on sending out an email with instructions and going home early, think again. We will discuss DirectAccess in more detail in Chapter 11.

Another way of providing remote connectivity with UAG is SSL Network Tunneling, formerly known as Network Connector, and its successor, SSTP (Secure Socket Tunneling Protocol) . Network Connector has been around for ages, and as such, it has some limitations, the most important being that it is unable to support Windows 7 clients. SSTP can be a suitable solution for some scenarios, because it supports Windows 7. SSL Network Tunneling is not difficult to configure, but it does require careful planning of the IP and Network configuration assignment, as well as the split-tunneling mode. You will have to configure SSL Network Tunneling with an IP pool that does not overlap with your Network's range. You can also assign a specific IP range and Networking configuration so as to control the client's access to various servers. For example, you might feel that connecting clients should have access to RDP to their own corporate computers from home, but not to the corporate servers—or the other way around.

You could also decide to set your NC clients to a non- split tunneling mode, which routes their connection to internet servers through the corporate network instead of directly through their local ISP. The advantages and disadvantages of each of those will be discussed in Chapter 5.

SSTP has a configuration that's somewhat similar to NC, although SSTP can be used by Windows 7 clients, which NC cannot. Many companies will have to set up both an NC option and an SSTP one to cover all their clients. SSTP is a little simpler to plan and configure—you simply enable it, and set a range of IP addresses for connecting clients. You can even set it to assign the IPs from DHCP in non-array scenarios, which is probably the most convenient for almost everybody.

Chapter 5, which discusses remote connectivity, will also discuss topics that are not categorized as VPN, but are still more related to connectivity than to simple application publishing. Of these technologies, it's worth noting File Access and Drive Mapping, as these pose additional requirements and considerations. File Access allows connecting clients to browse network shares, retrieve and save files, and more. Drive Mapping maps a server's share as a temporary network drive that allows the user to retrieve data from places like their own folder on the company's file server, or from generally available network shares. These two, however, require that the UAG server has access to the shares itself. This is not about file-level permissions, but more about ports and protocols. File Access and Drive Mapping use RPC, which may require special routing and IP configuration if an internal firewall or load balancer is in use.

Opting to employ several servers for high availability is a prudent step in most modern organizations, and thus, UAG includes built in support for arrays and NLB. Some organizations may still prefer using third party hardware, like F5 BigIP or Citrix Netscaler. The common scenario for load balancing would be to have several UAG servers running an identical configuration, and using a load balancer on the "external" side to distribute the load between the servers. Another scenario is when an organization has multiple internal servers, like a SharePoint server farm, and uses a Load-Balancer between it and UAG. Naturally, some organizations have both.

The most important consideration in a high availability scenario is the routing. With multiple virtual and physical IP addresses, the routing on all devices needs to be carefully planned, so that the data will have a clear path all the way from the client, through UAG, to the backend server and back. Stickiness also needs to be considered, as noted before (see Considerations for placing the server).

Another consideration for high availability is the keep-alive mechanism. Load balancers need to discern if the servers they are balancing are alive, and they usually do so by initiating some kind of contact with them. A popular way is by issuing a simple ICMP packet, like PING, but it's usually also possible to configure them to send an HTTP request to the server, or a TCP-SYN request. This needs to be planned carefully, so as to not have the keep-alive check impact the servers' performance, and also so that false-positives will not have bad consequences. We've seen many organizations configure their keep-alive to perform a check every second, which is a significant overkill, and caused the servers' logs to cycle so fast that the administrator was unable to track down real errors.

Another aspect of high availability is session failover, which, unfortunately, is not a part of UAGs functionality. NLB or third party load balancing will provide clients with a response even if one member server comes down, but the session management mechanism of UAG will not allow users with existing sessions to be moved over to another server. If a fail occurs, all users who are connected to the failed server will be redirected, upon their next request, to another array member, but they will be required to login again at that point. If they had SSTP, NC, RDP or SSL-VPN apps running, these sessions will be lost and have to be re-established as well. Some application-level protocols are designed to do this automatically, like RDP, but UAG will not do so on its own.

When considering the implementation of UAG, one must take into account which clients are usable with UAG. Various operating systems have different capabilities and limitations, and not all are supported. At the time of writing, UAG supports the following operating systems as clients:

As stated, not all systems support all functions. For example, using Network Connector is not possible with Windows 7. If your users are running both Windows 7 and Windows XP, the only way to allow all of them to VPN into the corporate network would be to implement both SSTP and NC. Depending on which OS is running, the proper one will be selected automatically.

When clients connect to various UAG services, they might need more than just a browser. For example, Endpoint Detection, Socket Forwarding and Endpoint Session Cleanup are special components that are installed on the client when they are required. These components may not be required, depending on which UAG features you are deploying. With most deployments however, they are necessary, so it's important to keep in mind that they can only be used with certain browsers and operating systems. With Windows and Internet Explorer, everything works nice and dandy. With Linux and Mac, a Java-based version of the client components does a similar job, and almost everything works (see link above). For mobile browsers, including Windows Mobile up to version 7 and Apple iPhone, the "Premium" portal is supported, but the phone cannot perform SSL tunneling, session cleanup or endpoint detection. Nokia phones only support the "Limited" portal. The "Premium" portal is specially designed for the mobile phone view on a small screen. It has fewer graphics, but still looks pretty darn good. The Limited portal is a text-only version that is usable even for phones with limited web capabilities.

When planning a UAG deployment, it's important to prepare and understand the limitations of client support to make sure the organization's primary target audience will have the right level of access. Discovering in mid-deployment that your number-one app is unusable for most of your users can be embarrassing. This is especially so if the target application or client are not explicitly on the list. Sometimes, even a minor version change can wreak havoc, as in the case of a certain well-known server application that introduced a major change to the way the application handles cookies, and so version 9.5.2 of the application worked perfectly through UAG, but version 9.5.3 failed miserably.

As mentioned before, when a user connects to the UAG portal for the first time, UAG client components are installed on their computer. It's important to keep in mind that the client components' installation process installs some Active-X components, and that is considered to be a risky situation. Don't worry—your user's computers aren't going to explode, but if the user is logged on as a non-administrative user, the Active-X registration will be denied and the client components installation will fail. In other words, make sure that when your users log on to the UAG portal for the first time, they will do so while logged on as local administrators, or at least run the browser with elevated privileges. Later, when just launching the portal again, the user no longer needs to be an administrator. If your organization or the user have customized the browser's security settings in some way, it's important to properly test the client component installation, to make sure the security configuration will not cause the computer to end up with a corrupt client installation. One other option that is at the administrator's side is the ability to manually install the client components using a stand-alone installer. The UAG server will have on its hard drive a set of Microsoft-installer files (with the extension of MSI) that can be used to install the client components fully or partially. In fact, if the organization's users take their computers to work regularly, one can even use Active Directory application deployment automation or a logon script to automatically and quietly perform this installation. You can read more about this in Chapter 7.

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.

At this point, UAG does not include the ability to remotely manage the server directly via the use of an MMC add-in, so to manage the server an administrator would have to access it physically via the console, or using Windows Remote-Desktop. Naturally, because the UAG is a gateway into your network, using RDP to connect to it can be risky. If UAG is hacked into, it might compromise your network more than just any regular workstation, so this should be planned carefully. It's also possible to enable remote desktop to the UAG server from outside, as a published application, although we still consider this to be a risky move for the same reasons. The fact of the matter is that most administrators want to have as many ways available to manage their servers, and we need to keep in mind that as we make things easier for ourselves, we usually make it easy for potential attackers as well, often increasing our exposure. For example, you might not allow external access to UAG, but you do publish your own workstation. An attacker breaks into your station this way, and can break into UAG from the "inside". Bottom line: to stay as secure as possible, be a little paranoid, and try to resist temptation to make everything possible remotely. We will discuss Remote Desktop publishing in more detail in Chapter 5.

In this chapter, we have talked about preparing your environment for the deployment of UAG, and addressed the considerations that are required to pave the path for a successful roll out. For many experienced IT administrators, UAG may seem to be just another server to install and squeeze into their already busy schedule, but UAG is a unique product in its abilities, and also in its requirements. Bringing up a server to host a simple web application can be accomplished quite easily, but that rarely ends there. Most organizations, when discovering how UAG empowers their home and mobile users to accomplish so much remotely, start piling on more and more applications and requirements, and at that point, any cracks in the initial design may show up. For example, setting up a SharePoint server may seem simple. After all, it's just a website, right? Not so fast. We soon discover (and will discuss this in Chapter 4) that the advanced code that makes SharePoint's content so dynamic and rich may also cause quite a headache if hostnames were not designed properly. In that case, an organization may find that it needs to reconfigure SharePoint's AAM settings, fiddle with DNS and in extreme conditions even reinstall the SharePoint server to allow it to be published perfectly. Will this happen to you? We hope not, so read Chapter 4 carefully (in fact, reading the entire book carefully won't hurt either) and don't rush into publishing the UAG portal before you have considered the various scenarios that can develop.

In the next chapter, we will learn how to install UAG with the various SKUs that are available. We will discuss the prerequisites in more detail and go over the installation procedure step-by-step, as well as tips and suggestions on avoiding the most common mistakes.