Robert McMurray's Blog [MSFT]

Life after FPSE (Part 4)

In continuation from my previous blog posts on on the subject of migrating from FPSE to WebDAV, today's blog post will address a combination of issues that I've run into and some implementation ideas.

Listing content in virtual directories

One different that I ran into rather quickly after I migrated a couple of web sites from FPSE to WebDAV was that suddenly my virtual directories were visible in my web authoring tool, which is Microsoft Expression Web. By default, virtual directories didn't show up when using FPSE - you had to explicitly "install" FPSE on individual virtual directories in order to use them from FrontPage or Visual Studio over the FPSE protocol.

For one web site this was somewhat alarming, because I had a web site with only 200 web pages and a virtual directory with thousands of files in it, and I routinely create VBA macros to automate large-scale authoring actions. This meant that any use of the ActiveWeb.AllFiles collection would take a large amount of time to process.

There isn't any easy way to hide virtual directories from WebDAV, because they're not necessarily hidden from any HTTP requests. If your web sites use virtual directories, WebDAV simply makes them available. You can't use IIS 7 Request Filtering's "hidden segments" or "deny sequences" to hide these paths, although you can use those to prevent access.

The only way that you can more or less "hide" your virtual directories would be to set the authoring rules to allow access to no one. Here's how this might work: you create a web site where you enable WebDAV at the root and add an authoring rule for yourself. Once that is completed, you would click on your virtual directory in the tree view and bring up the WebDAV authoring rules for that path. You would first remove the authoring rule for yourself, then add a new rule that denies all users any access to the virtual directory path.

What the above steps actually do is to instruct the WebDAV module to deny everyone access, so all PROPFIND requests for that path will result in an HTTP 403 response, therefore most WebDAV clients will not display the path. In my particular case I implemented these steps and my web site authoring is back to the way that I expected things to be.

Setting up two sites

Another idea that I've implemented on a few web sites lately is to use two web sites that point to the same content:

• The first web site (e.g. www.example.com) is used for normal HTTP web browsing
• The second web site (e.g. authoring.example.com) is used for for WebDAV authoring

This configuration yields a number of great benefits, but it's not always possible. For example - if someone else is hosting your web content, they might not want to give you a second web site, or they might charge you for two web sites.

Just the same, here's my short list of some reasons why using a second web site for your WebDAV authoring might be a good idea to look into:

• Each web site can have separate security settings (anonymous versus authenticated).
• Log file data will be kept separate for browsing versus authoring activity.
• Each web site can have a separate apppool, and the authoring apppool can be configured to ignore delegated configuration; this configuration helps alleviate problems from uploading invalid Web.config files that might otherwise prevent HTTP access to your web site.
• Each web site can have separate request filtering rules - this alleviates having to configure the "applyToWebDAV" attribute on your request filtering settings.
• You can have separate SSL requirements for each site - your "www" site can be HTTP-only and your authoring site can be HTTPS-only.
• Virtual directories on the "www" site would not automatically be added to the authoring site, so you can "hide" content from your authoring activities. For example, if you have a set of library scripts that your web site uses that you want to prevent authors from trying to update, you can deploy them through a virtual directory on the "www" site and it will remain hidden from the authoring web site until it's explicitly added.

That's just a few of the benefits that I've been seeing from deploying WebDAV in a two-site configuration - I'm sure that there are a great deal more reasons why this might be a great idea if you can afford to deploy a site this way.

That's all for today - I hope this gives you some more ideas to think about.

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
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:

C:\>net use * http://www.fabrikam.com Enter the user name for 'www.fabrikam.com': msbob Enter the password for www.fabrikam.com: ****** Drive Z: is now connected to http://www.fabrikam.com. The command completed successfully. C:\>net use * http://www.contoso.com Enter the user name for 'www.contoso.com': msbob Enter the password for www.contoso.com: ****** Drive Y: is now connected to http://www.contoso.com. The command completed successfully. C:\>xcopy y:\*.* z:\ /e /r /y Y:\default.htm Y:\www.contoso.com.txt Y:\subdir1\default.htm Y:\subdir2\default.htm 4 File(s) copied C:\>xcopy y:\*.* z:\ /e /r /y Y:\default.htm Y:\www.contoso.com.txt File creation error - The directory is not empty. Unable to create directory - Z:\subdir1 2 File(s) copied C:\>

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 www.contoso.com.txt 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 C:\>

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 * http://www.example.com/ 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 * http://www.example.com/ Enter the user name for 'www.example.com': msbob Enter the password for www.example.com: ****** Drive Z: is now connected to http://www.example.com/. The command completed successfully. C:\>

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:

• Expression Web Team Blog
• Visual Web Developer Team Blog

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.

Life after FPSE (Part 2)

Following up on my last blog post, today's blog post will discuss some of the highlights and pitfalls that I have seen while transitioning from using the FrontPage Server Extensions to publish web sites to WebDAV. It should be noted, of course, that FTP still works everywhere - e.g. Expression Web, FrontPage, Visual Studio, etc. As the Program Manager for both WebDAV and FTP in IIS I can honestly say that I love both technologies, but I'm understandably biased. <grin> That said, I'm quite partial to publishing over HTTP whenever possible, and Windows makes it easy to do because Windows ships with a built-in WebDAV redirector that enables you to map a drive to a web site that is using WebDAV.

