Life after FPSE (Part 6)
In this latest installment on my series about configuring your server for hosting without the FrontPage Server Extensions (FPSE), I'd like to discuss a couple of WebDAV best practices that I like to use.
Blocking FPSE-related Folders with Request Filtering
In my How to Migrate FPSE Sites to WebDAV walkthough, I discuss the following FPSE-related folders:
| Folder | Notes |
| _fpclass | Should contain publicly-available FrontPage code - but should be secured. |
| _private | The FrontPage Server Extensions often keep sensitive data files in this folder, so it should be secured to prevent browsing. |
| _vti_bin | This is the virtual directory for the FrontPage Server Extensions executables. This path is configured to allow executables to function, and since we are migrating sites to WebDAV it should be secured to prevent browsing. |
| _vti_cnf | The FrontPage Server Extensions keep sensitive metadata files in this folder, so it should be deleted or secured to prevent browsing. |
| _vti_log | The FrontPage Server Extensions keep author logs in this folder, so it should be deleted or secured to prevent browsing. |
| _vti_pvt | This folder holds several files that contain various metadata for your website, and should be secured. |
| _vti_txt | This folder contains the text indices and catalogs for the older FrontPage WAIS search. Since later versions of FrontPage only used Index Server, it is safe to delete this folder, but at the very least it should be secured to prevent browsing. |
| fpdb | FrontPage keeps databases in this folder, so it should be secured to prevent browsing. |
One of the actions that I usually take on my servers is to lock down all of these folders for my entire server using Request Filtering. To do so, open a command prompt and enter the following commands:
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_cnf']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_fpclass']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_private']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_log']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_pvt']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_txt']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='fpdb']" /commit:apphost
Note: You should only enter the following commands if you are sure that you will not be using FPSE anywhere on your server!
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_bin']" /commit:apphost
These settings will prevent any of the FPSE-related paths from being viewed over HTTP from a web browser; web clients will receive an HTTP Error 404.8 - Not Found message when they attempt to access those paths. But that being said - when you enable WebDAV for a website by using the Internet Information Services (IIS) Manager, it will configure the Request Filtering settings that enable WebDAV clients to access those paths through WebDAV requests, even though access from a web browser is still blocked. (All of this is made possible through the built-in integration between WebDAV and Request Filtering.
Two Sites are Better Than One
In part 4 of this blog series I discussed why I like to set up two websites when using WebDAV; as a quick review, here is the general idea for that environment:
- The first website (e.g. www.example.com) is used for normal HTTP web browsing
- The second website (e.g. authoring.example.com) is used for for WebDAV authoring
There is a list of several reasons in that blog post why using two sites that point to the same content can be beneficial, and I won't bother quoting that list in this blog post - you can view that information by looking at that post.
But that being said, one of the items that I mentioned in that list was using separate application pools for each website. For example:
- The first application pool (e.g. www.example.com) is configured to use delegated configuration
- The second application pool (e.g. authoring.example.com) is configured to ignore delegated configuration
This configuration helps alleviate problems from uploading invalid Web.config files that might otherwise prevent HTTP access to your website. By way of explanation, the WebDAV module attempts to validate Web.config files when they are uploaded over WebDAV - this is done to try and prevent crashing your HTTP functionality for a website and being unable to fix it. Here's what I mean by that: IIS 7 allows configuration settings to be delegated to Web.config files, but if there is a mistake in a Web.config file, IIS 7 will return an HTTP Error 500.19 - Internal Server Error message for all HTTP requests. Since WebDAV is HTTP-based, that means that you won't be able to fix the problem over WebDAV. (If the WebDAV module didn't perform any validation, that means that your website would become unusable and unrepairable if you had uploaded the bad Web.config file over WebDAV.) To help alleviate this, the WebDAV module performs a simple validation check to prevent uploading invalid Web.config files. But if you save an invalid Web.config file through some other means, like the local file system or over FTP, then you will have no way to repair the situation through WebDAV.
This leads us back to the idea that you can implement when you are using two websites - you can configure the application pool for the WebDAV-enabled website to ignore delegated configuration settings; so it doesn't matter if you have an invalid Web.config file - you will always be able to fix the problem over WebDAV. To configure an application pool to ignore delegated configuration settings, open a command prompt and enter the following commands:
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.applicationHost/applicationPools /[name='authoring.example.com'].enableConfigurationOverride:"False" /commit:apphost
Note: you need to update the highlighted section of that example with the name of your website, such as "Default Web Site," etc.
When you have two websites configured in this example and you have an invalid Web.config file that is causing the HTTP 500 error for the www.example.com website, you can still connect to authoring.example.com via WebDAV and fix the problem.
More Information
For additional information on the concepts that were discussing in this blog, see the following topics:
- Life after FPSE (Part 4) - This blog post discusses a couple of WebDAV-related topics, and includes my list of additional reasons why configuring two websites when you are using WebDAV can be advantageous.
- Adding Application Pools - This topic contains the detailed information about the enableConfigurationOverride setting for an application pool.
- Using the WebDAV Redirector - This walkthrough discusses mapping drives to WebDAV-enabled websites.
I hope this helps.