Fix IIS Compression Problems: A Troubleshooting Guide for IIS 6 and 7.x

Table of Contents

Web content compression is a critical component for optimizing website performance, reducing bandwidth consumption, and enhancing the user experience. By compressing static and dynamic content, Internet Information Services (IIS) significantly shrinks the size of data transferred over the network, leading to faster load times for visitors. However, configuring and maintaining IIS compression can sometimes be challenging, leading to scenarios where content that should be compressed is served uncompressed. This guide provides an in-depth, step-by-step approach to troubleshooting common IIS compression issues in both IIS 6 and IIS 7.x environments.

Understanding IIS Compression Fundamentals¶

At its core, web compression, primarily using Gzip and Deflate algorithms, involves reducing the size of files sent from the web server to the client browser. This process is transparent to the user, but its benefits are profound, especially for websites with large text-based content like HTML, CSS, JavaScript, and XML. IIS supports both static and dynamic compression. Static compression pre-compresses files that do not change frequently (e.g., images, PDFs, static HTML pages), while dynamic compression compresses content generated on-the-fly by server-side scripts (e.g., ASP, ASP.NET pages). Understanding these distinctions is crucial for effective troubleshooting.

Initial Checks and Prerequisites¶

Before diving into specific troubleshooting steps, ensure that IIS is correctly installed and functioning on your server. Verify that the IIS Admin Service and World Wide Web Publishing Service are running. Confirm that you have administrative privileges on the server, as many of these troubleshooting steps require modifying system-level configurations and IIS metadata. Basic network connectivity tests to your website should also confirm that IIS is serving content, even if it’s uncompressed.

Step-by-Step Troubleshooting Guide¶

This section outlines a systematic approach to diagnose and resolve common IIS compression issues.

1. Enabling Compression in IIS Manager¶

The foundational step for IIS compression is to ensure it is explicitly enabled within the IIS Manager interface. If compression is not activated at the server or site level, no amount of advanced configuration will lead to compressed content.

For IIS 6, navigate to the IIS Manager. Right-click on the Web Sites node, select Properties, and then proceed to the Services tab. Within this tab, you will find checkboxes labeled “Compress static files” and “Compress dynamic files.” Ensure both are selected according to your compression requirements. Enabling these options at the global level sets the default behavior for all websites hosted on the server.

In IIS 7.x (which includes IIS 7.0, 7.5, and later), the process is slightly different due to the redesigned user interface and configuration system. Open IIS Manager, select the server name in the Connections pane, and then double-click the Compression icon under the Features View. Here, you will find options to “Enable static compression” and “Enable dynamic compression.” Check the appropriate boxes and click “Apply” in the Actions pane. This interface provides a more granular control over compression settings.

Properly enabling compression through the IIS Manager is the first and most fundamental step. Without this initial configuration, IIS will simply not attempt to compress any content, regardless of other settings or file types. This initial check often resolves basic “compression not working” complaints.

2. Configuring the Compression Folder and Permissions¶

IIS requires a dedicated temporary directory to store compressed files before serving them to clients. This folder’s location and, critically, its permissions are vital for compression to function correctly. If IIS cannot write to or read from this directory, compression will fail.

By default, in IIS 6, this folder is located at %windir%\IIS Temporary Compressed Files. For IIS 7.x, the default path is %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files. It is possible to configure a different location, but regardless of the path, the necessary permissions must be granted.

The IIS_WPG group (for IIS 6) or the IIS_IURS group (for IIS 7) must have Full Control permissions on this temporary compression folder. These groups represent the identities under which IIS worker processes run, and they need comprehensive access to manage compressed files. Without full control, IIS will encounter access denied errors when attempting to create, store, or retrieve compressed versions of your web content. Tools like Process Monitor from Sysinternals can be invaluable for diagnosing permission-related issues, as they can log file access failures that might otherwise be obscure. Confirming these permissions is a common, yet often overlooked, troubleshooting step.