To set the mood for today's blog, let's have a little fun at FPSE's expense...

A Few Notes about Migrating FPSE Web Sites to WebDAV and Backwards Compatibility

To start things off, I wrote a detailed walkthrough with instructions regarding how to migrate a site that is using FPSE to WebDAV that is located at the following URL:

Migrating FPSE Sites to WebDAV
http://go.microsoft.com/fwlink/?LinkId=108347

I wrote that walkthrough from the point-of-view that you might want to preserve the FPSE-related metadata in order to open your web site using a tool like Visual Studio or FrontPage. Neither of these tools have native WebDAV support, so you have to map a drive to a WebDAV-enabled web site in order to use those tools, and the instructions in that walkthrough will lead you through the steps to make the FrontPage-related metadata available to those applications over WebDAV.

The part of that walkthrough that makes backwards compatibility work is where I discuss adding settings for the IIS 7 Request Filtering feature so that FPSE-related metadata files are blocked from normal HTTP requests, but still available to WebDAV. (These metadata settings are all kept in the folders with names like _vti_cnf, _vti_pvt, etc.)

It should be noted, however, that if you are not interested in backwards compatibility, the steps are much simpler. In Step 1 of the walkthrough, you would choose "Full Uninstall" as the removal option, and all of your _vti_nnn folders will be deleted. If you've already removed FPSE from a web site and you chose the "Uninstall" option, you can remove the _vti_nnn folders from your site by saving the following batch file as "_vti_rmv.cmd" in the root folder of you web site and then running it:

dir /ad /b /s _vti_???>_vti_rmv.txt for /f "delims=;" %%i in (_vti_rmv.txt) do rd /q /s "%%i" del _vti_rmv.txt

It's worth noting, of course, that this batch file can be pretty disastrous if run in the wrong web site, as FPSE will no longer be able to access any of the metadata that defined your web site. Any content stored in folders like _private, fpdb, _overlay, etc., will all be preserved.

Getting to Know the WebDAV Redirector

Windows Vista and Windows Server 2008 both ship a first-class director, making it easy to use WebDAV sites across the Internet as though they were local shares. Using the WebDAV director is as intuitive as mapping a drive to any UNC share, you just specify the drive letter and the destination URL:

If you prefer, you can also use the command-line to map a drive to a WebDAV site:

C:\>net use * http://www.example.com/ Enter the user name for 'www.example.com': msbob Enter the password for www.example.com: ****** Drive Z: is now connected to http://www.example.com/. The command completed successfully. C:\>

Rather than repeat myself any more than necessary, I wrote the following walkthrough for anyone that plans on using the WebDAV redirector:

Using the WebDAV Redirector
http://go.microsoft.com/fwlink/?LinkId=112138

That walkthrough discusses how to install the redirector if necessary, how to map drives to WebDAV sites, and how to troubleshoot any problems that you might see.

Microsoft Expression Web - Using a WebDAV-enabled Editor

One of my favorite publishing features in Expression Web is that it has native WebDAV support built-in, so it doesn't have a dependency on the WebDAV redirector in order to work with a WebDAV-enabled web site. If you're currently using Expression Web to open a web site using FPSE, the change to WebDAV should be fairly seamless. If you're currently using FrontPage, the Expression Web team has put together a whitepaper that describes the differences between FrontPage and Expression Web, which is available from the following link:

Microsoft FrontPage to Expression Web
Transitioning to Microsoft® Expression® Web from Microsoft Office FrontPage® 2003

That being said, when opening a WebDAV web site in Expression Web, you simply enter the HTTP URL the same way that you would if you were opening a site using FPSE:

When you first open a web site using WebDAV, Expression Web will prompt you whether to edit the web site live, or edit locally and publish your changes later:

Once your live web site is opened, the WebDAV editing experience is what you would have expected from using FPSE:

Summary

So in closing, I've presented a few things to consider when working with WebDAV instead of FPSE. Using the WebDAV redirector makes working with WebDAV sites as easy as working with network shares, and using Expression Web is by far the easiest way to edit WebDAV sites.

Life after FPSE (Part 1)

Today's blog post will be the first in a series of blog posts that I intend to write about my experiences with putting together a Windows Server 2008 machine without using the FrontPage Server Extensions (FPSE) for any web publishing. The main goal of this series is to describe some of the highlights and pitfalls that I have run into while transitioning away from FPSE.

Over the years I've seen the users of FPSE broken down into two groups: those that love FPSE and those that hate FPSE. So before anyone thinks that I fall into the category of people that hate FPSE, in this first part of the series I will explain a brief bit of my history with FPSE.

My Personal Background with FPSE

