permissions error in IIS install

Don't know the details on IIS because I've never worked with that server, but you need to protect that directory from being accessible via the web. One technique may be to use IIS to password protect the directory. That way other people won't be able to download your backup files if they're somehow able to guess what the file names are.

If you do find an easy and reliable way to protect directories in IIS, please let me know how you did it so I can add the instructions to the README.

Thanks
Ronan

Ditto that. I just upgraded to D 6.17 and started with the same errors. No problems until the upgrade. So I backed up and did a fresh install hoping that it would set the permissions during install and nope, didn't work. As I only use IIS7 on a Vista development box it is not too critical. It appears that what I need is a lesson on permissions for IIS7, which is annoying cause it worked before with no problems.

Unfortunately, I'm running IIS7 on a Vista box. It is just for development, but I need to be able to be able to update the live site using this module. It was working prior to the last update, so I have reverted to 6.x-1.2 and it works fine. If someone who knows IIS7 could guide me through the permissions, I would be grateful. Otherwise, I'll just live with the update messages. It is a great module when using Dreamweaver, going back and forth between the development and remote sites and all. My remote is actually on a Unix platform. Other than having to turn off clean URLs, I can go back and forth effortlessly.

mtndan's solution is great if you have access to IIS Manager. That isn't the case for all of us.

I'm supporting a Drupal site on a shared Windows host. I have no access to IIS manager. .htaccess is not an option. Is there a work around other than hacking the code?

My solution for iis7:
Simply block the directory in the web.config file:
Add the following lines to the RULES section:

 <rule name="postinst-redirect" stopProcessing="true">
           <match url="sites/default/files/backup_migrate" />
           <action type="Rewrite" url=""/>
</rule>

(if your backup migrate files are in sites/default/files/backup_migrate)

@munti: looks like the actual lines are missing. If you can finish this write up I'll put it in the README

I've wrapped the code by munti in <code> tags.

I've added the instructions to the readme for securing IIS7 to the 2.x branches. Thanks all.

Munti's rule doesn't work on my IIS 7.5.
This one does:

<rule name="Protect Backup and Migrate" patternSyntax="Wildcard" stopProcessing="true">
  <match url="*sites/default/files/backup_migrate*" />
  <action type="Redirect" url="/" />
</rule>

So is this a difference between IIS 7.5 and IIS 7? Should I add both of these rules to the README or will the second one also server for IIS7 users? I'm afraid I have no experience with this server so I'm relying on IIS users to give me some good advice I can pass on to others.

I'm no IIS guru, but thought I might as well try and contribute to this solution anyways. We're running IIS 7 with Drupal 6 and we are using "Request Filtering" rather than URL rewriting. In our case, we are not actually running the URL matching rules through IIS, but are instead running them using Helicon's ISAPIRewrite software, and we don't even have the rewrite filter enabled in IIS. Ours will not be a common IIS configuration for folks running Drupal.

Still, I wonder about the preference here for using the rewrite rules when trying to protect folders. Is it possible that in IIS, requestFiltering rules may be better than URL matching and rewriting when you are trying to secure a folder from prying eyes? That seems to be the suggestion on this page here:
http://learn.iis.net/page.aspx/501/iis-request-filtering-and-url-rewriting/

I don't really know enough about IIS to say for sure.

In any case, here is an example of such a configuration. We stick our site backups in a root folder, outside of the sites folder hierarchy. And here is an [edited] sample of the relevant web.config code:

        <security>
            <!-- we need to allow doubleescaping to fix IIS 7's over protectiveness causing stray errors in Drupal -->
            <requestFiltering allowDoubleEscaping="true">
                <!-- protect _backmeuphere folder and reject common hacker attempts -->
                <denyUrlSequences>
                    <add sequence="_backmeuphere"/>
                </denyUrlSequences>
                <fileExtensions>
                    <add fileExtension=".mysql" allowed="false" />
                    <add fileExtension=".pl" allowed="false" />
                    <add fileExtension=".sql" allowed="false" />
                </fileExtensions>
            </requestFiltering>
        </security>

Phil.

I shall let this debate continue until somebody has a suggestion for what I should put in the README. Or perhaps an enterprising IIS user could create a WIKI page and I'll just put in a link to that. That way the debate can continue forever :)

I have some IIS language in the README now. If anybody wants think's it's incorrect or insufficient please let me know.

#6 did not work for me, but adding the following rule to web.config did work. Hope it helps somebody.

Using Webmatrix on Window 8 box
Version 3.0

WebMatrix: 7.1.1924.0
IIS Express: 8.0.8418.0
.NET Framework: 4.0.30319.18046 built by: FX45RTMGDR
Web Deploy: 7.1.1762.0
Web Platform Installer: 7.1.1863.0
ASP.NET Web Pages: 2.0.20715.0

<!--Protect backup_migrate directory in local IIS environment-->
        <rule name="postinst-redirect" stopProcessing="true">
         <match url="sites/default/files/private/backup_migrate" />
         <action type="CustomResponse" statusCode="403" subStatusCode="0" statusReason="Forbidden" statusDescription="Access is forbidden." />
        </rule>

Thank you jraviotta that rule worked the first time. I had tried Windows security settings on the folder with varying degrees of success. Following the Wiki page one user suggested I reset the access on IUSR adding a Deny on List Folder Contents, and this made my entire site unusable and I could not revert the security settings so I had to format the drive! This was much simpler, and gets to the point: we don't want the Internet users to get there so block with a 403. Perfect. Thank you!