3. Verifying Metabase Configuration (IIS 6 Focus)¶

In IIS 6, the Metabase.xml file serves as the central repository for all IIS configuration settings. Compression settings are stored within this critical XML file, and an incorrect or incomplete configuration here can prevent compression from working. Understanding the structure of these settings is key to manual verification and troubleshooting.

There are three primary metabase nodes specifically dedicated to compression configuration:
* w3svc/filters/compression/parameters
* w3svc/filters/compression/gzip
* w3svc/filters/compression/deflate

The /parameters node is mandatory for compression to be enabled at all. This node contains general compression settings applicable to both Gzip and Deflate schemes. Following the configuration of the parameters node, you can then enable either the /gzip or /deflate node, or both, depending on the compression algorithms you wish to utilize. For instance, configuring only the gzip or deflate nodes without the parameters node will not activate compression. Similarly, if only the parameters and gzip nodes are configured, only Gzip compression will be active. To enable both Gzip and Deflate compression schemes, all three nodes must be properly configured.

This hierarchical and interdependent configuration means that simply checking one node is insufficient. A complete verification involves examining all relevant nodes to ensure they are present and correctly configured according to your compression strategy.

mermaid graph TD A[w3svc] --> B[filters]; B --> C[compression]; C --> D[parameters]; C --> E[gzip]; C --> F[deflate]; style A fill:#f9f,stroke:#333,stroke-width:2px; style B fill:#f9f,stroke:#333,stroke-width:2px; style C fill:#f9f,stroke:#333,stroke-width:2px; style D fill:#bbf,stroke:#333,stroke-width:2px; style E fill:#bfb,stroke:#333,stroke-width:2px; style F fill:#bfb,stroke:#333,stroke-width:2px; linkStyle 0,1,2,3,4,5 stroke-width:2px,fill:none,stroke:black;


This diagram illustrates the hierarchical relationship of the Metabase nodes for IIS compression. The parameters node is central, acting as the foundation for enabling the gzip and deflate compression schemes.

4. Checking Metabase Permissions for IIS 6¶

Beyond the configuration values themselves, the permissions on the IIS 6 Metabase are paramount. If the identity under which IIS operates lacks the necessary access rights to the metabase, it will be unable to read or write its own configuration, leading to a failure in initializing compression.

By default, the IIS_WPG group possesses Read, Unsecure Read, Enumerate Keys, and Write permissions to the /LM/W3SVC/Filters metabase key. These permissions are crucial for IIS to properly manage and execute its compression functionalities. Any deviation from these default permissions, whether due to an accidental change, a security hardening script, or a misconfigured update, can render compression inoperable. When permissions are insufficient, IIS cannot properly load the compression filter.

To verify and modify IIS 6 metabase Access Control Lists (ACLs), you can utilize the metaacl.vbs script. This tool allows administrators to inspect and adjust permissions on specific metabase paths, ensuring that the IIS_WPG group has the required access. A common symptom of metabase permission issues, particularly when the application pool identity or the IIS_WPG group lacks Read and Write access to the W3SVC or Filters keys, is the logging of a COMPRESSION_DISABLED failure condition within an Enterprise Tracing for Windows (ETW) trace.

An ETW trace, if captured, would typically show an entry similar to this:

IISCompression: STATIC_COMPRESSION_NOT_SUCCESS - IIS has been unsuccessful doing static compression
Reason: COMPRESSION_DISABLED

This specific trace message is a strong indicator that the root cause of the compression failure lies with insufficient metabase permissions, preventing IIS from even attempting to apply compression. Remedying these permissions is a critical step in restoring compression functionality.

5. Confirming Dynamic and Static Compression Settings¶

Even if the overarching compression feature is enabled, IIS provides granular control over whether static or dynamic compression is applied. This distinction is managed through specific configuration keys within the metabase nodes (/parameters, /gzip, and /deflate). If these keys are not set correctly, IIS will not compress content of that type.