In late 1995, Microsoft bought a little-known Massachusetts-based company named Vermeer Technologies, Inc., which really only had one product: FrontPage 1.0. (Incidentally, that's where all of those _vti_nnn folders that FPSE uses come from: the "vti" stands for Vermeer Technologies, Inc.) The product was quickly transitioned into the Microsoft array of Office products, and Microsoft realized that they needed someone to support it. With that in mind, four of my coworkers and I started a FrontPage support team in Microsoft's Product Support Services (PSS) organization. The following photo shows what the five of us looked like "way back when..."

Note: My hair is much shorter now. <grin>

The First Microsoft FrontPage Version

Back then we supported both the FrontPage client and FPSE. Two coworkers specialized on what was then a small array of Windows-based servers (WebSite, Netscape, etc.), while another coworker and I specialized on the wider array of Unix-based servers, (NCSA, CERN, Netscape, Apache, etc.) At first FPSE was 100% CGI-based, but Microsoft soon released Internet Information Services (IIS) 1.0 for Windows NT Server 3.51 and we provided an ISAPI version of FPSE when FrontPage 1.1 was released in early 1996. In either case, FPSE was often somewhat difficult to configure, so a couple of my coworkers and I used to spend our free time searching the Internet looking for servers that were using FPSE incorrectly, then we would call them and offer to help fix their web sites for free. (Support was different back then, wasn't it? <grin>)

FrontPage Gains Popularity

Industry acceptance for FrontPage and FPSE grew rapidly through the releases of FrontPage 97 and FrontPage 98. During that same time period Microsoft released IIS 2.0 through IIS 4.0 for Windows NT Server 4.0, where I switched from supporting the FrontPage client and refocused my career to work exclusively with FPSE and IIS. Over a short period of time a couple of coworkers and I became the escalation point for all the really difficult FPSE cases - so chances are good that if you were using FPSE back then and you had a problem then one us us probably helped you fix it. Sometime around this period Microsoft decided to scrap internal development for the Unix version of FPSE, so Microsoft contracted Ready-to-Run Software, Inc., to port FPSE to Unix.

FrontPage Grows Up

The next couple of years saw the releases of FrontPage 2000, FrontPage 2002, and FrontPage 2003, where FrontPage did its best to move away from a simple web authoring tool into more of a feature-rich developer tool. During that same time period Microsoft released IIS 5.0 for Windows Server 2000 and IIS 6.0 for Windows Server 2003. Through all of these releases I slowly transitioned from an escalation team member to writing content, where I wrote or edited hundreds of Knowledge Base articles about FPSE and IIS for Microsoft's support web site. I also worked extensively with several members of the IIS product team in order to get some much-needed changes into FTP and WebDAV.

What was interesting about the release of FrontPage 2003 is that Microsoft did not release a version of FPSE to coincide with that release. This decision was based on the fact that the product team that was responsible for FPSE was also responsible for SharePoint, and they decided to drop FPSE as a separate product in favor of SharePoint. What this meant to FPSE end users was - FPSE was being slowly phased out in favor of SharePoint, or in favor of competing publishing technologies like WebDAV or FTP.

The End of FrontPage

After the release of IIS 6.0 I accepted a position as an SDK writer on the IIS User Education team, and a short time later I found out that the Product Unit Manager for IIS, Bill Staples, was looking for someone to take over web publishing in IIS 7.0 on Windows Server 2008. Bill and I had already had several discussions on the subject so I volunteered for the position, and for the last few years my life has been happily consumed with shipping FPSE, FTP, and WebDAV for Windows Server 2008.

During this same time period, however, Microsoft ended the line of FrontPage products; the team responsible for the FrontPage client splintered into the groups that now make the SharePoint Designer and Expression Web products, and the FPSE product team was now focusing exclusively on SharePoint. This situation meant that no one that worked on FPSE in the past was available to work on a new version for Windows Vista or Windows Server 2008, which left FPSE users in a predicament if they wanted to upgrade their operating systems. With this in mind, the IIS product team decided to contract Ready-to-Run Software, Inc. again in order to port the Windows version of FPSE to Windows Vista and Windows Server 2008. Even then, though, FPSE's days are numbered.

Summary

So, the short end to this long story is that I've been around the FrontPage Server Extensions in one way or another ever since the very beginning, and I've seen the good, the bad, and the ugly.

In my next post, I'll discuss using WebDAV instead of FPSE.

WebDAV Extension for Windows Server 2008 RTM is released!

Earlier today the Microsoft released the RTM version of the new Microsoft WebDAV Extension for IIS 7.0 for Windows Server 2008!

Listed below are the links for the download pages for each of the individual installation packages:

• 32-bit Installation Package:
  • WebDAV (x86) Extension Module for IIS 7.0
• 64-bit Installation Package:
  • WebDAV (x64) Extension Module for IIS 7.0

We've loaded this version with many great new features such as:

• Integration with IIS 7.0:
  • The new WebDAV extension module is fully integrated with the new IIS 7.0 administration interface and configuration store.
• Per-site Configuration:
  • WebDAV can be enabled and configured at the site-level on IIS 7.0, which differed from IIS 6.0 where WebDAV was enabled at the server-level through a Web Service Extension.
• Per-URL Security:
  • WebDAV-specific security is implemented through WebDAV authoring rules that are configured on a per-URL basis.

Additional information about new features in the WebDAV extension is available in the "What’s New for Microsoft and WebDAV?" topic on Microsoft's http://learn.iis.net/ web site.

To help you get started using the new WebDAV extension, the following walkthroughs have been published on the http://learn.iis.net/ web site:

• Getting Started:
  • Installing and Configuring WebDAV on IIS 7.0
  • What’s New for Microsoft and WebDAV?
  • Using the WebDAV Redirector
• Advanced Administrative Features:
  • How to manage WebDAV using APPCMD
  • How to use custom properties with WebDAV
  • How to configure WebDAV and Request Filtering
  • Migrating FPSE Sites to WebDAV

Here are a couple of screenshots of the new WebDAV UI in action:

The following prerequisites are required to install the new WebDAV extension:

• You must be using Windows Server 2008.
• Internet Information Services 7.0 must be installed.
• If you are going to manage the new WebDAV extension using the IIS 7.0 user interface, the administration tool will need to be installed.
• You must install the new WebDAV extension as an administrator.
• IIS 7.0 supports a new shared configuration environment, which must be disabled on each server in a web farm before installing the new WebDAV extension for each node. Note: Shared configuration can be re-enabled after the WebDAV extension had been installed.

Feedback about the WebDAV extension and requests for information can be posted to the following web forum:

IIS7 Publishing Forum: http://forums.iis.net/1045.aspx

I would be remiss if I did not mention that special thanks go to:

• Keith – for building it
• Eok, Sriram, Ciprian, Dave – for testing it
• Gurpreet, Brian, Carlos, Reagan – for making it look pretty
• Wade, Ulad, Nazim – for stretching it

We've had a great time working on this project - thanks again to everyone that provided feedback to us throughout all of our technical previews!

Thanks!

FREB: LOG_FILE_MAX_SIZE_TRUNCATE

OK - I have to admit that one of my favorite features for IIS 7 is "Failed Request Tracing", otherwise known as "FREB". I've taught breakout sessions about FREB at Microsoft TechEd, and IT administrators love it. (By the way - FREB was originally called "Failed Request Event Buffering", in case you're wondering why the acronym doesn't match. ;-] )

Anyway, FREB is designed as "no repro" tracing, where you can set up tracing rules for specific conditions and IIS will generate log files if those rules are triggered. I like to refer to this as "set it and forget it" logic, because you enable your tracing conditions and then check for log files later.

I enabled FREB tracing for HTTP 500 errors on a new server recently, and I enabled it at the global level so an HTTP 500 error on any web site would generate a log file. A few days later I was checking my HTTP logs using LogParser to give me a breakdown of HTTP requests by status, and I saw that a few HTTP 500 errors had turned up. Being the geek that I am, for a few fleeting moments I was more elated that I had some live FREB logs to check and I almost forgot about finding & fixing the root cause.

Sure enough, however, IIS 7 had faithfully created several FREB logs for me. Opening the logs, it correctly listed the logs' trigger status as an HTTP 500 error, and it listed the event as LOG_FILE_MAX_SIZE_TRUNCATE. I assumed that this meant that I had run out of room for my IIS W3C log files. But then I thought - this is strange, it's a new server and I have lots of hard drive space free, so how can I be out of log file disk space?

Then it dawned on me - I was thinking about the wrong log files; the error message was trying to tell me that the FREB logs were too big. By default IIS 7 truncates the FREB log files at 512KB. Since I had turned on full verbosity for the FREB logs, there was simply too much data for the log files to complete.

The following commands took care of that problem, and the next time an HTTP 500 error was triggered I received the full FREB log file and it pinpointed the exact problem:

cd /d "%windir%\system32\inetsrv"
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:1024

Bear in mind, though, that the above command configures your log files so that each can be 1MB in size, instead of the default 512KB. This probably doesn't matter much given the price of hard drive space these days, but I wanted to point it out.

Before closing on this thought, I thought I'd show some of the other commands that I used to configure FREB at the global-level.

• List available global-level FREB settings:

  appcmd set config /section:sites -? | find "traceFailedRequestsLogging"

• Enable FREB tracing at the global-level:

  appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.enabled:true

• Set the default number of FREB logs to 10, instead of the schema default of 50:

  appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFiles:10

• Reset the default max FREB log file size back to 512KB:

  appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:512

For more information on FREB, see the following topics:

• Troubleshooting Failed Requests Using Tracing in IIS 7.0
• How to Capture ASP.NET Page Trace Events in IIS 7.0 Tracing
• How to Enable Failed Request Tracing for UNC Hosting

Automating IIS 7 Backups

Many years ago I wrote the following KB article:

• How To Schedule Metabase Backups Using WSH

Truth be told, I wrote the script in that article to help me manage several servers that I controlled. Once I finished the script, I found myself routinely giving it out to customers in order for them to automate their backups, so I decided to turn it into a KB. When IIS 6 came out, Microsoft shipped the IIsBack.vbs script to help customers automate backups.

One of the great things in IIS 7 is the deprecation of the metabase, which has been replaced by applicationHost.config, but the need for backing up your configuration settings is still there. With this in mind, I wrote a small batch file that I schedule to create backups of my configuration settings using the APPCMD utility. Since I've been giving this to customers at Microsoft TechEd, I thought it might make a nice blog post for everyone that can't make it to TechEd.

To use the script, copy the code below into Windows Notepad, then save it to your computer as "BackupIIS.cmd". (I usually save it in "%WinDir%\System32\Inetsrv", but you could save it to your executable search path as well.)

@echo off
cls

pushd "%WinDir%\System32\inetsrv"

echo.| date | find /i "current">datetime1.tmp
echo.| time | find /i "current">datetime2.tmp

for /f "tokens=1,2,3,4,5,6" %%i in (datetime1.tmp) do (
  echo %%n>datetime1.tmp
)
for /f "tokens=1,2,3,4,5,6" %%i in (datetime2.tmp) do (
  echo %%m>datetime2.tmp
)
for /f "delims=/ tokens=1,2,3" %%i in (datetime1.tmp) do (
  set TMPDATETIME=%%k%%i%%j
)
for /f "delims=:. tokens=1,2,3,4" %%i in (datetime2.tmp) do (
  set TMPDATETIME=D%TMPDATETIME%T%%i%%j%%k%%l
)

appcmd add backups %TMPDATETIME%

del datetime1.tmp
del datetime2.tmp

set TMPDATETIME=

popd
echo.

You can use Task Scheduler in Windows Server 2008's Server Manager to schedule this script to run at whatever interval you choose, although I usually schedule it to run once a week.

Backups will be created in the following path:

• %WinDir%\System32\Inetsrv\Backups\DyyyymmddThhmmssii

Where yyyymmdd is the year, month, day, and hhmmssii is the hour, minute, second, millisecond for the time of the backup.

I hope this helps!

Enabling WebDAV on IIS 6

I had a great question from someone the other day about enabling WebDAV on IIS 6, so I wrote a simple Windows Script Host (WSH) utility that does the trick. Because I'm a firm believer that writing code for one person will ultimately benefit someone else, I'm making that script the subject of today's blog post. ;-)

Note: The following script makes use of several IIS 6 metabase properties, and you can see the following topics for more information:

• http://msdn2.microsoft.com/en-us/library/ms525087(VS.85).aspx
• http://msdn2.microsoft.com/en-us/library/ms525016(VS.85).aspx
• http://msdn2.microsoft.com/en-us/library/ms524576(VS.85).aspx

To use this script, use the following steps:

• Copy the WSH code listed below and paste it into a text editor, such as Windows Notepad:

  Option Explicit
  
  ' --------------------------------------------------
  ' Part 1: Enable the WebDAV Web Service Extension.
  ' --------------------------------------------------
  
  ' Retrieve an object for the W3SVC root.
  Dim objIIsWebService
  Set objIIsWebService = GetObject("IIS://localhost/W3SVC")
  ' Enable the WebDAV Web Service Extension.
  objIIsWebService.EnableWebServiceExtension "WEBDAV"
  ' Save the changes to the metabase.
  objIIsWebService.SetInfo
  
  ' --------------------------------------------------
  ' Part 2: Enable the WebDAV-related attributes for the Default Web Site.
  ' --------------------------------------------------
  
  ' Retrieve an object for the web site root.
  Dim objIIsWebSite
  Set objIIsWebSite = GetObject("IIS://localhost/W3SVC/1/ROOT")
  ' Enable the WebDAV-related access flags.
  objIIsWebSite.AccessRead = True
  objIIsWebSite.AccessSource = True
  objIIsWebSite.AccessWrite = True
  ' Enable the directory browsing - required for file listings.
  objIIsWebSite.EnableDirBrowsing = True
  ' Save the changes to the metabase.
  objIIsWebSite.SetInfo
  

• Update the metabase path for your web site to IIS://localhost/W3SVC/nnn/ROOT, where nnn is the identifier for the web site where you want to enable WebDAV. Note: The web site identifier can be found in the IIS Manager using the following steps:
  • Open the IIS manager.
  • Expand the local computer node. 
  • Highlight the Web Sites node.
  • Notice the site ID in the "Identifier" column.
• Save the file as EnableWebDav.vbs to your desktop and close your text editor.

Note: This script is not designed the new WebDAV module for IIS 7. To manage the WebDAV module in IIS 7, see the following topics:

• Installing and Configuring WebDAV on IIS 7.0
• How to manage WebDAV using APPCMD

I hope this helps!

FTP7 for Windows Server 2008 RTM is released!

Earlier today Microsoft released the RTM version of the Microsoft FTP Service for IIS 7.0 for Windows Server 2008!

Listed below are the links for the download pages for each of the individual installation packages:

• FTP 7 (x86) Installation Package
  http://go.microsoft.com/fwlink/?LinkId=87847
• FTP 7 (x64) Installation Package
  http://go.microsoft.com/fwlink/?LinkId=89114

I've added this feature list in some of my past postings, but I’m going to repost that here because it sums up nicely what the new FTP service has to offer:

This new FTP service incorporates many new features that enable web authors to publish content better than before, and offers web administrators more security and deployment options.

• Integration with IIS 7.0: IIS 7.0 has a brand-new administration interface and configuration store, and the new FTP service is tightly integrated with this new design. The old IIS 6 metabase is gone, and a new configuration store that is based on the .NET XML-based *.config format has taken its place. In addition, IIS 7.0 has a new administration tool, and the new FTP service plugs seamlessly into that paradigm.
• Support for new Internet standards: One of the most significant features in the new FTP service is support for FTP over SSL. The new FTP service also supports other Internet improvements such as UTF8 and IPv6.
• Shared hosting improvements: By fully integrating into IIS 7.0, the new FTP service makes it possible to host FTP and Web content from the same site by simply adding an FTP binding to an existing Web site. In addition, the FTP service now has virtual host name support, making it possible to host multiple FTP sites on the same IP address. The new FTP service also has improved user isolation, now making it possible to isolate users through per-user virtual directories.
• Improved logging support: FTP logging has been enhanced to include all FTP-related traffic, unique tracking for FTP sessions, FTP sub-statuses, additional detail fields in FTP logs, and much more.
• New supportability features: IIS 7.0 has a new option to display detailed error messages for local users, and the FTP service supports this by providing detailed error responses when logging on locally to an FTP service. The FTP service also logs detailed information using Event Tracing for Windows (ETW), which provides additional detailed information for troubleshooting.

Additional information about new features in FTP7 is available in the "What's New for Microsoft and FTP?" topic on Microsoft's http://learn.iis.net/ web site.

The following prerequisites are required to install the new FTP service:

1. You must be using Windows Server 2008.
2. Internet Information Services 7.0 must be installed.
3. If you are going to manage the new FTP service using the IIS 7.0 user interface, the administration tool will need to be installed.
4. You must install the new FTP service as an administrator.
5. IIS 7.0 supports a new shared configuration environment, which must be disabled on each server in a web farm before installing the new FTP service for each node. Note: Shared configuration can be re-enabled after the FTP service had been installed.
6. The FTP service that is shipped on the Windows Server 2008 DVD must be uninstalled before installing the new FTP service.

To help you get started using the new FTP service, the following walkthroughs have been published on the http://learn.iis.net/ web site:

• Installing FTP7:
  • Installing and Troubleshooting FTP7
• Working with FTP Sites:
  • Creating a New FTP Site
  • Add FTP publishing to an existing Web site
• Configuring Security Features:
  • Configure FTP over SSL
  • Configure FTP User Isolation
  • Configure FTP virtual host names
  • Configuring FTP Firewall Settings
• Advanced Administrative Features:
  • Using FSRM Folder Quotas with FTP
  • Configure IIS Manager Authentication

Special thanks go to:

• Jaroslav, Emily, Daniel, Umer – for building it
• Suditi, Ciprian, Jeong, Dave – for testing it
• Andrew, Carlos, Brian – for prettying it
• Wade, Ulad, Nazim – for stretching it
• Reagan, Claudia, Rick, Tim, Tobin – for documenting it

It's been a great couple of years working on this project - thanks again to eveyone that provided feedback to us throughout all of our technical previews!

FPSE 2002 RTM for Windows Server 2008 and Windows Vista (x86/x64)

I'm happy to announce that earlier today Microsoft and Ready-to-Run Software released to web the RTM version of the FrontPage 2002 Server Extensions for IIS 7.0 on Windows Server 2008 and Windows Vista.

Listed below is the link for the download page for the combined 32-bit/64-bit installation package:

• FrontPage 2002 Server Extensions for IIS 7.0
  http://go.microsoft.com/fwlink/?LinkId=86706

FPSE 2002 for IIS 7.0 is supported on all of the the following operating systems:

• Windows Server 2008
• Windows Vista Ultimate
• Windows Vista Home Premium
• Windows Vista Business
• Windows Vista Enterprise

Additional documentation about installing and using this version of FPSE 2002 can be found at the following URL:

Installing the FrontPage 2002 Server Extensions:
http://go.microsoft.com/fwlink/?LinkId=88546

This release version is fully supported by Ready-to-Run Software.

Feedback about this release and requests for information can be sent to fpsupport@rtr.com or posted to the following web forum:

IIS7 - Publishing:
http://forums.iis.net/1045.aspx

My thanks for all the great work by Ready-to-Run Software that helped make this release possible!

WebDAV Redirector Registry Settings

Following up on the release of the WebDAV module for IIS 7, I've been experimenting with the WebDAV redirector that comes with Windows Vista and Windows Server 2008. This redirector ships as an updated WebClient service, and if you're using Windows Vista it should already be installed, but on Windows Server 2008 you will need to install the "Desktop Experience" feature. Once installed, you can map drives to WebDAV shares much like mapping to a UNC path:

Through some experimentation, I discovered some WebClient service behaviors that I wanted to explain. For example, if I tried to map a drive to a web site that did not have WebDAV enabled I would get an error as expected. But after I enabled WebDAV, I would continue to get an error until some period of additional time had passed. I assumed that the status was somehow cached, and I was curious as to whether I could control that caching. I eventually discovered that there are several settings that control the behavior of the WebDAV redirector that can be configured in the following registry key :

HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

I found a variety of sources that documented one setting or another but I couldn't find a concise list, so I've collected the following list that contains what I've been able to discover so far:

Note: After changing any of these settings you will need to restart the WebClient service.

I hope this list helps someone else. ;-]

WebDAV Module for Windows Server 2008 GoLive Beta is released

Earlier today the IIS product team released the GoLive beta version of the new WebDAV extension module for IIS 7. (This version is currently available for Windows Server 2008 only.)

Listed below are the links for the download pages for each of the individual installation packages:

• 32-bit Installation Package:
  • WebDAV Extension Module for IIS 7.0 (x86)
• 64-bit Installation Package:
  • WebDAV Extension Module for IIS 7.0 (x64)

We've loaded this version with many great new features such as:

• Integration with IIS 7.0: The new WebDAV extension module is fully integrated with the new IIS 7.0 administration interface and configuration store.
• Per-site Configuration: WebDAV can be enabled at the site-level on IIS 7.0, which differed from IIS 6.0 where WebDAV was enabled at the server-level through a Web Service Extension.
• Per-URL Security: WebDAV-specific security is implemented through WebDAV authoring rules that are configured on a per-URL basis.

Here are a couple of screenshots of the new WebDAV UI in action:

Additional documentation about installing and using this version of WebDAV can be found at the following URL:

Installing and Configuring WebDAV on IIS 7.0:
http://go.microsoft.com/fwlink/?LinkId=105146

While this release is a beta version and not technically supported, feedback about this release and requests for information can be posted to the following web forum:

IIS7 - Publishing:
http://forums.iis.net/1045.aspx

I would be remiss if I did not mention that special thanks go to:

• Keith – for building it
• Eok, Sriram, Ciprian – for testing it
• Gurpreet, Brian, Reagan – for making it look pretty
• Vijay,  Will, Taylor – for helping keep everything on track ;-]

