Life after FPSE (Part 3)

In continuation from my blog posts on April 17th and April 23rd, today's blog post will continue to examine moving from the FrontPage Server Extensions (FPSE) to WebDAV, and today I'm going to address a combination of issues that I've run into and questions that I've received from customers.

WebDAV Authoring Rules versus FPSE Roles

FPSE had a variety of built-in roles defined that have no replacement in a WebDAV world, but in all actuality most of those roles have no meaning in a WebDAV world. FPSE Roles were built around a set of User Rights, with several predefined roles like Administrator, Author, Contributor, and Browser. Each of these predefined roles contained various User Rights, and you could create your own roles from scratch by grouping together sets of User Rights. The following screen shot shows the full list of User Rights that were available:

Right up front you should be able to see a reason why there is no WebDAV replacement for many of these - they are mostly specific to FPSE-related behavior, such as adding themes or borders to a web, etc. Roles were generally written to file system ACLS through the use of specialized groups named "OWS_nnnnn_xxxxx" for whichever role was in use:

That being said, FPSE did a great number of things that annoyed many web administrators - namely:

  • If you manually changed your permissions to a set of customized permissions, FPSE would eventually rewrite your permissions the way that it thought they should be.
  • If you decided that having NETWORK and INTERACTIVE in the ACLs for every web site on your server was a bad thing, FPSE didn't seem to care and kept adding those permissions to every FPSE-enabled web site.

There are many other things that FPSE did that made people upset, but mainly I heard a great deal of complaints about those two behaviors.

Here's the great thing about moving to WebDAV - whatever permissions you set on your files will stay on your files. WebDAV does not come along later and reset anything, so now you're really in charge of your own ACLs. What's more, you can combine your WebDAV authoring rules with your file system ACLs to give you the flexibility and power that you have when combining file shares and file permissions. The following screen shot shows a small handful of WebDAV authoring permissions configured for two groups of users:

Since I manage several servers, I like having more control over what's really going on with my permissions. (When it comes to servers, I'm something of a control freak. <grin>) If you're familiar with AppCmd, you can script the creation of WebDAV authoring rules, making it easy to write scripts that create sites and automatically deploy a set of authoring rules for each site. More information on using AppCmd to script authoring rules is available in the "Working with WebDAV Authoring Rules" section of the following walkthrough:

How to manage WebDAV using APPCMD

WebDAV Redirector Weirdness

I mentioned in my last blog that I wrote the following walkthrough that discusses using the WebDAV redirector in depth:

Using the WebDAV Redirector

Once again, that walkthrough discusses how to install the redirector, how to map drives to WebDAV sites, and how to troubleshoot some of the problems that you might see when using the WebDAV Redirector. That being said, I have noticed a couple of other things when working with the WebDAV Redirector that I thought needed mentioning.

Weirdness #1: xcopy.exe fails on repeated copy operations

I discovered one day when using xcopy.exe to backup a site from one server to another that xcopy fails when doing repeated copy operations on WebDAV-mapped drives. Here's an example of that that looks like:

C:\>net use *
Enter the user name for '': msbob
Enter the password for ******
Drive Z: is now connected to

The command completed successfully.

C:\>net use *
Enter the user name for '': msbob
Enter the password for ******
Drive Y: is now connected to

The command completed successfully.

C:\>xcopy y:\*.* z:\ /e /r /y
4 File(s) copied

C:\>xcopy y:\*.* z:\ /e /r /y
File creation error - The directory is not empty.

Unable to create directory - Z:\subdir1
2 File(s) copied


Looking at the above example, you can see that the WebDAV Redirector successfully maps drives to both web sites, and the first xcopy.exe operation succeeds by copying all four files from the source web site to the destination web site. However, the second xcopy.exe operation fails when trying to copy files into a subdirectory in the destination web site.

Unfortunately, there's nothing that can be done about this failure right now. I talked about this with the team that makes the WebDAV Redirector and they said that they can't fix this at the moment. That said, they did suggest a workaround of using the robocopy.exe utility instead. Since I was simply trying to backup a site, I was able to successfully use the following syntax to backup the site after xcopy.exe failed:

C:\>robocopy y:\ z:\ /mir

   ROBOCOPY     ::     Robust File Copy for Windows


  Started : Thu May 01 15:21:35 2008

   Source = y:\
     Dest = z:\

    Files : *.*

  Options : *.* /S /E /COPY:DAT /PURGE /MIR /R:1000000 /W:30


                           2    y:\
100%        Older                     41        default.htm
100%        Older                      0
                           1    y:\subdir1\
100%        Older                     41        default.htm
                           1    y:\subdir2\
100%        Older                     41        default.htm


                Total    Copied   Skipped  Mismatch    FAILED    Extras
     Dirs :         3         0         3         0         0         0
    Files :         4         4         0         0         0         0
    Bytes :       123       123         0         0         0         0
    Times :   0:00:00   0:00:00                       0:00:00   0:00:00

    Speed :                 207 Bytes/sec.
    Speed :               0.011 MegaBytes/min.

    Ended : Thu May 01 15:21:36 2008


It's still not an ideal situation in my book - I'd rather just use xcopy.exe, but at the moment it's a workaround that I can live with.

Weirdness #2: WebDAV Redirector Timeouts

I mentioned in the walkthrough listed above that you can see the "System error 67 has occurred" when any one of several possible conditions might exist. One of the things that had me confused when I first ran into these errors was that I would fix the root cause of the problem and yet I would still get the same error when I attempted to map a drive. Unfortunately, this problem used to turn up during the early days of our development cycle when I was presenting the alpha versions of our new WebDAV module, so I used to think it was something that we were doing wrong. 😉

As it turns out, the WebDAV Redirector keeps a cache of failed server attempts, and if you're fast enough at fixing the problem, the WebDAV Redirector will still prevent you from being to connect until the timeout is reached or you restart the service. You can alter the timeout duration by changing the value of the "ServerNotFoundCacheLifeTimeInSec" registry setting that is detailed in the "WebDAV Redirector Registry Settings" section of the above walkthrough, or you can quickly restart the service like I did in the following example:

C:\>net use *
System error 67 has occurred.

The network name cannot be found.

C:\>net stop webclient & net start webclient
The WebClient service is stopping.
The WebClient service was stopped successfully.

The WebClient service is starting.
The WebClient service was started successfully.

C:\>net use *
Enter the user name for '': msbob
Enter the password for ******
Drive Z: is now connected to

The command completed successfully.


For a while I got in the habit of restarting the service after fixing the cause of the error, but once I adjusted the timeout to a lower value I almost forgot about it until I borrowed someone else's machine to do a WebDAV presentation. <grin>

No more FrontPage "Bots" or "Web Components"

Okay, I have to admit - I'm not sad to see the FrontPage "Bots" go the way of the dinosaur, but I realize that there are several people that would disagree with my sentiments. If you'll recall from my first blog post in this series, FPSE and I go back a long way. When FrontPage and FPSE were first released, the marketing slogan surrounding FrontPage was "Professional Web Site Publishing without Programming":

What are FrontPage "Bots"?

The way that FrontPage and FPSE delivered on that promise was through the use of FrontPage "Bots", which were later renamed as "Web Components". These can be subdivided into two main categories:

  • Author-time Bots/Components: These were features that were used to automate authoring features and did not require FPSE. These features included functionality such as substitution fields, included pages, automatic table of contents generation, navigation bars, etc.
  • Run-time Bots/Components: These were features that were designed to run interactively on a server through the use of FPSE. These features included functionality such as form processing, hit counters, threaded discussion groups, etc.

The great thing about bots was - they enabled the average user to create dynamic web sites without any programming skills or knowledge of technologies like CGI, ISAPI, ASP, PHP, etc.

But bots were both a blessing and a curse. Over the past twelve years I have seen an enormous number of FPSE bot failures, which has usually resulted in the ubiquitous phrase, "My FPSE site is broken." If you're curious about how prevalent this situation is, do a quick search on the phrase "FrontPage Save Results Component" - you should see tens of thousands of web pages, each of which having a web form that should be using FPSE but can't because it's "broken".

