When you create a trunk, whether it is HTTP or HTTPS, several things occur that you might want to be aware of.

The activation process automatically creates a new website within IIS, the built-in Web Server that is included with every version of Windows Server since the dark ages (actually, Microsoft's first web server was developed in Scotland and released as a free add-on for Windows NT 3.51, but you know what we mean). If you inspect your server after adding a trunk to it, using the IIS Management console , you will discover that it has several websites on it. Before we go on, we need to make this clear once again—do not make any manual changes to the IIS configuration, unless specifically instructed to do so by a Microsoft support document or official representative. UAG can get seriously offended if you meddle in its romantic relationship with IIS, and blow up on you. In fact, even keeping the IIS management console open while a configuration is being activated is risky. Assuming you haven't created multiple trunks yet, you should find three existing websites:

The Default website is what we like to refer to as the internal site. It is bound to ports 443, 6001, and 6002, and does most of the administrative work for UAG in the background. The Internal Site also hosts the pages and resources that are used during the authentication process, as well as displaying error pages and the logoff mechanism. It also contains a virtual site that serves as the Portal homepage. The portal home includes the various pages and resources that are used to build the portal homepage with its applications.

The trunk website is named according to the name you selected when running the wizard earlier, and should contain three folders: InternalSite, Scripts, and WhlServerProxy.

The Web Monitor site is typically bound to port 50002, and will allow you to monitor the activity on the portal. It can show you how many users are connected and what they are doing, as well as show warnings about problems in the configuration. We will discuss the Web Monitor in more detail in Chapter 9.

If you click on your Trunk's website, and then click on the ISAPI Filter icon (it's under the IIS group of icons, around the middle), you will see an item named <your portal name>-WhlFilter. This item is where the magic really happens. It's linked to the WhlFilter.dll file, and that DLL (Dynamic Link Library) is how UAG does its work. The filter can interact with data that IIS receives and sends, and manipulate it, and that's how UAG can parse and react to URLs the user types or clicks, and modify the content delivered to them.

In addition to IIS, UAG also configures TMG with rules that will allow it to communicate with users from the outside, and with servers on the inside. At this point, you can already find over 20 access rules that have been created by UAG. Most of these rules will be named publishing rule::custom#<some number>, and you should be able to see that they allow traffic from "localhost" (meaning, from the UAG itself) to Internal. Thes e rules allow UAG to contact important internal servers, like the Active Directory servers. You will also find two rules, from All Network to PublishingRule::Server#001 and PublishingRule::Server#002. One of these rules is for port 80 (your redirect trunk) and another for 443 (your portal trunk).

Another interesting rule you will see is the last Deny rule, which is common to pretty much all firewalls. It basically says that anything not specifically allowed in any of the previous rules it will be denied.

In case we haven't said that enough times already, do not attempt to modify any of the existing rules or configurations in TMG, or add any others, unless specifically instructed by a Microsoft support document or official representative. This is even more dangerous than fiddling with IIS, because you might unknowingly create a rule that is too permissive, thereby exposing your server to hostile parties. Keep in mind that baddies are not only out there, on the web, but can also lurk inside your own company. We've heard of plenty of cases where a company's employee dug around various servers and collected information or implanted back-doors for a rainy day.

You might be asking yourself what to do in case you want to manage your server remotely from the comfort of your desk using Remote Desktop. By default, UAG does not configure TMG for this, although TMG will configure itself if you have used Remote Desktop to install the server. We discussed this in the previous chapter, in the section titled Post-install issues, so review it if you plan on using Remote Desktop to install or administer the server.