Thanks!

FPSE 2002 RC1 for Windows Server 2008 and Windows Vista (x86/x64)

Earlier today Microsoft and Ready-to-Run Software released to web the Release Candidate 1 (RC1) version of the FrontPage 2002 Server Extensions for IIS 7.0 on Windows Server 2008 and Windows Vista. This build now includes a combined installation package for 32-bit and 64-bit versions of Windows.

Listed below is the link for the download page for the combined 32-bit/64-bit installation package:

• FrontPage 2002 Server Extensions for IIS 7.0

FPSE 2002 RC1 for IIS 7 is supported on all of the the following operating systems:

• Windows Server 2008 (Code Name "Longhorn")
• Windows Vista Ultimate
• Windows Vista Home Premium
• Windows Vista Business
• Windows Vista Enterprise

Once again, additional documentation about installing and using this version of FPSE 2002 can be found at the following URL:

Installing the FrontPage 2002 Server Extensions:
http://go.microsoft.com/fwlink/?LinkId=88546

While this release is a beta version and not technically supported, feedback about this release and requests for information can be sent to fpbeta@rtr.com or posted to the following web forum:

IIS7 - Publishing:
http://forums.iis.net/1045.aspx

Thanks!

Creating XML Reports for FSRM Quota Usage

I had a great question in follow up to the "Secure, Simplified Web Publishing using Microsoft Internet Information Services 7.0" webcast that I delivered the other day, "How you can you programmatically access the quota usage information from the File Server Resource Manager (FSRM)?"

