Life after FPSE (Part 3)
In continuation from on 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
http://go.microsoft.com/fwlink/?LinkId=108319
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
http://go.microsoft.com/fwlink/?LinkId=112138
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:
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:
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:
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:
Summary
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.