HOWTO: Allow file downloads (including .exe) on IIS 6.0, Part 2

  • Article

Some users have reported that IIS6 still refuses to allow an EXE file to download even after removing "Scripts and Executables" Execute Permission and making sure that .EXE has a MIME Type. Alright... I will have to come up with some more non-obvious reasons as possible explanations, as I now detail...

Question:

I have read your blog on how to make exe downloadable in IIS 6.0. I have followed your instructions to the letter and I can get everything to download except the exe files. I have made sure that only scripts are allowed in the execute permissions, I have made sure that a mime exist for .exe application/octet-stream. When I rename the executable from lets say x.exe to x.bin I am able to download the file so I know IIS is finding the file, however it will not download it as an executable. If you know of anywhere else I should be checking I would greatly appreciate it. I know you must be inundated with request.

Thanking you ahead of time

Answer:

Hmm... you are suggesting an interesting mystery that looks like an issue with IIS6, but I am not yet convinced that we have ruled out user misconfiguration. We all know how clever users can be at shooting themselves in the foot. ;-)

So, what you are saying is that:

  1. Only "Scripts" Execute permissions are enabled for the URL.
  2. MIME Type definitely exists for the .EXE extension.
  3. Yet .EXE resource is still not downloading.

Well, according to my previous discussion on how IIS decides to handle a given request, IIS is either executing the code on the server or it is sending it as download to the client. And since you say that it is not downloading to the client, I can only presume that IIS is still executing the EXE file on the server.

You can confirm this by looking up the IIS log file entry for the request, located at %SYSTEMROOT%\System32\LogFiles\W3SVC#\*.log . It probably has either "404 2 1260" or "404 0 2" as the Status, Sub-Status, and Win32 error codes.

Well, if the .EXE is still executing on the server and you only have "Scripts" Execute Permission, then you must have configured an application mapping for the .EXE extension to run some Script Engine, and either that Script Engine does not exist (resulting in "404 0 2"), or it is not allowed in the Web Service Extension ("404 2 1260"). I consider both to be more clever user misconfiguration.

Now, I do not know WHY you have .EXE configured as an application mapping. All you need to do is enable "Scripts and Executables" Execute Permission and the .EXE will execute on the server. In other words, the following two configurations are pretty much the same logically (though they are different in terms of ACL requirements and other NT permissions, but let's ignore that for now, for the sake of conceptual clarity):

  1. Configure .EXE application mapping to be run by CMD.EXE and Execute Permission is "Script".
  2. No application mapping for .EXE and Execute Permission is "Scripts and Executables".

#1 is a misconfiguration that I have seen some users make, but I do not understand why. I would really like to hear some user comments as to why you are configuring #1 to logically accomplish #2.

If you truly want .EXE to be downloadable, then you should just configure Execute Permission to "None". In that case, IIS never bothers trying to execute anything on the server - all requests should download. If that still does not work, then I can only presume that you have some custom ISAPI Filter running on the server performing arbitrary behavior, and I cannot give reasonable advice on arbitrary behavior...

//David