First of all, there is a native API for writing code to access FSRM data detailed at the following URL:

http://msdn2.microsoft.com/en-us/library/bb625489.aspx

That's a bit of overkill if you're just looking to script something.

There is a WMI interface as well, but it’s only for FSRM events.

So that leaves you with a pair of command-line tools that you can script in order to list your quota usage information:

• storrept.exe - Used to manage storage reports
• dirquota.exe - Used to manage quota usage

Right out of the box the first command-line tool, storrept.exe, can generate a detailed XML report using a user-definable scope. To see this in action, take the following example syntax and modify the scope parameter to your desired paths:

storrept.exe reports generate /Report:QuotaUsage /Format:XML /Scope:"C:\"

 You can also specify mutiple paths in your scope using a pipe-delimited format like:

/Scope:"C:\Inetpub|D:\Inetpub"

When the command has finished, it will tell you the path to your report like the following example:

Storage reports generated successfully in "C:\StorageReports\Interactive".

The XML-based information in the report can then be consumed with whatever method you usually use to parse XML. It should be noted that storrept.exe also supports the following formats: CSV, DHTML, HTML, and TXT. 

This XML might be okay for most applications, but for some reason I wanted to customize the information that I received, so I experimented with the second command-line tool, dirquota.exe, to get the result that I was looking for.

