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. ;-]) Enabling access to these folders over WebDAV is necessary if you are opening your website over a WebDAV-mapped drive while you are using authoring clients that do not have native WebDAV support, such as FrontPage or Visual Studio.

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. is used for normal HTTP web browsing
  • The second website (e.g. 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. is configured to use delegated configuration
  • The second application pool (e.g. 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=''].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 website, you can still connect to 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. ;-]

Note: This blog was originally posted at

IIS 6: Setting up SSL - Overview

Many years ago I wrote a series of instructions that used dozens of screenshots in order to show my coworkers how to set up and enable Secure Sockets Layer (SSL) communications in IIS 5, which I eventually turned into a blog series on one of my personal blog sites. A few years later I wrote a sequel to that series of instructions for my coworkers, and I wanted to turn that into a series of walkthroughs in the website. Sometime ago I proposed the idea to Pete Harris, who was in charge of at the time, but then I changed jobs and we scrapped the idea. We followed up on the idea a short time ago, but we just couldn't find a place where it made sense to host it on, so Pete suggested that I turn it into another blog series. With that in mind, over a series of several blog entries I will show how to configure SSL on IIS 6.

Note: This first post will leverage a lot of the content from the overview that I wrote for my IIS 5 blog series, but subsequent posts will reflect the changes in IIS 6.

Much like IIS 5, setting up SSL on IIS 6 is pretty simple. SSL is a Public Key/Private Key technology, and setting up SSL is essentially obtaining a Public Key from a trusted organization. The basic process for working with SSL is reduced to the following actions:

  1. Creating a Certificate Request
  2. Obtaining a Certificate from a Certificate Authority
  3. Installing the Certificate

While not necessary, installing certificate services on your computer is helpful when troubleshooting SSL issues, and I'll discuss that later in this blog series.

Creating a Certificate Request

This is a series of steps that need to be performed on the web server, and they differ widely depending on the server and version. A web administrator is required to enter information about their organization, their locality, etc. This information will be used to validate the requester.

Obtaining a Certificate from a Certificate Authority

This is when a web administrator submits their request for a certificate to a Certificate Authority (CA), which is a trusted organization like VeriSign or Thawte. For a list of trusted organizations, see the following section in Internet Explorer.

You can choose to trust a new CA by obtaining the Root Certificate from the CA. (I'll post an Obtaining a Root Certificate blog with more information later.)

Installing the Certificate

After a request has been processed by a CA, the web administrator needs to install the certificate on the web server. Once again, this series of steps needs to be performed on the web server, and the steps differ depending on the web server and version.

For the Future...

In future blogs I'll go through the steps for creating certificate requests, obtaining certificates from a CA, and installing certificates. Following that, I'll discuss setting up a CA for testing SSL in your environment.

Note: This blog was originally posted at