ISA Server 2006: Installing ISA 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration – Post Installation Tasks, Part 3

Installing ISA Server 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration
Post Installation Tasks Part 3


Have Questions about the article? 
Ask at: http://tinyurl.com/qqw8w

If you would like to read the other parts in this article series, then check them out at:

Configure Web Chaining Rules

Web Chaining Rules allow you to chain downstream ISA firewalls to upstream ISA firewalls, or even non-ISA firewall-based Web proxy servers. Web proxy chaining allows you to configure a hierarchical caching solution. In contrast, a multi-server ISA firewall array allows you to create a parallel caching solution. You can combine hierarchical and parallel caching solutions to significantly improve performance and reduce the total amount of bandwidth used on Internet links, WAN links, and even on the intranet.

The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. This has several advantages:

  • Content requested from all branch offices and the main office is cached on the main office ISA firewall array. This reduces overall Internet link bandwidth utilization
  • Content requested from each branch office is cached on the local ISA firewall array. This reduces bandwidth utilization on the branch office WAN and/or Internet link
  • Content hosted on main office Web servers can be dynamically cached or pre-loaded into the caches of branch offices. This allows this content to be available to branch offices even when the WAN or Internet link is down

With the increasing popularity of branch office deployments of the ISA firewall, you can expect to see even greater use of Web Chaining Rules.

To create a Web Chaining Rule, click the Networks node in the left pane of the ISA firewall console and then click the Web Chaining Rules tab in the middle pane. Then perform the following steps to create the Web Chaining Rule:

  1. Click the Tasks tab in the Task Pane and then click the Create New Web Chaining Rule link.


Figure 1

  1. On the Welcome to the New Web Chaining Rule Wizard page, enter a name for the rule in the Web chaining rule name text box. In this example we’ll chain the ISA firewall at a branch office to a ISA firewall Web caching array at the main office, so we’ll name the rule Branch to Main Array and click Next.


Figure 2

  1. On the Web Chaining Rule Destination page, click the Add button. In the Add Network Entities dialog box, select the destinations to which this Web Chaining Rule will apply. Since we want all requests for Web content regardless of where that Web content is located to be forwarded to the main office array, we’ll select the All Networks (and Local Host) entry in the Add Network Entities dialog box. Click Close in the Add Network Entities dialog box and then click Next.


Figure 3

  1. On the Request Action page, you configure how you want the Web requests to that particular destination routed by the ISA firewall. The default setting is to route the request directly to the destination Web site. However, in a Web Chaining configuration, you want the request forwarded to another Web proxy device. In this case, you would select the Redirect requests to the specified upstream server option. When you select this option, the next page of the wizard will ask you for details regarding the upstream Web proxy. Select this option and click Next.


Figure 4

  1. On the Primary Routing page, enter the name of the upstream ISA firewall array. You can leave the default ports in place if you haven’t changed them on the upstream array. In this example, the name resolves to one of the members of the main office array. Once the branch office ISA firewall receives the autoconfiguration script from the main office array, it will have a list of names of all the servers in the array and forward requests to the appropriate main office array member based on the CARP algorithm (CARP allows the branch office ISA firewall to perform client side routing of Web requests to the Web caching array member responsible for the URL).

    If the upstream array member requires credentials for Web access, click the Set Account button to enter the credentials the downstream array member should use to authenticate with the upstream. Click OK to save the account information and then select the authentication protocol from the Authentication drop down list. Since we always join ISA firewalls to the domain (an ISA firewall best practice), we can use integrated authentication. This prevents us from having to use SSL to secure the communications between the branch office ISA firewall and the main office array. Click Next on the Primary Routing page.


Figure 5

  1. On the Backup Action page you select how Web requests are routed when the upstream ISA firewall Web proxy isn’t available. In this example, we’ll assume that the branch office has its down Internet connection. Since the branch office has its own Internet connection, we can select the Retrieve requests directly from the specified destination option and connections will be forwarded directly to the Internet servers from the branch office ISA firewall, instead of routing them to the main office ISA firewall Web caching array. Click Next.


Figure 6

  1. Click Finish on the Completing the New Web Chaining Rule Wizard page.


Figure 7

I should note here that Web Chaining Rules give you a lot of flexibility in how requests from Web proxy clients are processed by the ISA firewall. The example above represents just one possible scenario out of many. In our upcoming book on the ISA Server 2006 firewall we’ll spend a lot of time going over the myriad of Web proxy chaining scenarios so that you are fully aware of your options. Of course, the book will also cover the many options available in configuring Web Chaining Rules that I didn’t have a chance to discuss in the above example.

Have Questions about the article? 
Ask at: http://tinyurl.com/qqw8w

Enable and Configure the Web Cache

Even in a unihomed Web proxy only ISA firewall configuration, the Web caching feature is not enabled by default. This reminds me of a very important distinction you should make: the difference between Web proxy and Web caching. Unfortunately, many people in our industry confuse the two terms and treat them synonymously. This is a grave error in the use of language and leads to many misunderstandings that could otherwise be avoided.

A Web proxy server is a machine that is able to proxy Web requests from Web proxy clients. The proxy component can authenticate users, perform URL rewrites, perform normalization on Web requests, bridge protocols, and much more. In contrast, a Web caching server does one thing: it caches Web content. In most cases, Web proxy servers also perform Web caching duties, although this is not required. By default, the ISA firewall is configured as a Web proxy server via its Web proxy filter hook into the ISA firewall’s Firewall Services. However, the ISA firewall is not a Web caching server by default. If you want Web caching, you’ll have to enable a cache drive.

