Network Computingwww.networkcomputing.com

If you're looking to better manage Web content via Internet Information Server, you'll like our latest Network Design Manual chapter, Administering Virtual Directories and Servers, from Osborne McGraw-Hill's Administering IIS 5.0 by Mitch Tulloch and Patrick Santry. In our first exclusive, hands-on excerpt, you'll learn how to create, configure, and delete virtual directories for content stored both locally and on remote servers.

Introduction

Organizing your Web content is an important issue for corporate intranets spanning multiple departments and for Internet servers hosting content for more than one company. Internet Information Services 5.0 allows administrators to organize Web content in two ways: by using virtual directories and using virtual servers. After completing this chapter, you will be able to:

• Understand what virtual directories are and what they are used for
• Create, configure, and delete virtual directories for content stored both locally and on remote servers
• Understand what virtual servers are and what they are used for
• Create, configure, and delete virtual servers for content stored both locally and on remote servers
• Understand host headers and how they are used to configure virtual servers

Virtual directories are a mechanism that allows Web content to be stored in locations other than the default directory

C:\inetpub\wwwroot

which is the home directory for the default Web site that is created on the local machine on which IIS is installed. This is accomplished by defining an alias for the virtual directory and mapping this alias to the physical location of the Web content. The actual Web content may be located in:

• A directory on the local machine (hence a local virtual directory)
• A share on a remote server (hence a remote virtual directory)

For an example of a local virtual directory, consider the mapping:

marketing ´ D:\MarketingDept\Webstuff

which assigns the alias marketing to the Web content stored in the directory

D:\MarketingDept\Webstuff

which is on the local machine (that is, the machine on which IIS is installed). If the local machine is an intranet server called server1, the Marketing Department Web site would be accessed by the following URL:

http://server1/marketing

The previous example illustrates why the term virtual directory is used: the user attempts to access the subdirectory marketing, which appears to be a subdirectory of the home directory of the default Web site on the IIS server. In other words, the path for the Marketing directory appears to be

C:\inetpub\wwwroot\marketing

but this subdirectory doesn't actually exist. Instead, it is an alias representing the real directory:

D:\MarketingDept\Webstuff

So we could say that virtual directories are mappings of URL space onto directory space.

Remote Virtual Directories

For an example of a remote virtual directory, consider the mapping

sales ´ \\Fileserv4\SalesWeb

which assigns the alias sales to the Web content stored in the share SalesWeb, which is on the remote machine Fileserv4. Note that remote virtual directories are mapped to UNC network shares. Again, if IIS is installed on a machine called server1, the Sales Department Web site would be accessed by the following URL:

http://server1/sales

Why Use Virtual Directories?

Virtual directories, especially remote ones, are useful for several reasons:

• It's easier to allow existing content to be left on existing file servers instead of being moved to a new IIS server. Moving content from one server to another involves several administrative tasks: capacity planning and upgrading for the new server, establishing new drive mappings for non-Web access to the content, educating users concerning the change in location of content, and so on. A key rule of thumb for administrators is if it works OK, don't change it!
• Performing backups of content is simpler if the content is left on existing file servers. Your network has a backup scheme in place for its existing file servers; using remote virtual directories means you don't have to modify your existing backup scheme.
• Upgrading the capacity of servers storing the content for your intranet can be performed without shutting down the Web servers themselves, minimizing Web server downtime.
• Security is enhanced by allowing those who create content access only to servers hosting content, not the Web servers themselves. No shares need to be created on the Web servers, making the Web servers more impervious to attack from hackers.
• Content can be segregated between departments by using virtual directories. Each department can access its own Web content through a unique URL (http://<server>/<dept_alias>) that maps to a unique directory on a server. Departments can work independently on their sites and only need to have their home pages linked to the default home page of the company Web site (http://<server>/default.htm) in order for them to be located and viewed on the intranet.
• Load balancing can take place by storing content for different departments on different file servers.
• Content can be stored on the network in locations where it is easily accessed and updated. Web servers can be installed in locations where they are easily accessed by administrators (although the HTML version of Internet Service Manager allows most IIS management functions to be performed remotely from anywhere in the network).