Virtual Directories: Targeting Local Directories and Network Shares

[Editor's Note: Be aware that as of this writing, Microsoft doesn't officially support pass-through delegation, which is one of the methods discussed in this article.]

If you're using IIS as your Web server, you have access to excellent virtual directory capabilities. You can use a virtual directory structure to selectively publish the content of certain physical directories without exposing their locations. However, before starting any discussion about IIS virtual directories, you need to be clear about what virtual directories are and how IIS uses them. Then, you can determine the most efficient source for your directories and decide how best to configure access and security.

The Basics
When you install an IIS Web server, the installation process creates a home directory (\%systemdrive%\inetpub\wwwroot by default) on that system. IIS uses this location to serve any HTTP request that doesn't include a directory name in the URL (e.g., http://webserver/default.asp). All physical directories under the home directory are also available to Web clients. For example, placing default.asp in the subdirectory \%systemdrive%\inetpub\wwwroot\subdir makes the URL http://webserver/subdir/default.asp available to clients. A virtual directory is a mechanism that you can use to make available a specific directory that resides anywhere on the file system or network, rather than only under the IIS server's home directory.

A quick glance at the Microsoft Management Console (MMC) Internet Information Services console reveals that IIS uses different icons to represent virtual directories, physical directories, and Web applications, as Figure 1 shows. In this example, RemoteScripts is a virtual directory, aspnet_client and subdir are physical directories directly under the Default Web Site object (i.e., the home directory), and IISHelp, IISAdmin, and IISSamples are Web applications. (For information about Web applications and their relation to virtual and physical directories, see the Web-exclusive sidebar "Web Applications," http://www.windowswebsolutions.com, InstantDoc ID 25933.) A red Error icon next to a virtual directory, such as the icon beside the Scripts virtual directory in Figure 1, indicates an error condition—most likely that the physical directory to which the virtual directory points no longer exists.

Be aware that a client request that includes ".." (e.g., http://altoid/subdir/../scripts/script.asp) jumps from the specified subdirectory (e.g., \%systemdrive%\inetpub\wwwroot\subdir) to the virtual directory (e.g., the Scripts virtual directory). Although jumping in itself isn't a problem, many viruses (e.g., Nimda) use requests that contain "..". To prevent jumping, you can install the URLScan add-on tool, as the Microsoft article "INFO: Availability of URLScan Version 2.5 Security Tool" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q307608) explains. (For more information about using URLScan, see Randy Franklin Smith, "Deploy URLScan to Protect Your IIS Server," August 2002, InstantDoc ID 25581, and "Protect Your IIS Server with URLScan," July 2002, InstantDoc ID 25230.)

Pick a Source
When configuring a virtual directory, you have a choice of three content sources. These sources are a local directory (i.e., a directory on the Web server), a network share on another computer, or redirection to a URL. Let's take a look at the first two options (I'll discuss the third option in my next article).

Using a local directory. The most common and efficient scenario targets a local directory. The local file system satisfies all requests without going to a remote machine (as using a file share on another computer requires) and without causing an extra HTTP round-trip (as redirecting to a URL requires). When you create a new virtual directory, it points to the local file system by default. To change the local directory that an existing virtual directory targets, open the Internet Information Services snap-in. Open the virtual directory's Properties dialog box and go to the Virtual Directory tab. Select the A directory located on this computer option, then specify the target directory in the Local Path text box, as Figure 2 shows, or click Browse to search for the target directory.

Using the local file system is also the most reliable option. The most common problem arises when someone renames or deletes the target directory without changing the virtual directory's Local Path property setting. (This problem occurs most often when more than one administrator manages IIS.) This error manifests itself as a 404 Object Not Found reply to the server, and an Error icon will appear next to the virtual server object in the Internet Information Services console. To search for such errors, you can open the W3SVC server logs (each Web site has a subdirectory under \%systemroot%\logfiles that contains that site's log files) and search for 404 in the Status Code field. The easiest way to locate a problem is to use Event Viewer (which you can access under Administrative Tools or through the eventvwr.exe command) to examine events in the System log. Look for an error event with a source of W3SVC.

Using a remote share. Using a remote share rather than a local directory lets you serve Web pages from a centralized network computer, even when that system doesn't run IIS. When you specify the A share located on another computer option in the virtual directory's properties, the Virtual Directory tab displays the Network Directory text box and a Connect As button (rather than the Local Path text box and Browse button). In the Network Directory text box, use the Universal Naming Convention (UNC) \\computername\share to specify the remote target system and share.

   Previous  [1]  2  3  Next