ISA Server's Caching Capabilities, Part 1

As its name implies, Microsoft Internet Security and Acceleration (ISA) Server 2000 is not only a firewall but also a service that accelerates Internet access by using an excellent caching functionality. The ISA Server cache stores frequently used URL objects (i.e., the content associated with URLs) in memory and in a cache file (or files) on ISA Server's hard disk. ISA Server caches requests for both forward proxying (i.e., for internal clients requesting external URL objects) and reverse proxying (i.e., external clients requesting internal published URL objects), but this two-article series covers only ISA Server's forward proxying capabilities. In Part 1, I explain ISA Server's caching behavior and show you how to configure cache routing rules and cache settings. In Part 2, I'll explain ISA Server's active caching feature, prepopulating the cache, advanced cache options, monitoring the cache, and scripts for working with the cache.

Setting the Cache Location and Size
You must install ISA Server in Cache mode or in Integrated mode to take advantage of the cache. During installation, the Microsoft Internet Security and Acceleration Server Setup dialog box prompts you to select drives for the cache. You can use only NTFS partitions. By default, ISA Server creates a 100MB cache on the largest NTFS partition when that partition has more than 150MB of space available, but the dialog box lets you change the cache size and location (the minimal cache size is 5MB). Microsoft recommends a cache of at least 100MB plus 0.5MB for each potential proxy client.

The best location for the cache is the fastest drive, and to maximize the performance of the cached drive, neither ISA Server nor the OS should be installed on it. For each 10GB of cache, ISA Server creates one file with the extension .cdat under the Urlcache directory. This file essentially is a database of all cached entries. After you've installed ISA Server, you perform all further cache configuration changes by using the Microsoft Management Console (MMC) ISA Management snap-in, which Figure 1 shows.

ISA Server's Caching Behavior
A combination of routing rules and cache configuration settings dictate ISA Server's caching behavior. For each outbound HTTP request that the proxy server allows through, the following takes place:

Routing Rules and Cache Configuration
Now that you know the basics of how ISA Server processes URL requests, let's look at how routing rules and cache configuration settings determine ISA Server's behavior. To create a routing rule, right-click Network ConfigurationRouting under your ISA Server in the left-hand pane of the ISA Management snap-in; select New, Rule; and follow the wizard prompts. To set the rule's caching behavior, right-click the rule in the right pane, click Properties to open the rule's Properties dialog box, and go to the Cache tab. Figure 2 shows the Cache tab for a routing rule named LEONBR-HM that governs requests sent to the LEONBR-HM destination. The tab offers three cache-search options that help determine the ISA Server caching behavior that I described in the previous section. The second option —Any version of the object; if none exists, retrieve the request using the route defined on the Action tab—returns any version of the URL object in the cache, whether valid or invalid.

Each routing rule also governs which content should be cached. Note that ISA Server ships with a default routing rule, which it uses if you don't set specific rules. This rule is similar to the second Cache content option that Figure 2 shows—If source and request headers indicate to cache, then the content will be cached. This option shifts the burden of cache content decision-making to the Web server, which uses caching headers to dictate caching behavior.

To configure the cache, right-click Cache Configuration in the left-hand pane of the ISA Management snap-in, select Properties, and go to the HTTP tab. This tab, which Figure 3 shows, controls caching of all outbound (and inbound) HTTP requests for this ISA Server. The Enable HTTP caching option controls whether ISA Server caches HTTP requests. When you select this check box, you can also specify how often ISA Server should update the URL objects in the cache.

The first three update-frequency options update URL objects according to fixed ISA Server policies. The fourth option—Set Time To Live (TTL) of object in cache to—lets you set your own update policy. I've entered 20 as the content age percentage. If a URL object was created or modified at 8:00 a.m., its content age at noon is 4 hours. Twenty percent of 4 hours is 48 minutes. Thus, if someone requests a URL object at noon, ISA Server will return the object until 12:48 p.m. After 12:48 p.m., ISA Server will send requests for that object to the Web server. A higher percentage means fewer cache updates. The No less than and No more than options let you set minimum and maximum TTL values.

The best update-frequency setting for your organization depends on what type of content users most frequently retrieve (and what type of Web content your organization publishes). You might choose the Less frequently (Reduced network traffic is more important) option if users request content with a lot of static pictures, logos, and backgrounds. You might choose the Frequently (Expire immediately) option if browsers in the organization frequently visit news sites whose content changes frequently. Your best bet is to try different settings and monitor cache performance with performance counters and cache reports, which I'll discuss in Part 2.

The routing rules and cache configuration settings let you determine to some extent how to cache URL objects, but as I mentioned earlier, Web server administrators exert the most control over how URLs are cached by using caching headers. ISA Server doesn't cache any responses that contain the Cache-Control: no-cache header, the Cache-Control: private header, the Cache-Control: no-store header, the Pragma: no-cache header, the WWW-Authenticate header, or the Set-Cookie header. ISA Server also doesn't cache any replies to requests that contain an authorization-type header (unless the replies also contain the Cache-Control: public header).

