ISA Server 2004 Service Pack 2

BITS Caching

The Background Intelligent Transfer Service (BITS) helps you transfer large amounts of data without degrading network performance. It does this by transferring data in small chunks, utilizing unused bandwidth as it becomes available, and reassembling the data at the destination. ISA Server 2004 SP2 provides the caching mechanism for Microsoft Update data received through BITS.

  Note

Microsoft Update Caching

Updating the Microsoft Windows operating system and other Microsoft products on corporate computers from Microsoft Update can use a large portion of the available bandwidth. This problem is exacerbated in a low-bandwidth connection scenario, but can be an issue in higher bandwidth conditions as well. Updating Windows and other Microsoft software is an important security function, and should be expedited.

ISA Server 2004 SP2 provides the Microsoft Update caching feature that uses the SP2 BITS caching feature to efficiently cache the updates, so that the ISA Server cache can serve the requests. The update request can be completed over the Internet connection once, and then can be applied through the corporate network.

ISA Server Microsoft Update caching uses HTTP Range Requests to make the caching process even more efficient. Microsoft Update uses a mechanism that enables computers that use a specific version of Windows to request and receive only the ranges that contain the update information they need. Because ISA Server can cache those range requests, additional efficiency can result. For example, in a branch office where all of the client computers run Windows XP, only the Windows XP ranges of an update will be requested and cached. This results in quicker updates with lower bandwidth use and a more secure operating environment.

  Note

For more information about how Microsoft Update enables computers to request and receive only specific ranges, see Using Binary Delta Compression (BDC) Technology to Update Windows Operating Systems at the Microsoft Download Center.

HTTP Compression

HTTP compression reduces file size by using algorithms to eliminate redundant data. Most common Web-related file types can safely be compressed. HTTP compression uses the industry standard GZIP and Deflate algorithms, which are built into Windows 2000 Server and later operating systems and Internet Explorer version 4 and later versions. These algorithms compress static files, and optionally perform on-demand compression of dynamically generated responses before sending them over the network. These same algorithms are again used to decompress the static files and dynamic responses on an HTTP 1.1 supported client. A client that is configured to use HTTP 1.1 will request compressed content from a Web server. Web servers indicate in their responses whether they support compression.

  Note

In Internet Explorer, configure the use of HTTP 1.1 on the Advanced tab of Internet Options, by selecting Use HTTP 1.1 through proxy connections.

HTTP compression in ISA Server is a global HTTP policy setting. It applies to all HTTP traffic that passes through ISA Server to or from a specified network or network object, rather than to traffic handled by a specific rule. HTTP compression is provided by two Web filters:

Do not change the default priority and order settings of these filters.

HTTP compression also provides a range compression feature, which is described in Range Compression in this document.

  Note

HTTPS traffic is not compressed.

Range Compression

Range compression is the compression of a specific portion of Web content. Range compression is required to support legacy Portable Document Format (PDF) file readers that do not have built-in compression support.

Because Internet Information Services (IIS) does not support range compression, do not allow range compression on the network that includes a server running IIS. However, because ISA Server does support range compression, you may want to enable it between two ISA Server computers.

For example, if you have a Web server in the main office, you would disable range compression on the Internal network for the main office, but enable it on the External network for the main office and for the branch offices, so that range compression takes place between the offices.

  Note

The HTTP Request for Comment (RFC) does not explain how to handle the combination of compressed content with range headers (the HTTP headers used to request content ranges). IIS by default does not compress range requests because of the ambiguity of the RFC. There is a specific flag that, if it is set, causes IIS to return the range from the compressed file. However, IIS first compresses the whole file and then returns the requested range. To simulate this behavior, ISA Server should fetch the whole file, compress it, and then return the specific range. If the file is large and the range is at the end, this scenario may result in denial of service. To protect ISA Server from denial of service, ISA Server takes a different approach than IIS.

By default, ISA Server does not compress a range request. To support compression of range requests, ISA Server uses a new property per network element that indicates if range compression is allowed. If range compression is enabled, ISA Server requests range compression. When receiving a compressed range response, ISA Server always decompresses it. When returning a range response to the client that asked for compression, ISA Server compresses the data before transferring it to the client.

The following diagram describes the compression and range behavior in ISA Server 2004 SP2.

The following describes the compression and range behavior in ISA Server 2004 SP2:

•	The client requests range compression.
•	The configuration in the branch office does not allow the client to request compression. However, ISA Server in the branch office is configured to request compression and range compression and therefore sends a range compression request to the main office.
•	ISA Server in the main office gets the request. Because its client (ISA Server in the branch office) is allowed to request compression, ISA Server sends the request to the Web server. However, because ISA Server in the main office is configured to not allow requests for range compression, the response from the Web server contains the uncompressed range.
•	When ISA Server in the main office gets the response, it returns it to ISA Server in the branch office. Because the request from ISA Server in the branch office asked for compression, ISA Server in the main office compresses the data before transferring it to the branch office.
•	ISA Server in the branch office receives the response. The response is a compressed range response. ISA Server decompresses it, and transfers it uncompressed to the client in the branch office.

Range compression is not enabled through ISA Server Management. The administrator has to edit the configuration .xml file manually and set the CompressRange flag. The process for doing this is provided in Configuring Minimum Size Packet and Range Compression in this document.

  Note

Range responses are not stored in the ISA Server cache.

ISA Server Cache and Compression

ISA Server cache and compression work together to provide more efficient serving of compression requests. Note the following about how cache and compression work together:

To clear the cache, disable the cache through ISA Server Management, and then delete the cache storage file, such as Dir1.cdat (the default name of the ISA Server cache file). There is a cache file in the Urlcache folder on each drive that is configured for caching. After you delete the cache file, enable the cache in ISA Server Management.

There is also a sample script that describes how to clear the cache programmatically. For information, see the document Deleting Cache Contents at the Microsoft TechNet Web site.

Content Types and Compression

In general, some Web servers, when responding to a request, do not accurately provide the content type in the response header. For example, a response may include a Microsoft Office PowerPoint 2003 (.ppt) file, but the response header may indicate that the content is plain text. When an Internet Explorer client receives this type of response in compressed format, it cannot interpret the response, and the user will see meaningless characters on the monitor. If the response is received uncompressed, Internet Explorer can interpret it, and the user can open and view the content. However, if the client requests compression, and the Web server replies with uncompressed content, ISA Server compresses the content, and Internet Explorer cannot interpret it. In this case, the client must request uncompressed content (by changing the compression setting in the browser) to view it.

Packet Prioritization Using DiffServ

Packet prioritization is a global HTTP policy setting. It applies to all browser traffic that passes through ISA Server, rather than to traffic handled by a specific rule. The packet prioritization functionality is provided by the DiffServ Web filter, which scans the Uniform Resource Locator (URL) or domain and assigns the packet priority using DiffServ bits. You can create priorities in ISA Server whose DiffServ bits match those of the priorities on your corporate routers, thereby enabling the corporate routers to transmit the packets according to their priority.

This filter has a high priority, and is high in the ordered list of Web filters. This is because this filter has to be aware of the size of the request or response that is actually being sent, and therefore has to inspect the data at the point that it is sent or received by ISA Server.

Do not change the default priority and order settings of this filter.

  Note

Modified Features

Several ISA Server 2004 features have been modified in this service pack. The changes to these features are described in this topic.

Cache Array Routing Protocol

In ISA Server 2004 Enterprise Edition, the Cache Array Routing Protocol (CARP) mechanism used hash-based routing that depended on the URL to determine which array member would handle the request. CARP exceptions were the sites that you wanted to be handled by a single array member. The array member that was assigned to handle the request was selected based on the host name as it appeared in the host header. This has changed in Service Pack 2, to better complement Internet Explorer functionality and provide better control over the distribution of requests that produce heavy Web traffic.

In Service Pack 2, the CARP hash-based routing uses the host name to determine which array member handles the request. CARP therefore assigns all of the requests for a particular host, such as www.fabrikam.com, to a specific array member. This also maintains the context of the session, as the requests and responses are handled by a single array member. CARP exceptions are the sites that you want to be distributed to all array members, because they generate too much traffic to be handled by a single array member. For example, you may want all Microsoft update requests to be distributed, and not assigned to a single array member. You would therefore add the Microsoft Update site to the list of CARP exceptions.

Auto Detection

The behavior of client auto detection as configured on ISA Server has been modified in this service pack. With Service Pack 2, a request has to match both the IP address range and the server name or domain name provided on the Web browser tab to bypass the proxy.

Tracing

Service Pack 2 includes an error-level tracing mechanism that operates continually in the background. If necessary, the tracing information is available for Microsoft Product Support Services. The tracing mechanism does not collect personally identifiable information.

Tracing takes place in the background, and has a negligible affect on ISA Server performance. A 400 megabyte (MB) file (%windir%\debug\isalog.bin) is created by Service Pack 2 on each computer running ISA Server services, to contain the tracing information.