To enable static compression for unchanging file types such as .txt, .html, or .xml, the HcDoStaticCompression key must be set to 1 (or TRUE). Conversely, for dynamic content generated by server-side scripts like .asp, .aspx, .asmx, or even executables (.exe), the HcDoDynamicCompression key needs to be set to 1 (or TRUE). These settings dictate IIS’s behavior for each content category.

For IIS 6, you can modify these settings using the adsutil.vbs script from the command line. For example, to enable dynamic compression at the /parameters node, you would execute the following command:

cscript.exe adsutil.vbs SET w3svc/filters/compression/parameters/HcDoDynamicCompression TRUE

The successful execution of this command will typically return an output confirming the change:

HcDoDynamicCompression          : (BOOLEAN) True

In IIS 7.x, these settings are managed within the web.config file, usually at the site or application level, within the <system.webServer> section. The urlCompression element handles both static and dynamic compression:

<system.webServer>
  <urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>

Ensuring these specific flags are set to TRUE for the desired compression type is crucial. If, for instance, HcDoDynamicCompression is FALSE, ASP.NET pages will never be compressed, even if the general compression feature is enabled in IIS Manager.

6. Managing File Type Extensions for Compression¶

After enabling static and/or dynamic compression, the next crucial step is to define which specific file types or MIME types should be compressed. IIS employs distinct lists for static and dynamic content, and if a particular file extension is not included in the appropriate list, it will bypass compression.

For static file compression (e.g., .html, .txt, .xml), you must add the relevant file extensions to the HcFileExtensions property. By default, IIS includes common types like .htm, .html, and .txt. If you wish to compress other static file types, such as .css or .js (which are often treated as static), they must be explicitly added to this property.

For dynamic compression (e.g., .asp, .aspx, .asmx, .dll, .exe), extensions are added to the HcScriptFileExtensions property. Default dynamic types often include .asp, .dll, and .exe. If your application uses other dynamic content types, such as .aspx pages or specific web service endpoints, they need to be added to this list.

In IIS 6, adsutil.vbs is used to manage these extension lists.
To set static file extensions for Gzip compression:

adsutil.vbs SET w3svc/filters/compression/gzip/HcFileExtensions "htm" "html" "txt"

You can retrieve the current list to verify your changes:

adsutil.vbs GET w3svc/filters/compression/gzip/HcFileExtensions

The output will show the configured extensions:

HcFileExtensions : (LIST)  (3 Items)
"htm"
"html"
"txt"

For dynamic file extensions:

adsutil.vbs SET w3svc/filters/compression/gzip/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
adsutil.vbs get w3svc/filters/compression/gzip/HcScriptFileExtensions

Expected output:

HcFileExtensions : (LIST)  (4 Items)
"asp"
"dll"
"exe"
"aspx"

For IIS 7.x, these configurations are handled within the <httpCompression> section of your web.config file, using <staticTypes> and <dynamicTypes> elements with mimeType attributes.

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" minFileSizeForComp="1000">
  <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
  <staticTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/x-javascript" enabled="true" />
      <add mimeType="application/atom+xml" enabled="true" />
      <add mimeType="application/xaml+xml" enabled="true" />
      <add mimeType="*/*" enabled="false" />
  </staticTypes>
  <dynamicTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/x-javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
  </dynamicTypes>
</httpCompression>
<system.web.extensions>
  <scripting>
      <scriptResourceHandler enableCompression="false" />
  </scripting>
</system.web.extensions>

A crucial note for IIS 6 adsutil.vbs usage: Be extremely cautious with the syntax when setting HcFileExtensions or HcScriptFileExtensions. Any trailing spaces, unnecessary quotes, or carriage returns can corrupt the property, leading to misconfiguration that adsutil.vbs might not report as an error. It is highly recommended to manually type these values rather than copying and pasting them, especially into a command prompt or directly into metabase.xml (direct metabase editing is generally discouraged unless absolutely necessary and you understand the implications).

