Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the 'Ask the Author' form. You will also gain access to thousands of other FAQs at ITFAQnet.com.
Q: What is negative caching?
A: Negative caching is a term that is used to describe ISA Server's ability to continue to serve Web pages and Web objects from the ISA Server cache even after those objects' Time To Live (TTL) has expired. Normally, items are cached for a specific period of time before they have to be updated from the Web server where they originated. Without negative caching, the cached object will no longer be available after the TTL expires (until it is once again refreshed by updating the object from the originating Web server). By using negative caching, ISA Server can continue serving the expired object after its expiration.
Q: Why does Microsoft use CARP for ISA Server 2004 communication between caching servers, instead of one of the other popular protocols?
A: In a word, efficiency. CARP allows caching servers and Web Proxy clients to locate cached objects based on a hash. This eliminates unnecessary traffic and duplication of cached objects among caching servers.
Q: What does the event log item 14193, 'Cache was initialized with less memory cache than configured' mean?
A: You may see this event recorded when the ISA Server 2004 computer does not have enough free memory to allocate the percentage of free memory that you configured to be used for caching. If there is not enough free memory, a smaller amount of memory will be allocated for caching, but this event will be recorded in the event log.
Q: What happens when the cache fills up? Will this prevent new objects from being cached?
A: No. New objects will still be cached. If the cache is full, ISA Server 2004 will purge some objects from the cache to make room for new ones. URLs in the cache are removed according to a built-in logic so that the most recently used objects will be removed last.
Q: What does it mean if I see a message, when I start the ISA Server 2004 computer, that the cache did not initialize properly?
A: This message usually indicates that the ISA Server 2004 computer was not shut down properly. For example, if a power outage caused the ISA Server computer to turn off without going through the normal shutdown process, you might receive this message. Even if the computer did shut down normally, you could receive this message when an ISA Server service was stopped abruptly.
Q: I have a routing configuration specified in my content download job and a different routing configuration specified in Web chaining rules. Which one will be used?
A: The routing configuration that you have specified in the Web chaining rules will always take precedence over the one in the content download job. Thus, if you have a Web chaining rule that specifies that a request should be routed, it will be routed even though you specify in the content download job that it should not be routed. Web chaining rules let you route Web requests according to destination. With the Web chaining rule, you can choose to route a request from a Web Proxy client to a specific upstream ISA server, redirect it to a specified Web site, or retrieve the requested object directly from a specified destination.
Q: Does ISA Server 2004 perform active caching? If not, why not?
A: Active caching was supported by ISA Server 2000. The purpose of active caching was to allow ISA Server to automatically go out and get updated versions of popular Web objects before they were requested by clients. ISA would monitor the TTL of the most frequently requested objects, and then, when they were close to expiring, refresh them from the Internet, preventing the objects from expiring. This 'proactive' approach was intended to keep fresh copies of popular objects in the cache to reduce the time needed to refresh expired objects when a client requested them. However, Microsoft determined, after examining real world deployments of active caching, that it often did not benefit the overall network environment because of the extra bandwidth involved in automatically refreshing objects. Thus, the feature was discontinued in ISA Server 2004.
Q: How does ISA Server 2004's caching capability compare with that of other third-party competitors?
A: One of ISA Server 2004's primary advantages over most competitors is its combined firewall functionality and caching capability. Most popular firewalls offer caching only as an add-on module or through a separate product (at extra cost). The only major competitor that offers both is Blue Coat, with its SG appliances.
There are a number of third-party caching-only solutions. Some, such as Cisco's Content Engines (which are billed as 'router-integrated content delivery systems that include caching), include other functions, and different models range in price all the way from under a thousand dollars to over $70,000. Others, such as the open-source Squid, are free of charge, but difficult to configure, requiring that you have Linux/UNIX expertise and use the command line interface and configuration files similar to the old Windows .ini files. Another popular caching solution is Novell's Volera Excelerator, which runs on Linux and Windows. It, too, is relatively expensive, ranging from $3,595 to $44,995, with a mid-range Enterprise license (1GB) costing $12,945 at the time of this writing.
Caching solutions also differ in features support and caching protocols used. For example, Blue Coat (formerly CacheFlow) appliances support forward, reverse, hierarchical, and distributed caching, as does ISA Server. It also supports active caching and streaming-media caching. Client browsers are configured via a Proxy Autoconfiguration (PAC) file, and reverse caching is done using a layer 4/7 switch or router that supports WCCP. Blue Coat supports ICP, HTCP and WCCP. Novell Excelerator can use ICP, proprietary HTTP, and WCCP, and supports hierarchical, distributed, forward, and reverse caching. Streaming-media caching is supported with the optional Media Excelerator (at extra cost). Squid runs on Linux/UNIX and supports a wide variety of protocols: ICP, HTCP, CARP, Cache digests, and WCCP. It supports forward, reverse, hierarchical,and distributed caching. It does not support active caching or streaming media caching. Squid does not include high availability/load balancing, as do ISA Server, Blue Coat, and Novell.
ISA Server holds its own against third-party caching solutions in terms of the feature/cost tradeoff.