The End of the Road for FrontPage "Bots"

Microsoft’s currently line of web authoring tools, including Microsoft Visual Studio and Microsoft Expression Web Designer, do not support Author-time Bots/Components, although these tools may provide alternate web authoring functionality that replaces some of these features. When mainstream support for FrontPage 2003 ends in 2009, existing FrontPage-based Author-time Bots/Components will cease to be supported.

When mainstream support for the FrontPage Server Extensions ends in 2010, support for the FrontPage-based Run-time Bots/Components will likewise end. Much of the functionality provided by the Run-time Bots/Components can be provided through web applications using technologies such as ASP.NET, Classic ASP, PHP, etc.

For information about what kinds of "bot-like" features will be available in the upcoming Microsoft web authoring tools, check out the following team blogs:


It's time to bring today's blog entry to a close, but I hope that I've provided some information that will help anyone that's migrating from FPSE to WebDAV.

Comments (3)
  1. Garry Trinder says:

    May I also add that FPSE was messy and WebDAV is sexy?

  2. merk says:

    I have to say, I’m a bit disappointed by the webdav alternative. When frontpage worked, it was really nice. Webdav doesn’t really seem to live up to the ‘it was really nice’ part. I don’t consider mapping drives an ideal way of accessing a site. Especially for someone who works on multiple sites. That mean’s i either need to have a multitude of drives mapped or i need to constantly map and unmap a drive.

    It does however sound like webdav would be more fool proof then frontpage and wouldn’t suffer from the ‘when it works’ part of frontpage.

    To me it feel somewhat like MS got tired of supporting the problems with frontpage, didn’t want to invest the time or money to really fix them and is only throwing webdav into things as a lazy fix to the removal of frontpage. Maybe I am just speaking out of ignorance, but it seems like MS should be able to come up with a more unified way of logging into and gaining access to the content on a website.

    I apologize if this sounded like i was bashing you personally. I do appreciate the blog posts explaining this. I’m just a little disapointed we don’t get the same ease of us (when it worked 😉 that we had with frontpage.

  3. robmcm says:

    Thanks, Ian (merk).

    No worries – it didn’t sound like you were bashing me personally. 😉

    Actually, when working with newer web authoring tools you don’t have to map a drive in order to use a WebDAV-based site – that’s only necessary when working with older development tools that aren’t WebDAV-aware, like the old FrontPage family of products. If you are using Expression Web you can open your web site by using the http:// address the same way that you have used in the past when working with FPSE-based web sites. But that being said, Windows never offered a feature where you were able to map a drive to an FPSE-enabled web site, so having that feature built-in for WebDAV is a great thing to have.

    Actually, the problem with FPSE is that it was a proprietary “RPC over HTTP” solution to web publishing that was owned exclusively by Microsoft. As a bit of history, when FPSE was invented, the only real alternative was FTP. When FPSE came along in 1995 it provided an HTTP-based method of delivering content, but since it was proprietary only a handful of clients ever supported FPSE, and the bulk of those were Microsoft’s web authoring tools. Once you ventured away from Microsoft’s tools you were usually limited to FTP again.

    The great thing about WebDAV is that it is an open standard with a much wider scope of industry acceptance and a much greater number of clients support it. So when you look at it, WebDAV is the only real unified way of logging into and gaining access to the content on a website.

    WebDAV was first released in February of 1999, and it has steadily gained acceptance over the past decade. During that time period, we have been trying to move everyone inside Microsoft away from FPSE. As I mentioned in previous blogs, the team that originally owned FPSE ceased creating new versions of FPSE six years ago, and since then that team has been focusing exclusively on SharePoint. In the meantime, the IIS product team has been investing more into WebDAV and FTP simply because those are the protocols that web authors on the Internet want to use.

    So in the end, while everyone realizes that FPSE has had more than its fair share of problems, the choice to deprecate FPSE was made based on the fact that FPSE has outlived its usefulness. FPSE was an acceptable HTTP-based publishing solution when there was nothing else, but now that there’s something better (WebDAV) we’re shifting our efforts in that direction.

Comments are closed.

Skip to main content