7. Addressing Overridden Compression Settings¶

IIS employs a hierarchical configuration system, where settings can be defined at various levels: the master level (server), website level, application level, and even directory level. A common pitfall in IIS compression troubleshooting is assuming a global setting applies everywhere, when in fact, a more specific, lower-level configuration is overriding it.

For example, you might have correctly enabled HcDoDynamicCompression at the w3svc/filters/compression (master) level, intending for all dynamic content on the server to be compressed. However, if a specific website (e.g., the Default Web Site) or an application within that site has a DoDynamicCompression setting explicitly set to FALSE, dynamic compression will not occur for requests targeting that particular site or application. The more specific setting always takes precedence.

To troubleshoot this, you need to systematically examine the compression settings at each level relevant to the problematic content. Use IIS Manager to inspect the properties of the server, then the specific website, and finally the application or virtual directory in question. In IIS 6, adsutil.vbs can be used with specific paths (e.g., w3svc/1/Root/WebApp for a website/application) to retrieve settings and identify where an override might be occurring. This layered configuration is powerful but requires careful attention to avoid unintended overrides.

8. Excluding Compression Directory from Anti-Virus Scans¶

One of the less obvious but impactful issues preventing IIS compression from working correctly involves antivirus software. When compression is enabled, IIS pre-compresses static files and stores them in its temporary compression directory. If an antivirus program running on the IIS server actively scans this directory, it can interfere with IIS’s operations.

The most common symptom of this conflict is IIS returning a 0-byte file instead of the expected compressed (or even uncompressed) content. This typically occurs when HTTP Static Compression is enabled, as the antivirus software might lock, quarantine, or corrupt the compressed file as IIS attempts to serve it. The antivirus program’s real-time scanning engine might detect the rapidly changing or newly created files in the compression directory as suspicious, leading to unintended file manipulation.

The resolution for this issue is straightforward: you must exclude the IIS temporary compression directory (e.g., %windir%\IIS Temporary Compressed Files or %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files) from your antivirus software’s real-time scan list. This ensures that the antivirus program does not interfere with IIS’s ability to manage its compressed files, allowing content to be served correctly.

9. URL Parameters Interfering with Compression¶

In rare scenarios, the structure of a requested URL, particularly when it includes slashes as part of parameters passed to an executing DLL or custom handler, can disrupt IIS’s compression process. IIS parses URLs to determine how to route and process requests, and an ambiguously formatted URL might confuse the compression module.

This specific issue tends to arise with older or highly customized web applications that employ non-standard URL rewriting or parameter passing mechanisms. For instance, if a URL path segment is intended as a parameter but contains characters typically reserved for directory delimiters (like /), IIS might misinterpret the resource being requested or the content type, leading to compression bypass.

Troubleshooting this requires careful examination of the problematic URLs and the corresponding application’s URL handling logic. It may involve adjusting URL rewriting rules, modifying application code to pass parameters differently, or implementing custom handlers that explicitly manage the content-type and compression headers. While less common, this issue highlights the sensitivity of IIS’s internal processing to URL structure.

10. ISAPI Filters and Header Modifications¶

ISAPI (Internet Server Application Programming Interface) filters are powerful components that can intercept and modify HTTP requests and responses within IIS. While they offer immense flexibility, a misbehaving or improperly designed ISAPI filter can inadvertently break compression by incorrectly handling HTTP headers or the entity body during the response phase.

The core problem arises when an ISAPI filter performs a “send” operation but fails to provide the complete and correctly formatted set of HTTP headers along with the entity body to HTTP_COMPRESSION::DoDynamicCompression. IIS’s compression module expects all relevant data to be presented in a specific manner to effectively apply compression. If a third-party or custom ISAPI filter places headers in the function meant for the entity body, or vice-versa, or omits essential headers entirely, DoDynamicCompression cannot process the response correctly.

