Share via

IIS Compression failure - compression_disabled Status

  • Article

Recently, we ran into a problem where static or dynamic compression would not work on a few websites, specially SharePoint sites, but works on other sites.

I always use our software tools and take a data driven approach for troubleshooting any kind of software problem. Software tools not only help you pin point problem area, but also assists in effective troubleshooting. Without data driven approach, we are pretty much into a guessing game or trial & hit method.

OK. So the next step is identify what tool(s) to use and the answer is – It depends. It depends on where you are troubleshooting (client side/server side etc). We know that IIS server is responsible for sending compressed responses. So naturally, we want to know why IIS isn’t compressing responses. There are many cases where IIS will not compress a response. For e.g. requests with status code 401. For a list of reasons, please refer to this blog post from Mike Laing, Escalation Engineer, Microsoft IIS support.

The most effective tools to trace into IIS are:

  1. Event Tracing for Windows aka ETW Tracing
  2. DebugView Tracing

ETW is the most easiest and preferred method because, unlike DebugView trace, it doesn’t require any registry changes and restart of the IIS services. In an earlier post, I discussed how to capture and parse an ETW trace.

Back to the problem… So in this case, here’s what the ETW trace showed us:

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

CAUSE:

The problem occurs only when you use a custom account for application pool identity, which was the case here as well. When using a custom account for application pool, you must provide read permissions for that application pool identity on the metabase compression keys within IIS configuration file – metabase.xml, located in %windir%\system32\inetsrv, so that it can read the settings. A failure reading the settings will cause a status of COMPRESSION_DISABLED.

Honestly, I didn’t know the cause at the top of my head, but a genius (Vivek Kumbhar) in my team who fiddles around a lot with his machine knew the cause & resolution. I am trying to find out how we can track down this failure due to lack of permissions on certain metabase keys. I will update this post after that. I will also document the various reasons and their associated causes.

 

SOLUTION

So when using a custom identity for the application pool, take these additional steps

  1. Add the application pool identity to the IIS_WPG group.
  2. Provide the application pool identity Read permissions on the website content folder using NT ACLs.
  3. Application pool identity/IIS_WPG must have query permissions in the following metabase keys: (use IIS 6.0 Metabase Explorer from IIS Resource Kit):
  4. LM –> Read
  5. W3SVC –> Read
  6. AppPools -> Query Unsecure Property (Special Permission)
  7. Filters -> Read and Write
  8. Compression –> deflate (Read and Write - Inherited)
  9. Compression –> gzip (Read and Write - Inherited)
  10. Restart IIS