I have come across to “Static compression is being disabled” error message in Event Viewer while reviewing logs for a web server. This error didn’t cause any user-side issue but it kept being flagged by SCCM.
Here is the Event 2264 with the entire error description:
The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\domain.com is invalid. Static compression is being disabled
Environment and Settings
Here are more details about the server and issue:
- OS is Windows Server 2012 R2
- There are over 12 websites hosted in the server
- Only Anonymous Authentication is enabled
- Anonymous Authentication uses App Pool Identity
- Static Compression is enabled on both server and website level
- Static Compression folder is
C:\inetpub\temp\IIS Temporary Compressed Files - There are sub-folders for each application pool / website. The owner of these folders are Administrator except the DefaultAppPool folder (the owner is DefaultAppPool itself)
- There are no warnings for the other server which uses
%systemdrive%as the Static Compression folder which is not recommended
Note: If you see 500.19 when the client drops the connection, you may have an issue related to the bug in Dynamic Compression module as explained in this post: IIS logs 500.19 if a client drops connection while loading the website
Solution for “Static compression is being disabled” error
The best practice is to have application pool accounts as the owners of the sub-folders in IIS Temporary Compressed Files. For example: IIS APPPOOL\domain.com local account should be the owner of the domain.com folder.
In order to change owners, please follow the steps below for each folder.
- Delete the folder
- Create it with the same name
- Right click and select “Properties”
- Go to “Security”. Click “Advanced”
- Click “Change” for the owner field at the top
More Information
When a compression folder is created by IIS app pool identity that is part of local Administrators group, the folder is owned by the local Admin group and not the worker process identity. IIS checks ownership on existing compression folders when app pool starts so when it isn’t the owner it attempts to delete and recreate the folder. Subsequent app pools get caught in infinite loop attempting to delete and recreate the folder which results in “The directory specified for caching compressed content is invalid” error.
More information about the Error ID 2264 can be found in the official Microsoft documentation.