This misplacement or omission of data can cause various IIS functionalities to fail, including SF_NOTIFY_SEND_RESPONSE notifications, AddResponseHeaders operations, and, critically, dynamic compression. The resolution lies in ensuring that any custom or third-party ISAPI filters strictly adhere to the IIS API guidelines for handling HTTP headers and response bodies. Developers of such filters must ensure that headers and the entity are provided in their respective, correct locations within the data stream.

11. Non-200 HTTP Status Codes¶

A fundamental rule for IIS 6 and IIS 7.x compression is that by default, only responses with an HTTP 200 (OK) status code will be compressed. This means that if your server responds with any other HTTP status code—such as 301 (Moved Permanently), 302 (Found), 404 (Not Found), 500 (Internal Server Error), or any other informational, redirection, client error, or server error code—IIS will not apply compression to the response body.

This default behavior is intentional, as compression is primarily designed for the successful delivery of content. Error pages or redirection responses are typically small and do not benefit significantly from compression; furthermore, compressing them could sometimes obscure debugging information or interfere with client-side handling of redirects.

If there is a very specific business requirement to compress content delivered with non-200 status codes (which is an advanced and generally discouraged practice), you would need to implement a custom HTTPModule. This module would intercept the response, manually apply compression, and then modify the response headers accordingly. However, for most use cases, understanding that IIS only compresses HTTP 200 responses is key to diagnosing why certain pages might not be compressed.

12. Via Header Presence and Proxy Behavior¶

The HTTP Via header is an optional header added by proxies or gateways to indicate the intermediate protocols and recipients between the user agent and the server. Its presence in a request can impact IIS compression behavior due to historical issues with proxy servers.

Many older or non-compliant proxy servers do not correctly handle compressed data. They might either fail to decompress the content before forwarding it to the client, or worse, provide compressed data to clients that do not support compression, leading to broken content. To mitigate these compatibility issues, IIS has a built-in safety mechanism: by default, it will not send compressed responses when the incoming request contains a Via header. This default behavior is controlled by the HcNoCompressionForProxies metabase key, which is set to FALSE by default.

If your network architecture includes proxies that you trust to handle compression correctly, and you wish to enable compression for requests coming through them, you can override this default behavior. This is done by setting the HcNoCompressionForProxies metabase key to TRUE. This adjustment signals to IIS that it should proceed with compression even when a Via header is present, assuming the proxy will correctly manage the compressed content.

13. Document Footers and Static Compression Failure¶

Static compression in IIS relies on the integrity and immutability of the files being served. When IIS pre-compresses a static file, it expects that file to remain unchanged. However, some server-side components or network devices, such as firewalls, security scanners, or custom HTTP modules, might append “document footers” or other content to the end of static files after IIS has processed them for compression but before they are sent to the client.

This post-processing modification can cause static compression to fail. The integrity check performed by IIS or the client’s de-compression logic might detect a mismatch between the expected compressed content and the actual content received, which has been subtly altered. This issue is specific to static files because they are pre-compressed based on their exact original content. Dynamic content, being generated per request, handles such modifications differently.

Troubleshooting this involves identifying any software or hardware that might be modifying the HTTP response body after it leaves IIS but before it reaches the client. This could include third-party security products, network appliances, or even custom code in IIS modules designed to inject content. Disabling or reconfiguring these components to exclude static files from their modification scope is typically the solution.

14. Wildcard Application Mappings and Static Compression¶

IIS distinguishes between static and dynamic content based on file extensions and application mappings. Static content is typically served directly by the IIS static file handler, while dynamic content is processed by ISAPI extensions or managed modules (like ASP.NET). A common misconfiguration, particularly in IIS 6, involves the use of wildcard application mappings.

