Workaround for the Nested Virtual Roots Bug

A clarification
Workaround for the Nested Virtual Roots Bug

In my two "How to Build a Web Development Environment" articles (November and December 1999), I described a process for creating nested virtual Web sites that used the Microsoft Management Console (MMC). I also described how to install the Microsoft FrontPage Server Extensions on these virtual Web sites using the MMC. I’ve since learned that while this process does create functioning nested virtual roots, you can't author on a root Web created in this way if you’re using FrontPage. For more information about this bug, see the Microsoft articles referenced at the end of this article.

How Do I Do It?
My company uses a lot of nested virtual roots—and they’re working. Essentially, you don't create nested virtual roots the way I described in the articles. The difference is subtle, but important.

First, build the directory structure for the root Web site and make it a primary domain by giving it its own IP address and port 80 with no host header (as I described in my articles). Then, use FrontPage (not the MMC, as I said in the article) to create the subwebs under the domain. Each subweb has separate access permissions, authors, and administrators (if necessary) from the time you create it. To set unique access options for the subweb, select the Use unique permissions check box on the FrontPage Explorer, Tools, Permissions dialog box. Then, set up the role-based permissions for who can browse, author, and administer the subweb.

To access the Web site with a domain name rather than as a subdirectory under the main domain, use the MMC to create a virtual Web site for the FrontPage-created subweb. Leave the subweb nested: It works fine. I perform this upgrade all the time for my Internet hosting clients who start out with the bargain-price subweb package, then want to upgrade to a separate domain name when they start getting a lot of traffic.

I don't yet know the cause of the nested virtual roots problem, but I think some clues exist in the Microsoft FrontPage Server Extensions Resource Kit. In researching this workaround, I noticed that FrontPage sets up the definitions for configuration variables such as AccessControl and RestrictIISUsersAndGroups on multiple levels: global for the whole machine, virtual server for a root Web site and subweb. According to the resource kit, if you define a configuration variable on more than one level, the FrontPage Server Extensions resolve the conflict by using the following hierarchy: FrontPage first processes the subweb permissions (if they exist), then the virtual server, and finally the global level. Apparently, the MMC doesn’t set some levels of these variables as well as FrontPage does.

See the following Microsoft articles for information about this bug:

Many thanks to Steve Thair of I*Net Architecture of Paribas in London and Andrew Wong Yen of Bandwidth Technologies for their emails tipping me off to the problem.