First of all, using dirquota.exe quota list returns information in the following format:

Quotas on machine SERVER:

Quota Path:             C:\inetpub\ftproot
Source Template:        100 MB Limit (Matches template)
Quota Status:           Enabled
Limit:                  100.00 MB (Hard)
Used:                   1.00 KB (0%)
Available:              100.00 MB
Peak Usage:             1.00 KB (10/25/2007 2:15 PM)
Thresholds:
   Warning ( 85%):      E-mail
   Warning ( 95%):      E-mail, Event Log
   Limit (100%):        E-mail, Event Log

This information is formatted nicely and is therefore easily parsed, so I wrote the following batch file called "dirquota.cmd" to start things off:

@echo off
echo Processing the report...
dirquota.exe quota list > dirquota.txt
cscript.exe //nologo dirquota.vbs

Next, I wrote the following vbscript application called "dirquota.vbs" to parse the output into some easily-usable XML code:

Option Explicit

Dim objFSO, objFile1, objFile2
Dim strLine, strArray(2)
Dim blnQuota,blnThreshold

' create objects
Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
Set objFile1 = objFSO.OpenTextFile("dirquota.txt")
Set objFile2 = objFSO.CreateTextFile("dirquota.xml")

' start the XML output file
objFile2.WriteLine "<?xml version=""1.0""?>"
objFile2.WriteLine "<Quotas>"