If a wildcard application mapping (e.g., mapping * to an ISAPI filter or handler) is installed at the root level of your IIS server or a specific website, it can cause IIS to treat all requests, including those for static files like .html or .txt, as dynamic requests. This reclassification occurs because the wildcard mapping tells IIS to pass all requests through a specific dynamic handler, bypassing the efficient static file handler.

The consequence is that while your .txt files are inherently static, they are now processed as if they were dynamic. If these “dynamically treated” .txt files are not explicitly listed in your HcScriptFileExtensions for dynamic compression (which is often the case, as .txt is expected to be static), they will not be compressed. This can be a very confusing scenario where general static compression appears to be enabled, but specific static file types are not being compressed. Reviewing your application mappings in IIS Manager is crucial to identify and correct any unintended wildcard mappings.

15. Accept-Encoding: identity Field and RFC2616 Compliance¶

The Accept-Encoding HTTP header is sent by a client to indicate what content encodings (like gzip, deflate, or identity) it understands and prefers in the response. The identity encoding explicitly signifies that the client prefers no transformation or compression. IIS, adhering to RFC2616 (the HTTP/1.1 specification), interprets this header carefully.

According to RFC2616, if an Accept-Encoding field is present in a request, and the server cannot send a response that is acceptable according to that header, the server should respond with a 406 (Not Acceptable) status code. However, if no Accept-Encoding field is present, the server can assume the client accepts any content coding. In this latter case, if “identity” (no compression) is one of the available content codes, the server might default to “identity” unless it has specific information that a different content-code would be more meaningful to the client.

The key takeaway for troubleshooting is to examine the client’s Accept-Encoding header in the request. If a client explicitly sends Accept-Encoding: identity or if it lists compression schemes it doesn’t support, IIS will respect this preference and send uncompressed content. This is not a server-side compression failure but rather a client-mandated behavior. Network diagnostic tools can help capture these request headers for analysis.

16. Advanced Troubleshooting with ETW Trace¶

For complex IIS compression issues that defy simpler diagnosis, Event Tracing for Windows (ETW) provides an invaluable, deep-level insight into IIS operations. ETW allows you to capture detailed logs of how IIS processes HTTP requests, including the exact reasons why compression might fail.

Here’s a step-by-step guide to using ETW trace for IIS compression issues:

1. Create an IIS Providers File: Create a text file named IISProviders.txt (or any name you prefer) and add the following content to it. This specifies the IIS WWW Server provider for tracing. The 0xFFFFFFFE represents tracing for all events, and 5 indicates a verbose logging level.
   

   "IIS: WWW Server" 0xFFFFFFFE 5
   

2. Start the Trace: Open an elevated command prompt and execute the following command to begin capturing trace data.
   

   logman start trace compressionTrace -pf IISProviders.txt -ets
   

   
   This command initiates a new trace session named compressionTrace, using the providers defined in IISProviders.txt.

3. Reproduce the Problem: While the trace is running, attempt to access the web content that is failing to compress. Ensure you perform the actions that trigger the compression issue you’re investigating.

4. Stop the Trace: Once the problem has been reproduced, stop the trace session using this command:
   

   logman stop trace compressionTrace -ets
   

   
   This command will generate a binary trace file, typically named compressionTrace.etl, in your current directory.

5. Convert the Trace to a Text File: The binary .etl file is not human-readable. Use tracerpt to convert it into a more accessible text format.
   

   tracerpt compressionTrace.etl
   

   
   This command processes the .etl file and produces two files in the directory where tracerpt was executed:
   • Summary.txt: Contains general details about the trace session, including the providers used and overall statistics.
   • DumpFile.csv: Contains the actual trace data in a comma-separated value (CSV) format, which can be opened with a text editor or spreadsheet program.

