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:
- ISA Server checks to determine whether the URL object is in the ISA Server cache. If the user made the request to an array of ISA Server machines, the machines use the Cache Array Routing Protocol (CARP) to determine which array member has the requested object. For more information about CARP, see "Configuring ISA Server Clients," September 2003, http://www.winnetmag.com, InstantDoc ID 39675.
- If the object is in the cache, ISA Server checks its validity. Invalid objects have an expired Time to Live (TTL). Web server administrators use caching headers to set the TTL value. In the absence of such headers, ISA Server administrators can set their own TTL value.
- If the object is valid, ISA Server returns it to the user. If the object is invalid, ISA Server checks its routing rules. If the rules let ISA Server return an invalid object, the server returns the object.
- If the rules don't let ISA Server return an invalid object, ISA Server checks to determine whether the Web server specified in the request is accessible. If the Web server isn't accessible, and if caching is configured to return expired objects, ISA Server returns the expired object. If the Web server is accessible, ISA Server sends the request to the Web server. Furthermore, if the object is cacheable (i.e., if the Web server hasn't specified a no-cache header) and if the ISA Server routing rules allow caching for a specific destination, ISA Server adds the URL to its cache.
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 Configuration\Routing 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.