' set the runtime statuses to off
blnQuota = False
blnThreshold = False

' loop through the text file
Do While Not objFile1.AtEndOfStream

  ' get a line from the file
  strLine = objFile1.ReadLine

  ' only process lines with a colon character
  If InStr(strLine,":") Then
    ' split the string manually at the colon character
    strArray(1) = Trim(Left(strLine,InStr(strLine,":")-1))
    strArray(2) = Trim(Mid(strLine,InStr(strLine,":")+1))

    ' filter on strings with parentheses
    strLine = strArray(1)
    If InStr(strLine,"(") Then
      strLine = Trim(Left(strLine,InStr(strLine,"(")-1)) & "*"
    End If

    ' process the inidivdual entries
    Select Case UCase(strLine)

      ' a quota path signifies a new record
      Case UCase("Quota Path")

        ' close any open threshold collections
        If blnThreshold = True Then
          objFile2.WriteLine "</Thresholds>"
        End If

        ' close an open quota element
        If blnQuota= True Then
          objFile2.WriteLine "</Quota>"
        End If

        ' signify a new quota element
        objFile2.WriteLine "<Quota>"

        ' output the relelvant information
        objFile2.WriteLine FormatElement(strArray(1),strArray(2))

        ' set the runtime statuses
        blnQuota= True
        blnThreshold = False

      ' these bits of informaiton are parts of a quota
      Case UCase("Source Template"), UCase("Quota Status"), _
          UCase("Limit"), UCase("Used"), _
          UCase("Available"), UCase("Peak Usage")

        ' close any open threshold collections
        If blnThreshold = True Then
          objFile2.WriteLine "</Thresholds>"
        End If

        ' set the runtime status
        blnThreshold = False

        ' output the relelvant information
        objFile2.WriteLine FormatElement(strArray(1),strArray(2))

      ' these bits of informaiton are thresholds
      Case UCase("Warning*"), UCase("Limit*")

        ' open a threshold collection if not already open
        If blnThreshold = False Then
          objFile2.WriteLine "<Thresholds>"
        End If

        ' output the relelvant information
        objFile2.WriteLine FormatElement( _
          Left(strLine,Len(strLine)-1), _
          Replace(Mid(strArray(1), _
          Len(strLine))," ","") & " " & strArray(2))

        ' set the runtime status
        blnThreshold = True

    End Select
  End If