6. Analyze the Trace File: Open DumpFile.csv and search for keywords related to compression failure, such as COMPRESSION_NOT_SUCCESS. You’ll find entries that provide specific reasons for the failure.
   Here’s an example of an error message you might find:
   

   IISCompression, STATIC_COMPRESSION_NOT_SUCCESS, 0x000008B0, 129744354075770195, 0, 0, {00000000-0000-0000-0700-0060000000bd}, "NO_MATCHING_SCHEME", 0, 0
   

   
   In this example, NO_MATCHING_SCHEME indicates that IIS could not find a suitable compression scheme for the requested file type or that the client’s Accept-Encoding header did not match any available compression methods.

ETW traces are powerful because they provide granular details about the internal decision-making process of IIS, giving you the precise reason for a compression failure that might not be evident from simpler checks.

Common IIS Compression Error Codes (ETW Trace)¶

When analyzing your DumpFile.csv from an ETW trace, you might encounter various error codes providing insight into why compression failed. Here’s a table of some common codes and their interpretations:

Error Code	Description
COMPRESSION_DISABLED	Compression is not enabled at the required configuration level, or IIS lacks necessary permissions to initialize it.
NO_MATCHING_SCHEME	No compression scheme (Gzip/Deflate) is enabled or configured for the specific file type/MIME type requested, or the client’s Accept-Encoding header doesn’t align with available schemes.
FILE_TOO_SMALL	The file size is below the minimum threshold configured for compression. IIS often has a minFileSizeForComp setting to prevent compressing very small files where the overhead might outweigh the benefits.
NO_COMPRESSION_FOR_PROXIES	The request includes a Via header, indicating it came through a proxy, and the HcNoCompressionForProxies metabase key is set to FALSE (default behavior).
ISAPI_MODIFIED_HEADERS	An ISAPI filter has improperly modified the HTTP headers or the response body, preventing IIS from correctly compressing the content.
RESPONSE_STATUS_NOT_200	The HTTP response status code for the request is not 200 (OK). By default, IIS only compresses 200 responses.
WILDCARD_APP_MAPPING	A wildcard application mapping is causing static files to be treated as dynamic, and they are not configured for dynamic compression.
DOCUMENT_FOOTER_PRESENT	The presence of a document footer (e.g., appended by an external component) is interfering with static compression.
ANTIVIRUS_INTERFERENCE	Antivirus software is scanning or locking the temporary compression directory, preventing IIS from writing or reading compressed files.

Best Practices for IIS Compression¶

To minimize future compression issues and maintain optimal performance, consider implementing these best practices:

• Regularly Monitor Logs: Frequently review IIS logs and ETW traces to catch compression failures early.
• Test Thoroughly: After making any configuration changes, rigorously test your website to ensure compression is working as expected across various content types and browsers.
• Understand Third-Party Modules: Be aware of any third-party ISAPI filters or HTTP modules installed, as they can significantly impact IIS behavior, including compression. Test them in isolation if issues arise.
• Ensure Proper Permissions: Periodically verify file system and metabase permissions for the IIS application pools and the compression directory.
• Exclude Compression Directory from AV: Confirm that your antivirus software excludes the IIS temporary compressed files directory from real-time scans.
• Consider Content Type: Focus compression on text-based content (HTML, CSS, JS, XML). Images (JPG, PNG, GIF) and already-compressed files (ZIP, PDF, DOCX) generally do not benefit from further compression and can even increase CPU load.
• Monitor CPU Usage: While compression saves bandwidth, it consumes CPU cycles. Monitor server CPU usage, especially during peak traffic, to ensure compression is not leading to performance bottlenecks.

Conclusion¶

Effective web content compression is a cornerstone of modern web performance. While IIS provides robust compression capabilities, troubleshooting issues requires a systematic approach, understanding the interplay between various configuration settings, permissions, and external factors. By following the comprehensive steps outlined in this guide, from fundamental enablement in IIS Manager to advanced ETW tracing, you can effectively diagnose and resolve most IIS compression problems in IIS 6 and 7.x.

We hope this guide proves invaluable in optimizing your web server performance. Have you encountered any other unique IIS compression challenges? Share your experiences and solutions in the comments below – your insights could help others!