Perform the following steps to enable the ISA firewall’s Web caching feature:

  1. In the ISA firewall console, click the Cache node that lies under the Configuration node in the left pane of the console. Click the Cache Drives tab in the middle pane, and then click the Properties command.


Figure 8

  1. In the server’s Properties dialog box, select the drive where you want to place the cache. Ideally, the cache drive will be on a separate spindle from the OS and logging drives. Thus, in an optimized configuration, the ISA firewall will have at least three drives: an OS drive with the ISA firewall software installed on it, a logging drive, where text or MSDE logging is performed, and a cache drive, where cached content is stored. Additional drives are required if you want to implement RAID for fault tolerance, but RAID is not required for the cache drive since the content is expendable. Make sure to check out our ISA Server 2006 book later this year for optimal disk and RAID configurations.

    After selecting the drive, enter the amount of disk space you want to dedicate to the on disk cache. Estimates vary for how much disk space you should dedicate to the cache, and for the most part, these estimates are SWAGs at best. In my experience, 5-10MB per user is reasonable, but a better estimate of optimal cache size should be based on your own deployment.

    For example, if you’re using the ISA firewall to only publish Web sites, you should have a disk cache large enough to cache all the content available on your published sites. For forward proxy scenarios, it’s best to limit the size of the cache based on the speed of your disks. You should also use information gained from the ISA firewall’s Web Cache performance counters. Click Set after adding the value and then click OK.




Figure 9

For a detailed account of how to optimize ISA firewall and Web caching behavior, check out Microsoft’s performance Best Practices document at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/bestpractices.mspx

Disable Unused Application and Web Filters

Application and Web Filters extend the ISA firewall’s core firewall feature set. They can do many things, such as securely manage complex protocols, perform stateful application layer inspection on application protocols, secure services from buffer overruns, add enhanced authentication support, and much more. However, Application and Web Filters can take up memory and processor resources that can be better used elsewhere.

For this reason, you should disable any filters you’re not using. In a unihomed ISA firewall configuration, there a many filters that you have no use for, since the unihomed Web proxy only ISA firewall supports only HTTP, HTTPS (SSL) and Web proxy tunneled FTP. You can turn off all Web filters that support and secure other protocols, since the ISA firewall won’t be servicing requests for those protocols.

To disable filters, click the Add ins node situated under the Configuration node in the left pane of the ISA firewall console. Click on the Application Filters tab and you’ll see something like what appears in the figure below. Right click the filter that you don’t need and then click Disable. The figure below has disabled all filters that are of no value in a unihomed Web proxy only configuration. You should disable the same filters on your unihomed Web proxy only ISA firewall.


Figure 10

Click the Web Filters tab in the middle pane of the ISA firewall console. Web Filters are essentially ISAPI plug-ins to the ISA firewall’s Web proxy filter. They’re “filters bound to a filter”. Notice that the default configuration is to enable all filters except for the DiffServ filter. You should review each of these filters to see if they’ll be in use in your organization. If you identify one or more filters that you definitely won’t be using (for example, the RADIUS authentication filter), then disable them.


Figure 11

Configure Compression Preferences

The ISA firewall can be configured to support requests for compressed content. The feature was first introduced with ISA 2004 SP2. You need to be careful with compression, because the ISA firewall doesn’t support all methods of compression and this feature has a tendency to generate a large number of errors related to alternate compression methods. However, one scenario where you’ll find compression especially useful is in a branch office scenario, where the branch office ISA firewalls are in a Web proxy chaining configuration with upstream ISA firewalls in a Web caching array.

To access the HTTP compression preferences, click the General node under the Configuration node in the left pane of the ISA firewall console. In the middle pane of the console, click the Define HTTP Compression Preferences link. This will bring up the General tab as seen in the figure below.

The Enable HTTP compression option is enabled by default. If you want to disable support for HTTP compression, then remove the checkmark from that checkbox.


Figure 12

Click the Return Compressed Data tab in the HTTP Compression dialog box. Here you configure the ISA firewall to compress HTTP responses when requested by client from network elements you determine here. For example, if you want the clients to be able to request compressed content from Internet hosts, then you could configure the Internal ISA firewall Network here. Note you also have the options to create exceptions and set what Content Types will be compressed.

It’s important to note once again, that when Microsoft developed support for compressed content, what they had in mind was a branch office scenario where the branch office ISA firewall requests compressed content from a main office ISA firewall array.


Figure 13

Click the Request Compressed Data tab in the HTTP Compression dialog box. Here you configure what network elements request compressed HTTP content when requests are sent to these network elements. For example, if you want the ISA firewall to request compressed content from Internet Web servers, then you would add the default External ISA firewall Network to this list. Once again, things are a little more complex than this and this functionality was designed for branch office/main office Web proxy chaining configuration.


Figure 14

I realize that I’ve been a little obtuse regarding how to configure compression support for the ISA firewall. The issue is potentially complex and there are a number of possible scenarios, each requiring a custom configuration. For more information on HTTP compression support for ISA firewalls, check out the ISA 2004 SP2 White Paper at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/sp2.mspx

Have Questions about the article? 
Ask at: http://tinyurl.com/qqw8w

Summary

In this article we continued our trek through post-installation tasks for unihomed Web proxy only ISA firewalls configured in a single server array configuration. We’re almost done! In the next article, part 4 of the series, we’ll complete our post installation tasks and then move on to more interesting topics, such as publishing front-end Exchange Server Web farms!

If you would like to read the other parts in this article series, then check them out at:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top