Loop

' close any open threshold collections
If blnThreshold = True Then
  objFile2.WriteLine "</Thresholds>"
End If

' close an open quota element
If blnQuota= True Then
  objFile2.WriteLine "</Quota>"
End If

' end the XML output file
objFile2.WriteLine "</Quotas>"

objFile1.Close
objFile2.Close
Set objFSO = Nothing

' format data into an XML element
Function FormatElement(tmpName,tmpValue)
  FormatElement = "<" & Replace(tmpName," ","") & _
  ">" & tmpValue & "</" & Replace(tmpName,Chr(32),"") & ">"
End Function

When the batch file and vbscript are run, they will create a file named "dirquota.xml" which will resemble the following example XML:

<?xml version="1.0"?>
<Quotas>
  <Quota>
    <QuotaPath>C:\inetpub\ftproot</QuotaPath>
    <SourceTemplate>100 MB Limit (Matches template)</SourceTemplate>
    <QuotaStatus>Enabled</QuotaStatus>
    <Limit>100.00 MB (Hard)</Limit>
    <Used>1.00 KB (0%)</Used>
    <Available>100.00 MB</Available>
    <PeakUsage>1.00 KB (10/25/2007 2:15 PM)</PeakUsage>
    <Thresholds>
      <Warning>(85%) E-mail</Warning>
      <Warning>(95%) E-mail, Event Log</Warning>
      <Limit>(100%) E-mail, Event Log</Limit>
    </Thresholds>
  </Quota>
</Quotas>

I found the above XML much easier to use than the XML that came from the storrept.exe report, but I'm probably comparing apples to oranges. In any event, I hope this helps someone with questions about FSRM reporting.

Have fun!

Upcoming IIS7 Webcasts

Okay, I have to admit, I was remiss at pointing this out earlier - several members of the IIS product team and myself are presenting webcasts on the TechNet web site for various IIS subjects throughout the month of October. Here's the schedule of upcoming topics:

• Securing and Tuning Microsoft Internet Information Services 7.0
  Tuesday, October 09, 2007 11:30 AM Pacific Time (US & Canada)
• Deploying and Managing Web Farms
  Thursday, October 11, 2007 9:30 AM Pacific Time (US & Canada)
• Secure, Simplified Web Publishing using Microsoft Internet Information Services 7.0
  Tuesday, October 16, 2007 11:30 AM Pacific Time (US & Canada)
• Securely Delegating Remote Web Site Administration With Internet Information Services 7.0
  Thursday, October 18, 2007 9:30 AM Pacific Time (US & Canada)
• Windows SharePoint Services and Windows Server 2008
  Tuesday, October 23, 2007 11:30 AM Pacific Time (US & Canada)
• Automating Microsoft Internet Information Services 7.0
  Thursday, October 25, 2007 9:30 AM Pacific Time (US & Canada)

We've had two webcasts already, and you can still listen to those online:

• What’s New in Microsoft Internet Information Services 7.0 for IT Professionals
  Tuesday, October 02, 2007 11:30 AM Pacific Time (US & Canada)
• Microsoft Internet Information Services 7.0 Diagnostics & Troubleshooting
  Thursday, October 04, 2007 9:30 AM Pacific Time (US & Canada)

Enjoy!