We recommend that you use the default settings for this feature. However, if you want to modify the tracing mechanism, you can do so through the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ISATrace. To change the size of the file used by tracing, change the value of CircularlLogSizeMB. To disable tracing, change the BootTracing value to 0. This does not delete the file, which has to be deleted manually. After registry changes, restart the computer so that the changes take effect. If you create the registry key before installing Service Pack 2, and set the BootTracing value to 0, the tracing file will not be added during the installation, and tracing will not be enabled.

Authentication Security

When you use HTTP-to-HTTP bridging, ISA Server will not allow traffic on the external HTTP port when the Web listener is configured to request Basic, forms-based, or Remote Authentication Dial-In User Service (RADIUS) authentication. This is a security-related change. These credentials should be encrypted, and not sent in clear text over HTTP.

Installation Procedure

Follow this procedure to install ISA Server 2004 SP2. This procedure assumes that you have ISA Server 2004 installed.

  Note

To install ISA Server 2004 SP2, follow these steps on each array member (for Enterprise Edition) or for each computer (for Standard Edition):

Creating the Microsoft Update Cache Rule

This procedure describes how to configure the Microsoft Update Cache Rule, which uses BITS caching to cache Microsoft Update data. It is assumed that you have already enabled the ISA Server cache, as described in Appendix A: Enabling the ISA Server Cache.

To create the Microsoft Update Cache Rule, follow these steps:

  Important

The Microsoft Update Cache Rule must remain first in the ordered list of cache rules.

Configuring HTTP Compression

To configure HTTP compression, follow these steps:

1.	In the console tree of ISA Server Management, click General: • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click General. • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click General.
2.	Under Global HTTP Policy Settings, click Define HTTP Compression Preferences to open the HTTP Compression properties.
3.	On the Settings tab, you can add the network entities for which HTTP compression will be requested from or allowed to. Click Add to open the Add Network Entities dialog box, select a network entity, and then click Add. Repeat to add additional network elements, and then click Close. Note that the list of network entities is ordered, so you can set a preference for compression between the network entities. Use the arrows on the right side of the property page to change the order of the network elements. Highlight each network element to select it and click Set Compression to set the compression properties.
4.	In the Set Compression dialog box, you can select: • Reply with compressed HTTP content. With this option enabled, ISA Server returns compressed content when a client request from this network element asks for compression. • Request compressed HTTP content from servers. With this option enabled, ISA Server asks for compressed content when making requests to this network element.
5.	After you configure the compression settings for the network element, click OK to close the Set Compression dialog box.
6.	On the Content Types tab, you can specify which content types will be compressed. You have the option of specifying the content types that will be excluded (all others will be included), or the ones that will be included (all others will be excluded). Then select specific content types to be excluded or included. The preceding figure is an example of a configuration in which only HTML documents will be compressed. You can create new content types in the Firewall Policy task pane, on the Toolbox tab, as described in ISA Server Help.   Note The following content types cannot be compressed because they are already compressed, or cannot be compressed because they are provided as a stream: • video • audio • application/x-tar • x-world/x-vrml • application/zip • application/x-gzip • application/x-zip-compressed • application/x-compress • application/x-compressed • application/x-spoon@@
7.	On the Content Inspection tab, you can select whether ISA Server Web filters will inspect the incoming compressed content. To do so, the compressed content will have to be decompressed. When decompressed, the content is stored in the cache as decompressed text. If ISA Server receives a request for the cached content, it recompresses it before sending, which increases response time.
8.	After you complete the configuration, click Apply in the ISA Server details pane to apply the changes.

SetCompConfig.vbs export filename

SetCompConfig.vbs import filename

<Compression ContentInspectionIsRequired="false"
  MinimumCompressionLength="36"
  MemAllocCompression="256">
 <NetworksElements>
   <NetworkElement
      Name="Internal"
   Type="Network"
   ClientCanAskForCompression="true"
   ServerShouldCompressResponse="false"
   CompressRange="false"
   StorageName="{4E32B556-0FAF-4A27-9111-085F679EDC9B}" />
  <NetworkElement
      Name="External"
   Type="Network"
   ClientCanAskForCompression="false"
   ServerShouldCompressResponse="true"
   CompressRange="true"
   StorageName="{F129EACF-778B-44FE-B339-5B752D7220A3}" />
  </NetworksElements>
 <ContentTypes CompressOnlyFollowingContentType="false">
   <ContentType
   Name="Images"
   StorageName="{2f203d1d-9ca0-414a-b036-fc9c585677ab}" />
   <ContentType
      Name="Video"
   StorageName="{7d3e566c-e96c-4cd4-b6aa-8181a8386c8e}" />
 </ContentTypes>
