Getting IIS7 gzip compression working with Plesk

IIS7 comes with the ability to apply compression to static and dynamic files, but we had a mongrel of a time making it work properly on our new 2008 server with Plesk 9. Same probably applies to Plesk 10 if you were unfortunate enough to install that instead (hint – I hate v10 with a passion – it’s evil).

Long story short it came down to a permissions issue. Essentially the difference between static and dynamic compression (in a practical sense) is caching — IIS7 will compress the file and cache the zipped output to disk so that the next time the request is served directly from cache (meaning no need to recompress it, hence less CPU overhead).

In our case, IIS was not able to write to the cache folder so essentially nothing happened. To make it work, you need to give the psacln user (which is the group which contains all the plesk assigned IIS worker processes) full access to the cache folder. You also need permissions on all parent folders of your cache folder for the psacln user to traverse — if you just apply the permission to the cache folder itself nothing will happen. To minimise the mucking about, the easiest thing to do is to change the location of the cache (via the IIS interface) to something like E:\IIS_compressed (your drive letter may vary – we put our cache on E because there’s nothing of any importance on that partition so we can be a little less lax with permission settings). Give psacln full access on that folder, and give it at least “read/list” on the root E:\ and you’re all set.

This is easy enough and you could leave it there. Problem is that Plesk has a neat little tool for resetting disk permissions, which is quite handy when things go wrong — you can just reset the permissions and things start working again. This, however, also undoes whatever change you made above so there’s one extra step you need to perform:

In your plesk program files folder, open up {plesk-install-folder}/etc/disksecurity/disksecurity.xml in a text editor.

On a 32bit system the default location is: c:\program files\parallels\plesk\etc\disksecurity\disksecurity.xml
On 64 bit it’ll be c:\program files (x86)\parallels\plesk\etc\disksecurity\disksecurity.xml

Paste the following XML at the bottom of the other entries, just before the final closing tag. It needs to be the last entry so it doesn’t get clobbered by the other definitions in the file.

<!-- E Drive (backups, IIS compressed -->
<Entry AccounType="1" Account="Psaadm" Path="/"  SubPath="IIS_compressed" AceFlags="ThisFolderSubfoldersAndFiles"
AccessMask="FullAccess" EntryFlags="0x2" />
<Entry AccounType="1" Account="Psacln" Path="/"  SubPath="IIS_compressed" AceFlags="ThisFolderSubfoldersAndFiles"
AccessMask="FullAccess" EntryFlags="0x2" />
<Entry AccounType="1" Account="Psaserv" Path="/"  SubPath="IIS_compressed" AceFlags="ThisFolderSubfoldersAndFiles"
AccessMask="FullAccess" EntryFlags="0x2" />

Here’s the article explaining what these settings settings actually do

Notes:

Before we worked out that it was only psacln that wanted those permissions we had tried psaadm and psaserv as well. I decided to leave those permissions in place just in case. You can try just inserting the one <Entry> node if you like.
I changed the MIME type for Javascript from “application/x-javascript” to “text/javascript” before I got to this point — I had read in various places that this setting made IIS happier, but since it started working my interest evaporated and I haven’t been back in to test whether the setting actually made a difference or not. It *shouldn’t* since IIS by default is set to compress/cache both but if you still have trouble gzipping javascript after applying the permissions above, give that a shot also.
You need to restart IIS after making any permission change on the cache folder (e:\IIS_compressed). It appears that it will only make one attempt to write to the cache folder and if it fails, will never try again.

Diagnosis & Testing

The way we got to the bottom of this was fairly simple in the end. Download and run Process Monitor. Add a filter so that you are only monitoring the actions of w3wp.exe