You can't directly control which URLs should be cached and which shouldn't. To exclude caching for a specific destination, you must create a destination set, configure a routing rule for the destination set, and disable caching for the routing rule. For information about creating a destination set, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/isa/proddocs/isadocs/m_p_h_createdestset.asp.

Testing the Cache
To see how Web server responses affect caching, you need a Web client that can show all HTTP response headers. Microsoft Internet Explorer (IE) doesn't show HTTP response headers, so I use httpdump.exe, which you can download from http://msdn.microsoft.com/downloads/samples/internet/networking/httpdump/default.asp?frame=true. This code sample sends an HTTP request and shows the entire response, including headers. Figure 4 shows my enterprise setup. Httpdump is running on my BETA-CLIENT machine. My first test, which Figure 5 shows, is to send a request for the hello.htm file (a static .html file that contains a welcome message) to the LEONBR-HM server. The command line specifies that I want to connect to LEONBR-HM, get the hello.htm object, and connect through the ISA-LEON proxy server, which listens on port 8080. (I've removed irrelevant headers and the body of the reply.)

The Expires header specifies when the hello.htm object in the cache will expire. The Date header identifies the time that the server received my request. As you can see, I've configured LEONBR-HM to let the object expire after 24 hours. The max-age value in the Cache-Control header expresses 24 hours in seconds. The Last-Modified header shows the date and time that hello.htm was last changed. In a minute, we'll look at the ISA Server cache and verify that ISA Server cached the http://leonb-hm/hello.htm object after it was requested.

A second test, which Figure 6 shows, requests the currenttime.asp page, which I wrote and which returns the current time and date. (The request is split across two lines for publication purposes, but you would enter it on one line.) Note that this request returns no Expires date or max-age value because the presence of the Cache-control: private header indicates that this content is dynamic content and shouldn't be cached.

Now, let's look at the ISA Server cache contents. The cachedir.exe tool in the supporttoolstroubleshooting directory of the ISA Server CD-ROM lets you view and manipulate the cache. If you run this tool from the CD-ROM, you'll get a missing DLL error. Instead, copy it to the program filesmicrosoft isa server directory of the ISA Server system and run it from there. Figure 7 shows the Cache Directory tool with hello.htm correctly cached. You can right-click the hello.htm entry in the right pane to see either the entire contents of the URL or just the headers. To obsolete (i.e., delete) the cache entry, right-click it in the left pane and select the Mark Obsolete option.

Notice that the Cache Directory tool shows no cache entry for currenttime.asp. As I mentioned earlier, the Web server has specified Cache-control: private in the response, so ISA Server doesn't cache the object. To force ISA Server to ignore this header, I could select the All content, including dynamic content, will be cached option on the LEONBR-HM routing rule, instead of the If source and request headers indicate to cache, then the content will be cached option that I selected on the Cache tab that Figure 2 shows.

As a third test, I modify the content of the hello.htm file on the Web server, then request the file again. Figure 8 shows this test (with only the relevant headers in the results). Because the LEONBR-HM routing rule uses one of the last two Search cache for options on the Cache tab, this second request for the hello.htm file returns an old version of the file with a generic warning that some of the information might be out of date. The routing rule causes ISA Server to display any version of the object, valid or expired, in the cache. In fact, if I deleted hello.htm from the server, I would still get the results that Figure 8 shows.

FTP and SSL
ISA Server also supports caching for content that a user has requested over an FTP connection. You use the FTP tab of the Cache Configuration Properties dialog box to enable FTP caching and to select a TTL for all FTP objects. The FTP protocol doesn't have any provision for sending auxiliary content information (such as the Expires response header) from the FTP server to the client. Thus, FTP servers can't override ISA Server's caching behavior. ISA Server caches an FTP object only when the request for it arrives from a proxy-aware client. IE is such a client. If a user types

FTP://ftp.microsoft.com

in the IE Address line, then ISA Server will cache the ftp.microsoft.com object. If a user types

ftp.exe

at a command prompt to start the ftp.exe utility shipped with Windows, the FTP request goes through ISA Server's Secure Network Address Translation (NAT) component or Firewall Client component and ISA Server doesn't cache it.

When IE establishes an SSL connection to a Web server through ISA Server, ISA Server uses SSL tunneling—that is, the proxy server doesn't decrypt SSL traffic; it just maintains a secure tunnel to the Web server. ISA Server doesn't cache SSL content sent over a tunneling connection. ISA Server can perform SSL bridging for incoming connections (when an external client connects to a published internal Web server) or when a downstream ISA Server machine connects to upstream ISA Server machines. Caching is enabled by default for bridging mode. For more information about ISA Server SSL tunneling and SSL bridging, see "SSL Bridging and Tunneling" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/isa/isafp1/sslbat.asp).

You're probably beginning to get a good idea of how ISA Server might help improve your users' Web browsing experience by displaying static content that it caches. In Part 2, I'll continue to explain the proxy server's features and operation.