</Compression>

Configuring Packet Prioritization with DiffServ

Packet prioritization properties can be set through the HTTP DiffServ properties. To configure packet prioritization in the HTTP DiffServ properties, follow these steps:

1.	In the console tree of ISA Server Management, click General: • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click General. • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click General.
2.	Under Global HTTP Policy Settings, click Specify Diffserv Preferences to open the HTTP Diffserv properties.
3.	On the General tab, you can select whether Quality of Service bits will be set by ISA Server.
4.	On the Priorities tab, you can add and configure priorities and DiffServ values to be supported by ISA Server. You will assign these priorities to URLs and domains on other tabs of the HTTP Quality of Service properties. To add a priority, click Add to open the Add Priority dialog box. After you add the priorities, you can order them. If a packet is assigned to a specific priority based on a URL or domain, but cannot be assigned that priority based on packet size, it defaults to the next priority on the list. You can also select Allow special handling, so that headers will be handled with a different (typically, higher) priority than other parts of requests and responses.
5.	In the Add Priority dialog box, provide a priority name, and specify the DiffServ bits, which are also known as the Differentiated Services Code Point (DSCP), as a six-digit binary string. The binary string should match the binary string used by your router for a particular Quality of Service (QoS) setting. In SizeLimits, you can apply a size limit in bytes, so that the priority will only apply to requests or responses of a maximum size. A request or response that exceeds the specified maximum size will receive the next priority in the order. After you configure the priority, click OK to close the dialog box.
6.	On the URLs tab, you can apply priorities for URLs. To add a URL, click Add to open the Add URL Priority dialog box. Use an asterisk (wildcard character) at the end of the URL, unless you want to assign a priority only to a specific URL.   Note URL priorities listed on the URLs tab will be used by ISA Server to apply DiffServ bits for content that can be inspected by ISA Server (content that has not been tunneled). Content that has been tunneled over HTTPS cannot be inspected, and the URL cannot be known, so ISA Server will apply DiffServ bits to domains, which you add to the Domains tab. If you do not select a network to which the prioritization applies, your other settings will not be applied to any traffic. Only traffic to the networks you select on the Networks tab will be prioritized.
7.	In the Add URL Priority dialog box, provide a URL to which you want to apply a priority, select a priority from the drop-down list, and then click OK.
8.	After you add URLs, you can use the up and down arrows to order them. This allows you to apply priorities to specific URLs. If a more general URL precedes a specific URL, the specific URL will never be matched. For example, you may want to apply a high priority to www.contoso.com/news/*, and a lower priority to www.contoso.com/*. For the priorities to be applied correctly, www.contoso.com/news/* must be higher on the list. Otherwise, the /news/* request will get to the www.contoso.com/* entry and have the lower priority applied before the /news/* entry is reached.
9.	On the Domains tab, you can apply priorities for entire domains. When a domain is on the list, all of the URLs of that domain receive the priority set for the domain. To add a domain, click Add to open the Add Domain Priority dialog box.   Note URL priorities listed on the URLs tab will be used by ISA Server to apply DiffServ bits for content that can be inspected by ISA Server (content that has not been tunneled). Content that has been tunneled over HTTPS cannot be inspected, in which case ISA Server will apply DiffServ bits to domains, which you add to the Domains tab. If you do not select a network to which the prioritization applies, your other settings will not be applied to any traffic. Only traffic to the networks you select on the Networks tab will be prioritized.
10.	After you add domains, you can use the up and down arrows to order them. This allows you to apply priorities to specific domains. For example, you may want to apply a high priority to mail.contoso.com, and a lower priority to the rest of the domain, *.contoso.com. For the priorities to be applied correctly, mail.contoso.com must be higher on the list. Otherwise, the requests for mail.contoso.com will get to the *.contoso.com entry and have the lower priority applied before the mail entry is reached.
11.	In the Add Domain Priority dialog box, provide a domain to which you want to apply a priority, and select a priority from the drop-down list.
12.	On the Networks tab, select which networks’ packets will have prioritization assigned to them by enabling or disabling DiffServ for specific networks.   Note If you do not select a network to which the prioritization applies, your other settings will not be applied to any traffic. Only traffic to the networks you select on the Networks tab will be prioritized.
13.	After you complete the configuration, click Apply in the ISA Server details pane to apply the changes.