Chapter 8 - Administering an ISP Installation

This chapter is for Internet service providers (ISPs), Enterprise Service Providers, and Application Service Providers, of all sizes and configurations. Whether your ISP installation contains only one server, or encompasses clusters of servers in various locations, the information in this chapter will help you to administer your installation in an efficient and cost-effective manner.

Organized by task, the material in this chapter shows you how to leverage the power of Internet Information Services (IIS) 5.0 in order to streamline administration. For example, in the "Configuring IIS 5.0" section, you'll learn how to create a company Web site and a personal Web site, and how to restrict content to certain groups of users. In the "Managing Your Installation" section, you'll see how to automate tasks, including Web site creation and changing site permissions. You'll also see how to leverage the replication and clustering features of Microsoft® Windows® 2000 Server in order to guarantee the reliability of your installation. In addition, you'll find information about how to take advantage of other Microsoft products that work in conjunction with IIS 5.0, adding to its power. For example, integrating IIS 5.0 with products such as Microsoft® FrontPage® Server Extensions can make it easier to automate, customize, and administer your installation. And in the "Customizing Your Installation" section, you'll learn how to save money on hardware by configuring multiple sites on one computer, with one Internet Protocol (IP) address.

The last two sections of this chapter show you how to put everything together. The first of these, "Building a Web Cluster," tells you how to set up a three-tier Web cluster. The last section, "Adapting IIS 5.0 to a Sample Installation," describes a real-world ISP installation and tells you how to use IIS 5.0 for various configurations, depending on your customers' needs.

On This Page

Configuring IIS 5.0 Managing Your Installation Customizing Your Installation Building a Web Cluster Adapting IIS 5.0 to a Sample Installation Additional Resources

Configuring IIS 5.0

On an ISP installation, you will probably host many different kinds of Web sites. Commercial sites generate the most money, but you can earn money by hosting personal Web sites as well. IIS 5.0 contains features that can help you set up different kinds of sites, enabling you to get the most out of your investment.

Creating Web Sites

An ISP typically hosts two general types of sites: large, company sites with domain names, and smaller, personal sites with dial-in services. Large, company sites often consist of static Web pages that might include advertising, interactive pages, or e-commerce. Personal sites usually contain the Web pages of individual subscribers. The following sections tell you how to register and set up both types of sites.

Before setting up any sites, configure all disk drives on your servers in the NTFS file system format in order to take advantage of the complete Microsoft® Windows® 2000 security system. For information about setting up security, see "Security" in this book.

Creating a Company Web Site

The following series of procedures show you how to set up a full-domain site, which will have an address in this format: https://domain.com. You will learn how to configure the site so that anonymous users will be able to read the content, and so the owner will be able to transfer content to the site through File Transfer Protocol (FTP) or FrontPage Server Extensions. If there will be more than one owner authoring the site, create user accounts for the additional authors and add them to the user group corresponding to the Web site's domain.

To begin setting up your site

1. Register a domain name with InterNIC ( https://www.networksolutions.com/internic/internic.html ) or with the appropriate authority for registration in your area.

   Top-Level Domain	Registry
   .com, .edu, .net, .org	https://www.networksolutions.com/internic/internic.html
   .us	https://www.nic.us/
   .gov (U.S. government)	https://www.registration.fed.gov/
   .mil (U.S. military)	https://www.nic.mil/
   .ca (Canada)	https://www.cdnnet.ca/
   .mx (Mexico)	https://www.nic.mx/
   Europe	https://www.ripe.net/
   Asia/Pacific	https://www.apnic.net/

   After you have registered a domain name, you can assign an IP address to the domain. If clients will be able to access your site only through HTTP, but not through FTP you can assign a host-header name in IIS 5.0 in order to associate multiple domain names with the same IP address. For details, see the "Naming Web Sites" topic in the IIS 5.0 online product documentation.

2. In the DNS Management tool, add the Domain Name System (DNS) entry for the new domain.

   For information about how to use this tool, see the Microsoft® Windows® 2000 Server online product documentation.

3. Add the IP address to the host system's Transmission Control Protocol/Internet Protocol (TCP/IP) configuration.

   Note: You may need to restart your computer in order to activate the IP address.

4. Create a home directory for the domain Web site. One option is to create it as a subdirectory of the C:\Inetpub directory.

Next, you need to create and configure an anonymous user account. This is accomplished through the Microsoft® Windows® 2000 Computer Management tool.

To create an anonymous user account

1. Right-click My Computer on the Windows desktop, and select Manage.

2. In the Computer Management tool, double-click System Tools, and then Local Users and Groups.

3. Create a Windows user account for a primary administrator of a Web site, and grant Log on locally permissions.

4. Create a new anonymous user account for the new Internet domain. An example would be: IUSR_sitename, where sitename is the name of the domain.

   This step allows you to set unique discretionary access control lists (DACLs) for the home directory of the Web site domain. For detailed information about NTFS DACLs, see the "About Access Control" topic in the IIS 5.0 online product documentation.

   Assign the following settings to the new anonymous user account:

   • User cannot change password

     Choose this option as a minor security precaution to prevent the user from changing the password on the proxy server.

   • Password never expires

     Choose this option unless you want to periodically dispose of the password and create a new one.

5. Make the anonymous user a member of the Guests group.

6. Create a new Windows global group for the domain, and add the new anonymous user to that group as well.

   In order to more easily identify which domain the group belongs to, create the group name so that it is similar to the domain name.

For detailed instructions about the Computer Management tool, see the Windows 2000 Server online documentation.

Next, set the file system and IIS 5.0 permissions.

To set permissions

1. On the home directory for the Web site, set a DACL for the global group that you have just created.

   The DACL should grant members of this group Full Control over the home directory and its contents. Figure 8.1 shows the Windows 2000 Server dialog box in which you set Full Control permission for a user or group.

   

   Figure 8.1 Dialog Box for Full Control Permission

2. Create a virtual server for the domain, granting Read permission.

3. If the virtual server will contain script programs (.asp files) that clients will be able to run, in the IIS snap-in, on the Home Directory property sheet for the server, select Scripts only in the Execute Permissions box.

4. In order to store your executable programs (.exe files) in one location, create a \Bin subdirectory, establish it as a virtual directory, and grant Execute permission.

5. Set a DACL in order to grant Read permission to IUSR_sitename for the home directory and its contents.

6. Set the anonymous user for the virtual server so that it uses the anonymous user account for the domain (which you created earlier as IUSR_sitename).

7. Set the default pages for the site in this order: Default.htm, Index.htm, Default.asp.

If you've installed FrontPage Server Extensions, you will need to create a home page (file), set up the Web site administrator, and configure the virtual server in order to publish information on the site.

To set up publishing

1. Create a file named Default.htm and add it to the home directory.

   You can indicate in this file that the site is under construction.

2. If you want to upload files to the site through FTP, create an FTP virtual directory for the virtual server.

Note: You can only do this if you have a dedicated IP address for the Internet domain. For information about uploading through FTP, see "Uploading Content through FTP" later in this chapter.

1. If necessary, create an additional user account and designate the user as a Web-site administrator.

   Do this only if you want to allow the additional user to control the IIS 5.0 configuration settings for the domain.

2. Set up the virtual server and the anonymous user as the owner/author of the site.

   For more information, see "Configuring FrontPage Server Extensions" later in this chapter.

If you want to allow a user to dial in from a remote computer, you can grant Dial-in permission.

To grant Dial-in permission

1. In the Computer Management tool, double-click System Tools, Local Users and Groups, and then Users.

2. Right-click the user to whom you want to grant Dial-in permission, and click Properties.

3. Click the Dial-in tab and, on the Dial-in property sheet, grant the user Dial-in permission.

Troubleshooting

Now that you've set up your domain site, you need to make sure it's running.

To verify that your site is running

1. Ping the IP address of the domain, using the Ping utility at the command prompt.

2. Run the NSLookup utility at the command prompt in order to find the domain name. First, type the command with the www prefix in order to see if the secondary domain name has been registered. Then, run the command again without the prefix in order to see if the top-level domain name has been registered.

   For example, at the command prompt type:

   nslookup domain.com

   And then type:

   nslookup domain.com

   This step verifies that there is a DNS entry.

   Note: The DNS entry might not be active for one or two days after the Internet domain name has been registered.

3. As a final check, view the home page in Microsoft® Internet Explorer.

Creating a Personal Web Site

This section tells you how to set up Web sites for individual users. These sites will not have their own domain names, but will have an address in this format: https://domain.com/*username*/.

The procedure for creating a personal Web site is similar to the procedure described in "Creating a Company Web Site," except that the following items will not be created:

• User groups

• DNS server entry

• Separate anonymous user account

To create a personal Web site

1. Create a Windows user account for the user who will be publishing on this Web site.

   Optionally, create an e-mail account for the user.

2. Create a home directory for the user, and set DACLs to grant the user full control over the directory and its contents.

   For detailed information about NTFS DACLs, see the "About Access Control" topic in the IIS 5.0 online product documentation.

3. Create a virtual directory for the user and grant Read and Write permissions. This step will allow the user to add content to the site.

4. If you want clients to be able to run scripts in Active Server Pages (ASP) on the site, in the IIS snap-in, on the Home Directory property sheet, select Scripts only in the Execute Permissions box.

5. If you want executable (.exe) files to be available to clients, create a \Bin subdirectory and then create a virtual directory for it, with Execute permissions.

6. Create a file called Default.htm, add it to the home directory, and indicate in the file that the site is under construction.

7. If you want users to be able to upload content to the site, create an FTP virtual server for the directory that you created in step 2.

   For details, see the "Adding Sites" topic in the IIS 5.0 online product documentation.

8. If you are running FrontPage Server Extensions, set up the virtual server, and allow the user to be an owner/author.

Restricting Content

You might need to restrict access to some of your Web sites, or to portions of them. For example, you might want to restrict most of a site's content to members only, while allowing the general public to see just a generic page containing a submission form in order to join the site. You can restrict a site's content in several ways:

• Disclose the site's URL only to those people who should have access to the site's content.

  Because this method is not completely reliable, use it only for sites that contain nonsensitive information.

• Require members to log on, by assigning each user a logon account. Create a user group for those users who are members and restrict the site's content to this particular group.

  You can also restrict content of a site simply by setting a DACL that denies access to the anonymous user, but that allows access to authenticated users.

• Set a password page that will be verified by an ASP program.

  You can set a single password for all users or you can attach it to a database. This method, however, will prevent you from setting Windows DACLs. As a result, someone knowing a URL could bypass the password (except for the ASP content, which can check within each script). For more information, see "Security" in this book.

• Require Secure Sockets Layer (SSL) with client certificates either for logon or for comparison to a database, using a script in an ASP page.

• Create your own Internet Server Application Programming Interface (ISAPI) authentication filter.

  Creating your own ISAPI authentication filter becomes more complex if you need to restrict different areas of the site to different groups of people. You can set this configuration up through an ISAPI script or a script in ASP pages, or you can create Windows accounts. For information about setting up an ISAPI filter, see the "Installing ISAPI Filters" topic in the IIS 5.0 online product documentation.

• Set DACLs on individual files within the site in order to further restrict the content to specific users or groups.

Managing Your Installation

This section discusses features in IIS 5.0 that can help you manage your installation. Here you will learn how to enhance reliability, so that your sites will continue running even when your installation is being overloaded by simultaneous user connections. You'll also be introduced to two tools, included on the Microsoft® Windows® 2000 Server Resource Kit companion CD. These tools enable you to stress test your applications before publishing them to an active server, in order to make sure they won't overload your installation. IIS 5.0 comes with three features that allow you to automate administration tasks through the sample command-line scripts and to create your own customized administration scripts. After learning how to automate administration using these features, you'll see how to leverage several additional features of IIS 5.0 and Windows 2000 Server in order to administer sites from a remote computer. The remainder of this chapter discusses ways to manage content, to create sites through FrontPage Server Extensions, to upload content to sites with FTP, and to manage sites with Microsoft® Site Server 3.0.

Enhancing Reliability

As the Internet continues to become more and more popular as a method for communication and for information retrieval, providing reliable Web hosting becomes more of a challenge. Grouping servers into a Web cluster is an effective way to enhance reliability, allowing you to manage several servers as a single unit. With your servers working together in a Web cluster, you will be able to more quickly detect and recover from server failure.

A Web cluster is any Web site that is served by more than one computer. You can set up a Web cluster by using Microsoft® Cluster Service, and then let Network Load Balancing for Microsoft® Windows® 2000 Advanced Server distribute user requests to the different servers in the Web cluster. This will prevent any one server from becoming overloaded by requests. For suggestions about setting up Cluster Service, as well as information about Network Load Balancing in a three-tier configuration, see "Building a Web Cluster" later in this chapter.

If you administer a site consisting of several servers together in a Web cluster, all of the servers need to be kept running constantly, so that connections from outside users will not be interrupted. Windows 2000 Server, IIS 5.0, and the Microsoft® Internet Information Services Resource Guide offer suggestions to help you prevent a potential overload, as well as tips about how to handle an overload, if one does occur.

This section includes information about the following:

• Windows replication and clustering

• Site Server 3.0 Content Deployment

• IIS 5.0 fault tolerance

• Network Load Balancing feature of Windows 2000 Server

• Testing applications

• Troubleshooting applications

• Process isolation

• Tips on crash recovery

Replication and Clustering in IIS 5.0

Replication consists of copying content and configuration settings from one server to another, so that both servers will be able to offer identical resources to users. You must replicate the configuration settings for all servers within the Web cluster, regardless of whether or not they share content. Content replication is unnecessary, however, if your servers share a data storage device such as a disk drive.

IIS 5.0 comes with a command-line utility for replicating the IIS 5.0 metabase from one server node to other nodes. For details about how this utility works, see the "Replication and Clustering in IIS" topic in the IIS 5.0 online product documentation.

Many clustering applications support replication of both content and configuration settings. For details, see the documentation provided with your clustering application.

Replicating through Content Deployment

The Content Deployment feature (previously known as the Content Replication System) of Site Server 3.0 allows an installation to deploy content between Web servers quickly, securely, and reliably. (This content can include files, directories, DACLs, and metadata.) The servers can be local, on a corporate intranet, or on the Internet. Typically, you would initially deploy content on a testing site or staging server, where you can test and refine content and components before publishing them. Once testing is complete, you can then move the content to a production Web server (also known as an end-point server) connected to an intranet or the Internet.

Content Deployment simplifies the staging and deploying of Web pages and other file­based information, including applications. With this feature, it is easy to deploy content between directories, among local servers, as well as across geographically remote, secure networks, to multiple end-point servers.

Content Deployment Servers

Although a single server can deploy content between directories, most Content Deployment installations are more complex, involving multiple servers that perform different functions. The following list briefly describes the functions of two types of content deployment server:

• Staging Server Receives and deploys content from content authors or from other staging servers, and can also receive content from an HTTP or FTP server during an Internet retrieval. On this server you test, or stage, the content before deploying it to end-point servers. Testing allows you to review the content and make sure that all the links are functioning properly. Once testing is complete, the staging server deploys the content, either to other staging servers at remote sites or to end-point servers.

  Each staging server can contain multiple project directories for storing Content Deployment projects. When replicating content, Content Deployment searches the project directories for all relevant content files, directories, and subdirectories, based on filters that have been applied. The feature then deploys those files to the next server.

  Staging servers operate in the Windows 2000 Server environment and should have a network or Internet connection to the other Content Deployment servers.

• End-Point Server Receives deployed content from the staging server. This server is not capable of deploying content, but it is able to respond to user requests for Web pages. The end-point server contains a destination directory, which receives deployed content. The publishing administrator identifies the destination directory when creating a project.

  End-point servers can be Windows- or UNIX-based.

  Note: UNIX-based end-point servers can only receive content that has been deployed from Windows-based servers. In addition, UNIX-based end-point servers cannot perform Internet retrievals.

Benefits of Content Deployment

Content Deployment is not a tool for authoring Web pages or other content. Rather, it moves content from one server to one or more other servers. In addition to deploying content, Content Deployment quickly, securely, and reliably deploys and installs server applications, including COM components and Java applets.

Content Deployment does the following:

1. Uses the TCP/IP protocol and Windows 2000 Server authentication in order to create secure connections among Content Deployment servers.

2. Deploys data reliably across an intranet or Internet network through sophisticated data validation.

   For example, for small sites you can move content from a staging server to a production directory on the same server. For large sites you can deploy content from a staging server to a midpoint distribution server, in order to perform a final check and test. Once the content has been approved, you can disseminate it to Windows- or UNIX-based production Web servers around the world.

   

Main Features

The following list describes the new offerings in the latest version of Content Deployment. For more information, see the Site Server 3.0 product documentation.

• Improved User Interface Globally stages and deploys content across several servers. In addition, it sets up, administers, and monitors deployments—all through the IIS snap-in.

• Same Server Deployment Deploys content from a staging directory to a production directory within the same server.

• Component Deployment Deploys server applications, such as Microsoft® ActiveX® controls and Java applets, as quickly and easily as every other type of file.

• Metabase Deployment Deploys IIS 5.0 and virtual server settings to other Web servers, allowing you to clone your Web servers quickly and easily.

• Improved Event Reporting Logs server events to a database where you can easily monitor project activity and server load for your entire site.

• Improved Performance Deploys data faster than before, over slow connections.

• Improved Content Posting Works with the HTTP Post (RFC 1867) protocol in order to accept content from clients such as Microsoft® Web Publishing Wizard, Microsoft® Internet Explorer version 3.02 or later, and Netscape Navigator 2.02 or later.

• Integration with FrontPage Detects and deploys new Web content received from Microsoft® FrontPage®.

• Integration with UNIX Deploys content to Windows 2000 Server–" and UNIX-based destination servers. The following illustration shows this type of deployment through a proxy.

  

Type of Projects

Content Deployment can replicate information by:

• Moving content.

• Moving components (files, directories, DACLs, and metadata).

• Retrieving information from the Internet or intranet.

In Site Server, these methods of deployment are referred to as projects. All three types of projects, which are discussed subsequently, move content from a source to a destination. Both the source and destination could be on a single server or could be dispersed among multiple servers at local and remote locations.

• Moving Content Stages and deploys content by moving it from one directory to another within a single server, or from one server running Content Deployment to another. The content can range from static to dynamic pages, and can include applications and databases.

  Each server involved deploying content should contain an identically named project. The publishing administrator can create these projects manually or automatically, using the project wizard.

• Moving Components Disseminates compressed application files across a network, where they can be uncompressed and automatically installed on remote servers. Content Deployment allows you to replicate active content, including Java applets and Microsoft® Component Object Model (COM) components, to all Windows servers on your site.

  Java applets and COM components are small applications that you install on your servers. Content Deployment looks at the authenticode signature in order to verify that the Java applets and COM components are safe and certifiable. It then distributes them in cabinet (.cab) files that are installed and registered when they arrive at the destination servers.

  

  To deploy components

  1. Create a project on every server involved in the deployment.

  2. Issue the Start command.

  Note: Components cannot be deployed to UNIX-based end-point servers or to Windows-based servers running earlier versions of Content Deployment.

• Retrieving Information Retrieves information from an Internet or intranet server by using HTTP or FTP protocol. Typically, the Internet or intranet server is not a Content Deployment server.

  

  The administrator creates a project on the Content Deployment server that will retrieve information over the Internet or intranet. When creating the project, the administrator references the base URL (pointing to the virtual directory where the content is stored) and specifies the crawl depth (the number of subdirectory levels under the base URL). Content Deployment will retrieve only those links and files that reside on the same Internet or intranet server as the URL.

  For example, if the administrator specifies that the HTTP retrieval should go two levels deep, Content Deployment will pull all of the content from the specified URL, plus the first level links, if those links are on the Internet or intranet server.

Clustering

Clustering allows two or more servers to appear to users as though they are one computer. The servers are connected not only physically by cables, but also programmatically through clustering software. This connection allows them to take advantage of features (such as fault tolerance and load balancing) that are unavailable to stand-alone server nodes. Clustered servers can also share disk drives that contain important information, such as a database.

If you have installed Windows 2000 Advanced Server, you already have software that will allow you to manage clustering. When linked together, Cluster Service and Network Load Balancing offer comprehensive availability and scalability for customers who are building applications with multiple tiers:

• Cluster Service gives you reliable application, transactional, file, and printing services on a two-node cluster. When combined with Microsoft® SQL Server" Enterprise Edition or Microsoft® Exchange Enterprise Edition, Cluster Service adds reliable database and messaging services to your installation.

• Network Load Balancing extends the IIS 5.0 clustering technology in several ways. For example, in a multitier application, Network Load Balancing supplies load balancing and high availability for the first tier—the user interface. Because this kind of load balancing works through TCP/IP, a variety of workloads can benefit, including the load balancing of IIS 5.0 sessions, as well as Point-to-Point Tunneling Protocol (PPTP) and Virtual Private Network (VPN) sessions. Up to 32 servers can be formed into a Web cluster. Network Load Balancing is an extraordinary solution for the most demanding Web sites in the world, such as sites that need to support tens of thousands of simultaneous connections. Microsoft Web sites, including MSN (the third-busiest Web site in the world), prove the value of Network Load Balancing every day.

While Cluster Service reinforces the availability of database and messaging applications (back end), Network Load Balancing delivers reliability to IIS 5.0 Web servers (front end). For example, on an e-commerce Web site, you can cluster your front-end Web servers that are running IIS 5.0 with Network Load Balancing, and have them access a back-end cluster that is running SQL Server Enterprise Edition.

Additional features in Windows 2000 Advanced Server make it easy to set up and manage clustering on your installation. These features include:

• Improved usability, including wizards for creating applications, setting up virtual servers, and configuring and managing clusters on your installation.

• Failover of system services, including all existing services—Web, file, print, and Message Queuing—plus support for Dynamic Host Configuration Protocol (DHCP), Windows Internet Name Service (WINS), and distributed file system (DFS).

• Orderly rolling upgrade to individual cluster nodes without taking the cluster, as a whole, offline.

• Appropriate support for Windows Management Instrumentation (WMI) and the IIS snap-in, as well as integration with Microsoft® Active Directory".

• Network adapter failure detection and forced failover.

• Plug and Play support for network adapters and disk drives (allowing hot swappable components to be replaced without shutting down the system).

All of these clustering components work together to greatly increase reliability through fault tolerance and load balancing. For details, see the "Replication and Clustering in IIS" topic in the IIS 5.0 online product documentation.

Fault Tolerance and Load Balancing

These features enhance the reliability of your installation by minimizing any potential interruption of service. If one server node stops working, another server node will immediately pick up the request load, with minimal disruption to users. Fault tolerance is made up of two components, failover and failback.

Failover transfers one server node to another node. Failback restores the load to the failed server node, after that node is back online.

Load balancing refers to two or more servers that support large amounts of activity by equalizing the request load among them. With Network Load Balancing, you can assign Web or FTP sites to a specific preferred server node, either manually or programmatically. In other words, a group of front-line Web servers would handle requests in the following manner: If an HTTP request comes through when one of the servers is already very busy processing requests, Network Load Balancing would direct the HTTP request to the idle server. In this way, you make sure users can access information quickly, even though a site is receiving a large number of simultaneous requests.

Note: Typically, you should configure clustering to enable both fault tolerance and load balancing.

Running Applications

On the Resource Kit companion CD, you'll find two tools that can further enhance reliability, by testing applications before they are made available to users. These tools are called the Web Application Stress Tool (https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx) and the Web Capacity Analysis Tool (WCAT). This section tells you how to tune your applications by using throttling processes, and gives guidelines for running applications in isolation.

Testing Applications with the Web Application Stress Tool

The Web Application Stress Tool, available on the Resource Kit companion CD, simulates having multiple browsers request pages from a Web application at the same time. By masking some of the complexities of Web server testing, the Web Application Stress Tool allows you to focus on gathering performance data on a Web site. This version of the Web Application Stress Tool offers the most up-to-date features for stress testing three-tier personalized Web sites that contain ASP pages and that run on Microsoft® Windows® NT Server version 4.0 and Windows 2000 Server. For more information about three-tier sites, see "Building a Web Cluster" later in this chapter.

The following list highlights some of the features offered by the Web Application Stress Tool. These features allow you to:

• Create scripts by hand, by recording browser activity, by pointing to an IIS 5.0 log file, or by selecting files in your content directory. For details, see the Web Application Stress Tool documentation included on the Resource Kit companion CD.

• Run a test script with any number of client machines, all of which are controlled from one centralized master client. The Web Application Stress Tool handles the allocation of threads and users, and collects report data from all computers.

• Control Web stress tests from a remote location through either the C++ or the ASP version of the Web Application Stress Tool client.

• Create multiple users so that authenticated and personalized Web sites can be accurately stress tested.

• Personalize realistic test scenarios. By default, support for ASP sessions allows cookies to be associated with users.

• Log off the client without interrupting a test, because the Web Application Stress Tool runs as a Windows service.

• Simulate modem throughput and increase the number of concurrent users, utilizing the Web Application Stress Tool's built-in bandwidth throttling.

• Customize your own stress run by using the stress templates provided with the Web Application Stress Tool. These templates change the number of users who are requesting pages on a site, simulating real-life site activity.

• Import, store, and edit complex query-string name-value pairs by using the query-string editor.

• Use the object model in order to create your own test client. By exposing all of the properties, methods, and constants, you can customize your own interface.

• Assign the IP address or DNS name of a specific server to make the Web Application Stress Tool round-robin among the servers in your cluster.

• Test for racing conditions, because the Web Application Stress Tool contains a delay between requests that is changeable.

• Complete online definition help using expert discussions about stress testing techniques.

• Customize all your test data, which the Web Application Stress Tool stores in a Microsoft® Access database.

Testing Applications with WCAT

WCAT, available on the Resource Kit companion CD, simulates various workloads on client-server configurations. Using WCAT, you can test how your IIS 5.0 and network configurations will respond to different client requests for content, data, or HTML pages. With the results of these tests, you can determine the optimal server and network configurations for your computer. For more information about WCAT, see "Monitoring and Tuning Your Server" in this book, and the WCAT documentation available on the Resource Kit companion CD.

Because Web servers are vulnerable to overload, it is crucial to virtually stress your Web server before rolling it out into a production environment. Since your server might be idle one minute, but then might suddenly receive 10,000 simultaneous requests, you should stress your application in order to see how it will react in an overloaded environment. When running stress on an application, increase the number of requests, starting at 100 and going as high as 100,000. You can then use System Monitor to see the effects that the stressed application is having on the server. Make any necessary changes to ensure the availability of your application.

The next section briefly tells you how to run a WCAT script, how the script can test a sample workload on your site, and how to interpret the results.

Running a WCAT Script

A WCAT script is split across three files, as shown in Table 8.1:

Table 8.1 Distribution of Files

File Name	Type of File	Contents
Script.cfg	Configuration file	The number of clients, the number of threads, the duration of the run, and so on. You can overwrite most of this information on the command line.
Script.dst	Distribution file	A collection of pairs (ClassID, Weight). The class IDs come from Script.scr. The Weights should add up to 100.0.
Script.scr	Script file	One or more transactions, each identified by a class ID. A transaction is one or more GETs or POSTs and an associated set of headers and other attributes to be sent to the server.

A large collection of sample scripts is available in the Scripts subdirectory.

To run a WCAT script

1. On the client computer(s), type the following at the command prompt:

cd \wcat\client client.bat

If the client computer(s) are correctly configured to point to the controller (not the server), you don't need to do anything more to the client(s).

2. On the Controller, type the following at the command prompt:

cd \wcat\control run.cmd some-script [parameters]

**Note:** To see a full list of parameters, type **wcctl -?** at the command prompt.

Checking Performance Counters

After running a WCAT script, you should check the WCAT log file. You can also check the counters in the System Monitor of Windows 2000, which graphically displays the results of running WCAT. For details about System Monitor and for a description of the counters, see "Monitoring and Tuning Your Server" in this book. In addition, see the "Counters Reference" topic in the IIS 5.0 online product documentation.

Interpreting the Results

WCAT writes copious details to the .log file. The line in the log file that is most useful to administrators is Pages Read, which displays the following information:

• The first numeric column displays the total number of pages read by all client machines.

• The second column shows the rate of pages per second seen by the first client machine.

• The third column shows the total number of pages seen by the first client machine.

If you have more clients, you will see the rate and total numbers for each machine in subsequent columns.

WCAT Troubleshooting

The following tips will help you to gain the maximum performance benefit from WCAT:

• Because WCAT assumes that all clients are the same, and because it is also unable to recognize HTML code, you must spell out the contents of framesets and image URLs explicitly in your transactions, by clustering them under one class ID.

• If performance suddenly improves, verify that an error has not occurred.

• Turn off IIS logging while stressing your applications; otherwise, you'll receive huge logs full of useless data.

Testing Conditions

This section gives you tips about how to test the performance of your applications and how to stress them before making them available on the Internet or on an intranet. With these tips, you can monitor an application's maximum performance and also see how much of a load the application can take before it breaks.

Performance Testing

In order to test a Web application's maximum possible performance, you'll need the following:

• An isolated private network

• Enough clients to saturate the server

• At least 100 megabits per second (Mbps) of network bandwidth

• Several network adapters to distribute the load

• A multiprocessor machine for scalability testing

First, test the pages with your browser in order to verify that the application is running correctly.

Note: You will need to rerun tests in order to verify that results are reproducible.

Because you don't run an application in a vacuum, maximum performance is not always what you want to test. For example, you might also want to know how well your application performs under an average load, coexisting with other Web sites and other non­Web applications on the server. To test for average performance, set some goals for the application and see if it can meet them. For example:

• More than 20 pages/second

• Less than 50 percent capacity utilization of CPU

• Less than 10 seconds response time

Stress Testing

For high-stress testing, as mentioned earlier, you need a private network and a collection of client machines. But for average stress testing, you might not necessarily need a private network and lots of clients. Putting your application under a moderate load is often enough to expose bugs. Therefore, running the controller and a client on the server will suffice. Finally, running stress tests on a multiprocessor computer is a great way to find threading bugs.

Running Applications in Isolation

Once you've tested your applications and are satisfied with their performance, you're ready to make them available on the Web. IIS 5.0 allows you to run applications in one of two ways: in process or out of process (in isolation). Process isolation allows multiple Web applications to run on one Web server without crashing, by running each application that is on the server in a separate memory space (out of process).

The advantage of running everything out of process means that if one application fails, it won't cause the others to fail. The disadvantage is that this adds an extra step when diagnosing problems. Despite the disadvantage, it is recommended that you run an application out of process when you're not sure of its integrity.

In the IIS 5.0 architecture, all the IIS services run in the Inetinfo process. (You can look at this process by opening the Task Manager and clicking the Process tab.) When you run an application out of process, you will find an associated Mtx.exe process in the Task Manager. (For example, if you were running 10 applications out of process, you would find 10 separate Mtx.exe files.) If your application fails, the associated Mtx.exe fails, leaving either the Inetinfo process or your Web server intact. Once you're confident that the application is reliable, bring it into the Inetinfo process by clearing the Run in own memory space check box, which can be found in the application's property sheets.

Running applications out of process is an important feature for ISPs because many of their customers want to use custom components. If these components are run in process, it is common to see that the Inetinfo process is exceeding normal performance parameters and, as a result, to falsely assume that IIS 5.0 is running poorly. But in reality the poor performance is usually caused by a custom component that is leaking memory. Had that component been run in its own memory space first, the associated Mtx.exe would have reflected the performance cost. The solution, accordingly, would have been to end the Mtx.exe process, not the Inetinfo process.

It can strain your computer's resources to run applications out of process, since doing so takes away resources from the Web server. Despite this drawback, it is best to initially run new applications out of process to make sure they are stable and meet your requirements. Once you have done that, you can then safely run them in process.

Here are some guidelines on running various types of applications in and out of process.

• Common Gateway Interface (CGI) applications are run out of process, but they offer poor scalability. In other words, every instance of a CGI application requires the creation of a new process with its associated overhead, and application parameters are passed through environment variables.

• ISAPI applications can also be run out of process. When you do this, you'll attain the same level of application integrity as CGI applications, but with faster performance. You can further improve performance by running ISAPI applications in the same memory space as the server (in-process). Remember that in-process applications don't yield as much application integrity as those run out of process.

• Some ISAPI dynamic-link libraries (DLLs) can't be isolated. Examples include DLLS that rely on locking resources, such as open files, shared memory, and so on. In such cases, you should rewrite the application to remove the dependencies.

• An individual server can host a mix of in-process and out-of-process applications. With this mix, you can run well-tested applications in-process for faster performance, and run others out of process during development or beta stages for "fail-safety" reasons.

  Note: While both ISAPI and ASP process isolation are managed through Microsoft® Component Services, process isolation is managed through the IIS snap-in.

Out-of-Process Application Pooling

With IIS 5.0, ASP applications run in an out-of-process application pooling by default. When you create a virtual directory with the wizard in the IIS snap-in and then create applications to run in that directory, the applications will run in a separate process from IIS 5.0. The separate process is a special COM+ application, of which each pooled ASP application is a component.

The following guidelines will help you determine when to run applications in the pool for maximum stability and performance:

• If you're running 20 or fewer applications, run them out of process.

• If you're running 21 or more, add them to the pool.

• Run a stateful application out of process.

• If you're running 20 or more applications, some stateful and some stateless, run the stateful ones out of process and add the stateless ones to the pool.

You can set the pooling parameter in the IIS snap-in, or through Adsutil.exe on the command line. For details about pooling and for procedures, see the IIS 5.0 online product documentation.

Hosting Applications

ISPs often establish preproduction sites (or staging servers) to test customer applications before they are hosted on the production site. (For more information about staging servers, see "Replicating through Content Deployment" earlier in this chapter.) During this test phase, you can save resources by using one server to host multiple customer test sites.

ISPs hosting Web-based applications should establish guidelines for those who are writing them. For example, it is not good to write applications that can be run only in process, since those that can be run out of process are safer for the installation as a whole.

Recovering from Crashes

Even after rigorous testing, it's still possible that, at one time or another, an application will fail when it's run on a production Web server. To handle crashes and still protect data, IIS 5.0 offers two convenient ways of recovering when the Component Services environment hosts applications (ISAPI and ASP applications running out of process, for example):

• If a fatal application error occurs, the process is terminated automatically.

• If a transactional application crashes, all transactions in progress are stopped and any changes to the data are rolled back.

  The Windows® Event Log stores a record of the error that occurred, and the run-time Component Services environment automatically restarts the application process. In this way data is protected and the application can be rerun.

Automating Administration

Administering Web sites can be time consuming and costly, especially for people who manage large ISP installations. Consequently, many ISPs support only large, company Web sites, at the expense of personal Web sites. Nevertheless, a cost-effective way to support both would be to automate administrative tasks and let users administer their own sites from remote computers. This solution reduces the amount of time and money it takes to manually administer a large installation, without reducing the number of Web sites supported. IIS 5.0 offers three technologies that help you automate administration:

• Microsoft® Windows® Script Host (WSH)

• IIS Admin Objects

• Microsoft® Active Directory Service Interfaces" (ADSI)

With these three technologies, you can administer sites from the command line of a central computer, as well as group frequently used commands in batch files. All you need to do is run the batch files to add new accounts, change permissions, add a virtual server to a site, and so forth.

In this section, you'll learn how to carry out basic administrative tasks, by running the sample ADSI scripts installed with IIS 5.0. These scripts can give you faster, more cost­effective administration. For example, you'll see how to create a new virtual directory on a remote server and then change that directory's write access. You'll also see sample custom scripts that can change Windows permissions on a server.

ADSI sample scripts and the WSH environment are installed by default, when you install Windows 2000 Server and IIS 5.0. Although the sample scripts are fully functional, they also serve as templates from which you can create your own scripts.

For detailed information about WSH and ADSI scripts, see the "Administration Scripts" topic in the IIS 5.0 online product documentation.

Windows Script Host

WSH is a language-independent scripting environment for 32-bit Windows platforms. Microsoft offers both Visual Basic® Scripting Edition (VBScript) and JScript® scripting engines with WSH, while third-party companies supply ActiveX scripting engines for other languages, such as Perl.

WSH can automate administrative tasks on a server. For example, an administrator can write a program in VBScript that will create a new virtual directory. With WSH, the script file can then be run from the command line, in order to create a new virtual directory on the Web site. In addition, an administrator can write a single script that will target multiple Web sites or multiple physical servers. For more information, see the Windows Script Host material in the Windows documentation.

IIS Admin Objects and ADSI

The IIS Admin Objects installed with IIS 5.0 make programmatic administration straightforward. Based on ADSI, these objects are compatible with automation and, as a result, can easily be accessed and manipulated by any language that supports automation, such as VBScript or JScript, Microsoft® Visual Basic®, Java, or C++.

When you install IIS 5.0, the sample IIS Admin Objects scripts are copied into the Inetpub\AdminScripts directory by default.

You can use these sample scripts to configure your IIS 5.0 installation, to create virtual directories, to display information about a Web site (see the example in the following section), or to manage the status of Web sites by stopping, pausing, and starting IIS.

In addition to using the sample scripts as they are, you can customize them by extrapolating from the annotated examples. With custom scripts, you can administer your IIS 5.0 configuration by changing the settings stored in the metabase. The structure of the metabase parallels the structure of your IIS 5.0 installation, and the property inheritance feature of the metabase allows you to set up IIS 5.0 configuration settings in an efficient manner.

For details about ADSI objects, see the "ADSI Object Methods" topic in the IIS 5.0 online product documentation.

Executing Scripts

Adsutil.vbs, an administration utility installed with Windows 2000 Server and IIS 5.0, runs on VBScript in conjunction with ADSI. Use Adsutil.vbs together with Cscript.exe, which is installed with WSH, in order to manipulate the IIS 5.0 configuration.

You can execute an administration script by typing the appropriate syntax on the command line. The following example shows the current settings for the root of the default Web site:

cscript.exe inetpub\adminscripts\adsutil.vbs enum w3svc/1/root

To execute any other script on the command line, type:

Cscript.exepath\ScriptName

Instead of typing the syntax on the command line, you can type it in a batch (.bat) file, and execute your scripts from there. If you execute the same script repeatedly, putting it into a batch file will save you from having to retype the script every time you want to run it.

If you've added the path to the Inetpub\AdminScripts directory, you don't have to type the full path to Cscript.exe. For information about editing your path, see the Windows 2000 Server online documentation.

Note: If you have registered Cscript.exe as your default scripting host, you don't have to type Cscript.exe in front of the scripts to execute them. (To learn how to register Cscript.exe, see the first two steps in the next section.)

Examples

The following examples show you how ADSI scripts can automate tasks that ISPs must perform repeatedly. For a detailed explanation of the script syntax, see the IIS 5.0 online product documentation.

The first two examples assume that you've already set the path to the administration scripts within the Windows environment, or that you are running the scripts in the C:\Inetpub\AdminScripts directory, where they reside. The following procedure tells you how to set the path to the administration scripts.

To add a path to the Windows environment

1. On the Windows 2000 Desktop, right-click My Computer.

2. Select Properties.

3. On the System Properties dialog box, click the Advanced tab.

4. Click the Environment Variables button.

5. In the System Variables box, select the line beginning with the word "path."

   

   Figure 8.2 Dialog Box for Environment Variable

6. Click the Edit button.

7. In the Edit System Variable dialog box, put the cursor at the end of the line in the Variable Value box.

8. Type the following to add the path to the sample ADSI scripts:

;C:\Inetpub\AdminScripts

**Note:** Each element in the path variable must be separated by a semicolon, which explains this initial punctuation.

Changing Permissions

This example shows you how to change permissions for a virtual directory located on a different server. Suppose you want to grant Write permission on a virtual directory called Test. The Web site is on your company's intranet on a computer named Server2, located in another building. Instead of walking over to the other building, you prefer to make this change from the computer (Server1) in your office.

To change permissions for a Web site on another server

1. On your administration server, open a command prompt.

2. Type adsutil and accept the defaults in order to register Cscript.exe.

   If you don't want to register Cscript.exe (because you are running another scripting host by default), you have to type Cscript.exe in front of the script you want to run. See the example in the previous section, "Executing Scripts."

3. At the command prompt on Server1, type the following line:

Adsutil set w3svc/1/root/test/accesswrite "true"-S:server2

**test** is the virtual directory on which permissions are reset.

**accesswrite** changes Write permissions.

**true** grants Write permissions.

**-S:server2** is the server where the Web site is located.

Users can now upload files to the virtual directory Test on Server2.

Creating a Web Site

This example creates a new Web site with the sample ADSI scripts. Suppose you want to create a Web site on your production Web server for a new client that you will be hosting. The repetitive work of creating site after site can easily be automated by running the Mkw3site.vbs script.

Once you've set the path, as explained earlier, you can create a Web site.

To create the Web site

1. On your administration server, open a command prompt.

2. If you have not registered Cscript.exe, register it as described in step 2 of the previous example.

3. At the command prompt on the server, type the following line:

   mkw3site -r c:\webs\customer1 --DontStart -t "Customer 1 Site" -o 80

   -i 172.16.100.1

   mkw3site includes the script to make the Web site.

   –"r is the root directory of the Web site.

   –"DontStart creates the Web site in a stopped state. To start it, you must activate it through the IIS snap-in, or from the command line by typing net start w3svc.

   –"t defines the title of the Web site.

   –"o defines the port number.

   –"i defines the IP address for the Web.

Customizing Scripts

The following sample ASP pages show you how to set up customized scripts. The first deals with setting permissions in general, while the second shows you how to set up a virtual directory with Read, Script only, and Directory browsing permission.

Web server permissions control how users access and interact with specific FTP and Web sites. For example, permissions determine whether users visiting a Web site are allowed to see a particular page, upload information, or run scripts on the site. Unlike NTFS permissions, Web server permissions apply to all users accessing a Web or FTP site. This distinction is very important, because NTFS permissions apply only to a specific user or group of users with a valid Windows account.

The following example contains customized scripts that set permissions on a virtual directory in two ways:

• GET/PUT notation Choose this type for script that contains variables.

• Dot notation Choose this type for hard-coded scripts.

The example also shows how inheritance works. In the first part, the GET/PUT notation denies Write permission (sets it to FALSE) from the root level of the default Web site on MyComputer. When you set permissions at the root level, all directories below the root level inherit this setting. However, the dot notation (the second part of the example) grants Write permission (sets it to TRUE) on the virtual directory named VDir1a, overwriting the inherited setting that is at the root level.

<%
Dim WebServerRootObj
Dim VDirObj
Dim WritePerm
'Open the object for the first virtual Web server root.
Set WebServerRootObj = GetObject("IIS://MyComputer/W3SVC/1/Root")
'Deny write access for all directories and files
'for the server (except those already specifically set)
'Using the Put method.
WebServerRootObj.Put "AccessWrite", False
'Save the changed value to the metabase.
WebServerRootObj.SetInfo
'Get a directory subordinate to the Web server root.
Set VDirObj = GetObject("IIS://MyComputer/W3SVC/1/Root/Vdir1/VDir1a")
'Overwrite the inherited value for write access
'Using the dot method equivalent to Put.
VDirObj.AccessWrite = True
'Save the changed value to the metabase.
VDirObj.SetInfo
%>

The next example shows a customized script that creates a virtual directory with Read, Script only, and Directory browsing permissions.

<%
'''''''''''''''''''''''''''''''''
'ADSI ASP Sample Program.
'This is a sample of how to create a virtual directory using ADSI.
'
'''''''''''''''''''''''''''''''''
Option Explicit
On Error Resume Next
'''''''''''''''''''''''
'First, open the path to the Web server you are
'trying to add a vdir to.
Dim ServObj
Dim VdirObj
Dim Testpath
Set ServObj = GetObject("IIS://LocalHost/w3svc/1/Root")
if (Err <>0) then
Response.Write "GetObject (""IIS://LocalHost/w3svc/1/Root"") Failed! <BR>"
Response.Write "Error! " & Err.Number & "(" & Hex(Err.Number) & "): " & Err.Description & "<BR>"
Response.End
end if
'''''''''''''''''''''''
'Second, Create the vdir path.
Set VdirObj = ServObj.Create("IIsWebVirtualDir", "MyVdir")
VdirObj.SetInfo
if (Err<>0) then
Response.Write "CreateObject (""IIS://LocalHost/w3svc/1/Root/MyVdir"") Failed!<BR>"
Response.Write "Error! " & Err.Number & "(" & Hex (Err.Number) & "): " & Err.Description &
"<BR>"
Response.End
end if
''''''''''''''''''''''''
'Finally, create a Path variable containing the VR path and
'set the permissions to read, script, and directory browsing.
VdirObj.AccessRead = True
VdirObj.AccessScript = True
VdirObj.EnableDirBrowsing = True
Testpath = "C:\Temp"
VdirObj.Put "Path", (Testpath)
VdirObj.SetInfo
if (Err<> 0) then
Response.Write "Put (""Path"") Failed!"
Response.Write "Error! " & Err.Number & "(" & Hex (Err.Number) & "): " & Err.Description &
"<BR>"
Response.End
end if
Response.Write "VDIR successfully created"
''''''''''''''''''''''''
'The minimum amount necessary to create a virtual directory has now
'been completed. If you need to add more, do it here.
%>

For more sample scripts and for details on writing your own scripts, see the "Programmatic Administration Examples" topic in the IIS 5.0 online product documentation.

Administering a Site Remotely

With IIS 5.0 and Windows 2000 Server, you can administer a server from a remote computer. IIS 5.0 supplies three methods for administering sites remotely: the IIS snap-in, Internet Services Manager (HTML), and IIS Admin Objects working in conjunction with ADSI scripts. Under Windows 2000 Server, you can administer servers remotely through Microsoft® Windows® 2000 Terminal and Telnet Services.

IIS Snap-in

Windows 2000 Server comes with an Administration Tools package, which you can install on a computer that is running Microsoft® Windows® 2000 Professional. You can then set up the IIS snap-in on the remote computer, connect to an IIS 5.0 server, and administer IIS 5.0 through the snap-in. You can perform any IIS 5.0 administrative task on the remote server that you could if you were actually there. For details about how to handle administrative tasks through the IIS snap-in, see the IIS 5.0 online product documentation.

Internet Services Manager (HTML)

With Internet Services Manager (HTML), you can administer your Web installation over an intranet or the Internet. Although you can't perform all the tasks you can with the IIS snap-in, you can change access privileges, create Web sites, read log files, check or change properties. You can also start, stop, or pause servers from any computer on the network that is running Microsoft® Internet Explorer 5. Figure 8.3 shows the Internet Services Manager (HTML).

Figure 8.3 Internet Services Manager (HTML)

For details about how to handle administrative tasks through the Internet Services Manager (HTML), see the IIS 5.0 online product documentation.

Command Line

Based on Microsoft's ADSI, the IIS Admin Objects simplify command-line administration through automation. Using these features, you can perform many administrative tasks remotely. Possibilities include the following:

• Creating new FTP and Web sites

• Creating virtual directories

• Changing properties and permissions on Web sites and virtual directories

In addition, you can write your own ADSI scripts in order to customize administrative tasks.

Terminal Services

Although you can remotely manage IIS 5.0 Web sites from the IIS snap-in or the Internet Services Manager (HTML), you cannot perform Windows 2000 administrative tasks through them. However, with Terminal Services, you can administer a Windows 2000 Server as well as IIS 5.0 from a remote computer.

Terminal Services was originally created so low-powered machines (thin clients) could run applications that required more resources than the computer could offer. For example, you could run Microsoft® Office 2000 applications on a computer that is running Microsoft® Windows® version 3.1. But with Terminal Services client software installed, a client computer can connect to a computer that is running Windows 2000 Server (with Terminal Services server software), and run these applications through the server.

To install Terminal Services, you must select it when installing Window 2000 Server. Once the server is set up, you can install the client software on a computer that is running Windows 2000 Professional, Microsoft® Windows® 98, or even a 16-bit version of Windows such as Windows 3.1. From the client, you connect to the server through a local area network (LAN), PPTP, or dial-up connection and perform any administrative tasks you want, even though the server you're administering may be halfway around the world.

In addition to setting DACLs and performing other Windows 2000 administrative tasks, a Terminal Services client can administer IIS 5.0 remotely through the IIS snap-in. First, connect the client to the Windows 2000 Server. Next, mirror the server's desktop and the IIS snap-in on the server. Through the snap-in, you can perform any IIS 5.0 administrative task on the remote server that you could if you were actually at the site. For example, you can create Web sites, change access permission, or administer IIS 5.0 security. You can basically do anything that you could with the IIS snap-in.

For detailed information about Terminal Services, see the Windows 2000 Server online documentation.

Telnet

Remote administration through a Telnet client and server lets you remotely log on to and execute commands on operating systems based on Windows 2000 or UNIX. Microsoft® Telnet Service logs remote clients onto a server as though they were connected to the server directly through a local terminal. Telnet Service works like a basic TCP/IP Telnet Server. A computer running the Telnet Server tool under Windows 2000 Server can support connections from various TCP/IP Telnet clients, including UNIX-based and Windows-based computers.

The remote administration feature of Telnet lets users log on to UNIX-based and Windows-based computers in another location and execute commands on them. Telnet Service is now part of the Windows 2000 Services for UNIX. You can download Telnet from the Microsoft Web site, at https://www.microsoft.com/.

When you download and install Telnet, a Telnet client is installed in the Accessories folder. The Telnet client connects to another computer that is running a TCP/IP-based Telnet server.

The Telnet Server tool can execute commands (such as TCP/IP tool or Microsoft® MS­DOS® commands) in the command-prompt window. Here's how the command process works:

1. Once logged on to a Telnet server, you can enter a command at a remote Telnet client computer.

2. The Telnet server sends the results of the command back to the remote Telnet client computer.

Each Telnet-client session started on a Telnet server is allocated a console session, which doesn't interfere with any local-user sessions on the server. At the start of a session, the remote Telnet client must send a user name and password to log on to the Telnet server. This user name and password create a connection with the security attributes of the user.

For example, you can:

• Log on to a computer running Windows 2000 Professional and the Telnet client.

• Start the Telnet client.

• Connect to a computer running Windows 2000 Server and the Telnet Server tool.

• Run command-line scripts to add users, services, and so on.

For more information about Telnet service, see "Telnet Server Admin Utility" in the Windows 2000 online documentation.

Turning Users into Web Site Operators

Delegating administrative rights to your customers can present a security challenge. To meet this challenge, you have to make sure that each customer can administer only his or her own site. For ISPs who are hosting multiple sites on a single server, the Web site Operators feature of IIS 5.0 is the ideal tool for this. Web site Operators are Windows user accounts that have limited administration privileges on a Web site.

With this feature, you can give individual site administrators complete control over the properties, applications, and security of their site—without jeopardizing the security or configuration of other sites running on the same server. A Web site Operator cannot change bindings or port numbers, configure the anonymous user name and passwords, change the identification of the Web site, throttle bandwidth, change accounts on the server, add virtual directories, configure process isolation or ISAPI filters, or stop, pause, or restart a site.

For more information see "Assigning Web Site Operators" in the IIS 5.0 online product documentation.

Configuring FrontPage Server Extensions

This section tells you how to set up and configure FrontPage Server Extensions. You'll learn how to properly structure newly created virtual servers for FrontPage and how to transfer content from one server to another. You'll also learn how to set Windows 2000 and IIS 5.0 permissions that work compatibly with FrontPage Server Extensions. Finally, you'll see tips on how to properly configure e-mail to work with forms created in FrontPage Server Extensions.

Although FrontPage offers most of the same features as FrontPage Server Extensions, you must install the FrontPage Server Extensions on your production Web server in order for the following to work:

• Confirmation Field

• Discussion Form Handler

• Guest Book

• Registration Form Handler

• Save Results Form Handler

• Scheduled Image

• Scheduled Include Page

• Search Form

• Live Authoring

Introducing the FrontPage Snap-in

The FrontPage snap-in is a Windows 2000 interface similar to the IIS snap-in. While the IIS snap-in allows you to administer IIS 5.0, the FrontPage snap-in allows you to administer FrontPage Server Extensions and FrontPage-extended webs. A FrontPage web is a project containing all the pages, images, and other files that make up a Web site.

Since the FrontPage snap-in appears in the IIS snap-in, commands, property sheets, and other tools required to administer FrontPage Server Extensions are added to the IIS snap-in shell.

To access the FrontPage snap-in

1. On the Windows Toolbar, click Start, and then click Programs.

2. Click Administrative Tools, and then click Internet Services Manager.

You can verify that the FrontPage snap-in is installed by right-clicking the Default Web Site in the IIS snap-in and selecting All Tasks. Under All Tasks, you'll find FrontPage administration commands. If the Server Extensions are not installed on the Default Web Site, you will see the command ConfigureServerExtensions. If they are installed, you will see the following FrontPage administration commands: Check Server Extensions, Open With FrontPage, Recalculate Web, and Remove Server Extensions.

The FrontPage snap-in replaces and significantly improves upon the Fpsrvwin utility, an administrative program that was included with previous versions of FrontPage. The FrontPage snap-in's capabilities are similar to those of the Fpsrvwin, Fpsrvadm, and Fpremadm utilities.

With the FrontPage snap-in, you can do the following:

• Extend a virtual server with FrontPage Server Extensions

• Check and fix FrontPage Server Extensions on a web

• Upgrade FrontPage Server Extensions on a web

• Remove FrontPage Server Extensions from a web

• Delete a subweb (virtual directory under a FrontPage web) that has been extended with FrontPage Server Extensions

• Convert a subweb into a folder, and vice versa

• Recalculate all hyperlinks in a web

• Add an administrator

• Enable or disable authoring on a web

• Tune web performance

• Log authoring operations

• Require SSL for authoring

• Specify that a folder can contain executable scripts or programs

• Enable source control

• Set e-mail options

There are only two things that you can't do with the FrontPage snap-in:

• Administer the FrontPage Server Extensions from a remote computer

• Perform command-line scripting

For command-line scripting, use the Fpsrvadm utility, and for remote administration, use the HTML Administration Forms or the Fpremadm utility. All of these components are installed in the following directory by default: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40 Folder. For information about configuring these utilities, see the Microsoft® FrontPage® 2000 Server Extensions Resource Kit at https://officeupdate.microsoft.com/frontpage/wpp/serk.

You will know FrontPage Server Extensions are enabled if you right-click on a virtual server, select All Tasks, and see either Configure Server Extensions or any of the commands associated with a server that already has the extensions installed, like Check Server Extensions or Recalculate Hyperlinks. If you do not see these commands, enable the extensions.

To enable FrontPage Server Extensions

1. Click Console and then click Add/Remove Snap-in.

   If the Console menu shows only the Options item, choose Options, and select Always open console file in author mode. Click OK, and exit the IIS snap-in. Reopen it, and from the Console menu, select Add/Remove Snap-in.

2. Select the Extensions tab, and make sure FrontPage Server Extensions is selected.

3. If it is not selected, click the FrontPage Server Extensions check box, and click OK.

Managing Content

When creating and transferring FrontPage content, there are a few tips you should keep in mind. This section teaches you how to successfully move content from one server to another. It also tells you how to configure any content you might want to nest among virtual servers.

Transferring Content

The FrontPage Publish command transfers FrontPage content from one FrontPage-extended web server to another through HTTP. All of the functionality of installed FrontPage components is also transferred.

However, if you choose another method of publishing or transferring the content, such as FTP, Windows Copy command, or Site Server's Content Deployment, the FrontPage components will not be functional until you run FrontPage Recalculate Web on the production Web server. This command enables the FrontPage Server Extensions on the production Web server to parse the content and to recognize FrontPage components. If the _vti directories from the source server are also copied by FTP, you may need to remove the FrontPage Server Extensions and reinstall them on the destination server.

Because the _vti directories contain server-specific information, transferring them from one server to another (by copying or replicating content) moves the configuration information from one server to a new server, where the information might not apply. If this happens, FrontPage will not work. Should you encounter this problem, remove and reinstall the Server Extensions on the new server.

Nested Content

Before installing FrontPage Server Extensions, make sure you do not have content nested in overlapping virtual servers. Virtual server directories should not be configured under the root directory for another server.

For example, because the following configurations contain nested directories for the virtual servers, they will not work with FrontPage Server Extensions.

Example 1: Server running on Windows 2000

Default Site C:\Inetpub\wwwroot
Virtual Server 1 C:\Inetpub\wwwroot\virsvr1
Virtual Server 2 C:\Inetpub\wwwroot\virsvr2

Example 2: Server running on UNIX

Default Site /usr/local/www
Virtual Server 1 /usr/local/www/user1
Virtual Server 2 /usr/local/www/user2

If you have configured your virtual servers as in the examples, you must reorganize them in order for FrontPage Server Extensions to work properly.

Changing the Root of a Web Site

To change the root of an IIS 5.0 Web site with FrontPage Server Extensions

1. Uninstall FrontPage Server Extensions.

2. Change the document root.

3. Reinstall FrontPage Server Extensions.

   Note: When you change the document root directory in IIS 5.0, you must also reset the permissions on that directory.

FrontPage 2000 now administers permissions at the content root level. Therefore, if you remove and reinstall FrontPage Server Extensions, your permissions are not lost. When you install them, FrontPage assigns the following permissions on the content root:

Type of User	Level of Permission Assigned
Site visitor	Read, Execute
Author	Read, Execute, Write, Delete
Administrator	Read, Execute, Write, Delete, Change Permissions

Overlapping Virtual Servers

You cannot install FrontPage Server Extensions onto a virtual server that overlaps another virtual server (nested virtual servers). If you try to install them, you'll get the following error message:

Unable to create a web for the url "/" because its root directory, "c:\Inetpub\wwwroot\web", falls below the root of another web in the directory "c:\Inetpub\wwwroot".

Overlapping Configurations

The following examples show overlapping configurations:

Example 1

C:\Inetpub\wwwroot\ [Default Web site on IIS]
C:\Inetpub\wwwroot\virtualserver1\
C:\Inetpub\wwwroot\virtualserver2\

Example 2

C:\Inetpub\wwwroot\
C:\Inetpub\webs\virtualserver1\
C:\Inetpub\webs\virtualserver1\virtualserver2\

Example 2 shows virtual servers in different directories with an overlapping configuration.

If you have a configuration like one of these, reconfigure it so that virtual servers do not overlap, before you install FrontPage Server Extensions.

Nonoverlapping Configurations

The following examples show configurations on which you can install FrontPage Server Extensions:

Example 1

C:\Inetpub\wwwroot\
C:\Inetpub\virtualserver1\
C:\Inetpub\virtualserver2\

Example 2

C:\Inetpub\wwwroot\wwwroot2\ [Default Web site remapped to \wwwroot2]
C:\Inetpub\wwwroot\virtualserver1\
C:\Inetpub\wwwroot\virtualserver2\

Example 3

C:\Inetpub\wwwroot
C:\webs\virtualserver1\
D:\websites\virtualserver2

Example 3 shows how to configure your virtual servers in different directories without any overlapping.

Setting Security on an IIS 5.0 Server

Because FrontPage Server Extensions has no security of its own, you have to set up IIS 5.0 security to work with FrontPage. If IIS 5.0 isn't configured correctly, someone without authorization could edit a FrontPage web without being challenged for a user name and password.

IIS 5.0 uses Windows NTFS permissions in order to enforce security. Because FrontPage borrows the security mechanism of the Web server it is extending, you have to configure IIS 5.0 security in conjunction with NTFS permissions. For information about how IIS 5.0 authenticates a user, see "Security" in this book.

Resecuring a Site

This section tells you how to restore security, if you've determined that unauthorized users are able to log on to a Web site by using the IUSR_computername. Without examining a specific problem and configuration, it's hard to make generalizations. However, the following troubleshooting procedure suggests a way to tighten security on a site.

To resecure a site

1. If your server is configured with nested content or overlapping virtual servers, fix those problems first.

2. If the IUSR_computername account is a member of the Administrators group, remove it from the group. No anonymous user should have administrator privileges.

3. In FrontPage, on the Tools menu, select Security and then Permissions.

4. On the Permissions property sheet, if the Everyone group is listed, remove it, and click OK.

5. Reopen the Permissions property sheet, and on the Users tab, select Everyone has browse access.

   The IUSR_computername account is a member of the Everyone group, and should not be a member of any group that has Author access. If Permissions on the Tools menu is grayed out, you are on a file allocation table (FAT) partition. You must store Web content on an NTFS partition in order to have FrontPage security.

   If the IUSR_computername account can still open the Web site, see step 6.

6. For the root Web site and all its sub-webs that use unique permissions, set Only registered users have browse access on the Permissions property sheet.

   Similar to a directory hierarchy, a sub-web is a site under a main Web site.

7. To tighten security, open the IIS snap-in, right-click the virtual server, click Tasks, click Check Server Extensions, and select Yes.

8. Open the FrontPage web. (If you receive an error message, give the IUSR_computername account Read, Write, and Delete permissions to the _vti_pvt directory of the web in question.)

9. Set the site back to Everyone has browse access. Exit the FrontPage Explorer, and retest the security of the web in FrontPage.

10. If you've tried each of the previous steps to no avail, or if you get unexpected results when managing content with FrontPage, reset NTFS permissions back to the default, and let FrontPage retake control.

    This step applies to a single sub-web site, or to an entire virtual server.

Setting Permissions

Unless you understand how the FrontPage security model works, it's best to let FrontPage manage Web permissions for you. This section gives several examples of improperly set permissions and tells you how to correct them.

For a detailed description of the FrontPage security model on IIS 5.0 and guidelines for the minimum permissions needed, see the "Security on Windows NT" section of the FrontPage 2000 Server Extensions Resource Kit.

Common Problems and Resolutions

Problems with permissions can range from a hit counter that does not increment (or an author who cannot open a web) to issues that deal with multiple virtual servers. The following is a list of common problems and resolutions:

• The hit counter on a Web page shows up as a broken image or is stuck at 1.

  Make sure the file _private/Filename.htm.cnt has Read, Write, and Delete permissions for the user (usually the IUSR_computername account) accessing the page. Before trying to edit the permissions directly, run the FrontPage command Check Server Extensions. This will reset the permissions on the files in the _private directory.

  To run this command

  1. On the Windows Taskbar, select Start, point to Programs, Administrative Tools, and Internet Services Manager.

  2. Right-click the virtual server that's having the problem, point to All Tasks, and select Check Server Extensions.

  If the command fails to resolve the problem, then IUSR_computername, Network, Interactive, or Everyone is more than likely listed on the Permissions property sheet, (which you can access from the Tools menu in FrontPage). If that is the case, follow the steps in "Resetting Permissions in a Sub-Web" later in this chapter. The same solution applies to problems with forms.

• When a user tries to submit a form, FrontPage returns an error message in the browser, or asks for a user name and password.

  Make sure that the resulting storage file has Read, Write, and Delete permissions for the user (usually the IUSR_ computername account) submitting the form. You can find the name of this file by looking in the source HTML of the form, or by checking the Form properties in the FrontPage Editor.

• The Web root is busy or cannot open Service.lck for Read/Write permissions.

  Lock files (*.lck) ensure that FrontPage has exclusive access to files as necessary. When a Web page is opened, the main lock file, _vti_pvt/service.lck, must be accessible. If there are insufficient permissions for the IUSR_computername account or if the file is corrupt, an error message is returned. To correct this problem, give Read, Write, Execute, and Delete permissions to all FrontPage users, for the _vti_pvt directory.

  Unless the web is restricted, the IUSR_computername account will be a FrontPage user. To resolve this, turn off anonymous browsing in IIS 5.0, and reset the permissions, as described later in this chapter. When you have finished resetting permissions, turn anonymous browsing back on.

• An author cannot open the web to add or edit content, but a Windows administrator can.

  Make sure that the author has been added to the FrontPage web as an author and that the content is correctly structured, as described earlier in this chapter. If Basic authentication has been set, the author must have the right to log on locally and might have to enter domainname\username, rather than just username when prompted.

• Anyone can open the FrontPage web without being asked for a user name and password.

  To solve this problem, see the suggestion for tightening security on a site earlier in this chapter.

  When trying to open, rename, or save a file to a web in the FrontPage Explorer or Editor, one of three errors is returned. For example, suppose you receive one of the following errors for a file called "Test.htm":

  • Cannot open file "Test.htm"

  • Cannot rename file "Test.htm"

  • Cannot save file "Test.htm"

  To eliminate these errors, if you've selected integrated Windows authentication, make sure you're not authoring as the anonymous user.

  Also, examine the NTFS permissions on the file that is giving these error messages, or on the parent directory. The user you are authenticating to the FrontPage web must have sufficient permissions on the file, such as Read, Write, and Delete. If the permissions are incorrect, adjust them manually. However, if there are several thousand files in the web with incorrect permissions, correcting each one individually will take too long. A more efficient alternative is to remove the author in question from FrontPage permissions. You can change permissions on the Permissions property page, which is accessed by selecting Permissions from the FrontPage Tools menu. Another method is to run the Fpsrvadm.exe command-line utility and reinstate the author with FrontPage permissions.

  Note: If you have to change permissions on thousands of files, security changes may take several minutes to propagate.

• You are unable to tighten security on a particular file or directory in a FrontPage web.

  By default, FrontPage does not allow you to increase security on just one file or directory. You should create a new sub-web with unique permissions and then set the desired permissions through FrontPage.

  Alternatively, you can target one file or directory by changing NTFS permissions. First, create a virtual directory that is physically outside the FrontPage content area. Next, manipulate NTFS permissions on this directory, or on a file within it. There is no danger of FrontPage overwriting NTFS permissions. The only drawback to this method is that FrontPage will not recognize that virtual directory and, therefore, will not be able to manage it.

Granting Log on Locally Rights

This section tells you how to grant users rights to Log on locally, as well as how to verify that a user has these rights.

To grant Log on locally rights

1. On the Windows 2000 Desktop, right-click the My Computer icon.

2. Select Manage.

3. In the left-hand pane of the Computer Management tool, double-click System Tools.

4. Double-click Group Policy, then Computer Configuration, then Windows Settings, Security Settings, Local Policies and, finally, User Rights Assignments. Figure 8.4 shows the user interface.

   

   Figure 8.4 Computer Management, User Rights

5. In the right-hand pane of the Computer Management tool, double click Log on locally.

   Figure 8.5 shows the resulting Log on locally dialog box, where you'll see a list of users for that computer. You'll also see a box to the right of the user name, under the heading Local Policy.

   

   Figure 8.5 Log on Locally Dialog Box

6. Select the Local Policy box for the user, or verify that the box has been selected.

Resetting Permissions in a Sub-Web

The easiest way to fix permissions problems in FrontPage is through the client. This section gives two sets of procedures for you to correct these problems. The first tells you what to do if a user, who has permission, cannot access a web. The second tells you how the Check Server Extensions command can fix authoring problems.

Cannot Access a Web Site

These steps will ensure that the user can access a web.

To give access

1. If you get errors relating to the Service.lck file, turn off anonymous browsing on the Web server.

2. Log on as an administrator, and open the web that is having the problem.

3. Remove the user account that is receiving the error, and click Apply.

4. If the IUSR_computername account is listed under the Users tab, remove it.

5. Click the Groups tab. If Network, Interactive, or Everyone is listed, remove them, and click Apply.

6. Under the Users tab, set browse access to Only registered users have browse access, and click Apply.

7. After the settings have been applied, reset browse access to Everyone has browse access.

8. Add the problem account back in with author access, and click Apply.

9. If you had to disable anonymous browsing, enable it.

If the user is not able to write to a Web site, try the next procedure.

Cannot Perform Authoring Tasks

Occasionally, an author of a web might not be able to upload web content, modify the web directly on the server computer, or perform other authoring functions supported by FrontPage Server Extensions. The cause of the problem can range from accidentally deleting or renaming essential files to corrupting the Windows 2000 DACLs. The Check Server Extensions command addresses many authoring problems by doing the following:

• Checks that files have Read access permission.

• Checks that the files Service.cnf and Service.lck have Read and Write access.

• Updates the files Postinfo.html and _vti_inf.htm.

• Verifies that the files _vti_pvt, _vti_log, and _vti_bin are installed and that _vti_bin is executable.

• Determines whether virtual server roots or metabase settings are correct and up-to-date.

• Verifies that the IUSR_computername account doesn't have Write access.

• Warns you if you are running on a FAT file system. If you are, you won't be able to supply any Web security whatsoever (provided you're running IIS 5.0).

To check server extensions on a web

1. In the console tree, right-click the web that you want to check, and fix the server extensions.

   The selected web will be checked and fixed, as well as all sub-webs below it.

2. Click Tasks on the shortcut menu, and then click Check Server Extensions.

   The Check Web window displays a status log for each web that is checked.

3. Select Yes if you see the following prompt: Do you want to tighten security as much as possible?

Resetting Permissions on a Virtual Server

This section contains two sets of procedures. You can use them to fix permissions on an entire server, without losing any custom permissions that have been set in each sub-web.

Before you work through these procedures, make sure that there are no custom script files in the directory structure you are working on. Otherwise, you may need to reset the permissions on these files after you have finished.

Note: While you work through these steps, users will get a password prompt when trying to browse webs until permissions have been reset.

One Virtual Server

The following procedure shows how to reset permissions for a configuration of a single virtual server with only a few sub-webs. If you have many sub-webs, work through the procedure that follows this one.

To reset permissions

1. Open a sub-web.

2. If the IUSR_computername account is listed under the Users tab, remove it. Also remove the Network, Interactive, and Everyone groups if they are listed under the Groups tab.

3. Click Apply.

4. Set browse access to Only registered users have browse access, and click Apply.

5. Verify that none of the users or groups you just removed has reappeared under the Users or Groups tabs. If they have, remove them.

6. Repeat the previous steps for each sub-web on the virtual server.

   Save the root web for last, in order to avoid random password prompts.

7. From the IIS snap-in, right-click the virtual server for which you want to change permissions, select All Tasks, and then click Check Server Extensions.

8. Select Yes when you see the following prompt: Do you want to tighten security as much as possible?

9. Open the root web with FrontPage.

   If you get an error message such as Cannot open service.lck for writing, turn off anonymous browsing on the Web server. (You can turn it back on once you have opened the root web.)

10. From the Tools menu in FrontPage, click Permissions, and on the Permissions property sheet, select Everyone has browse access, and click Apply.

11. Repeat steps 9 and 10 for each sub-web.

Multiple Virtual Servers

The following procedure shows how to reset permissions for multiple virtual servers, each with multiple sub-webs that have unique permissions. First, you have to restrict browser access, and then reset permissions on each virtual server.

To restrict browser access

1. From the document root (which contains the virtual servers on which you need to reset permissions), open a command prompt.

   If you are dealing with the Default Web Site (found in the C:\Inetpub\Wwwroot directory, by default), open a command prompt and change to the C:\Inetpub directory. Then, type the following command:

cacls wwwroot /T /E /R iusr_computername network interactive everyone

However, the Wwwroot directory is just an example. Substitute your content directory's path in the preceding command.

2. From the IIS snap-in, right-click the virtual server on which you want to change permissions, select All Tasks, and then click Check Server Extensions.

3. Select Yes when you see the following prompt: Do you want to tighten security as much as possible?

   At this point, Browse access will be restricted.

Once you are in the site with FrontPage, turn Anonymous access on.

To enable Anonymous access

1. Open the root web with FrontPage.

2. From the Tools menu in FrontPage, click Security and then Permissions.

3. On the Users tab of the Permissions property sheet, select Everyone has browse access, and click Apply.

4. Repeat the previous step for each sub-web that was set with unique permissions.

How These Solutions Work

The majority of the problems that FrontPage encounters are caused by changes to NTFS permissions. Normally, IUSR_computername is granted Read and Execute permission from the top of the document tree. When IIS 5.0 finds that IUSR_computername can execute Admin.dll and Autor.dll, it never prompts FrontPage for a password. From this point, one of two things will happen:

• Everything will appear to work, but all documents are created by the anonymous user. This occurs only if IUSR_computername was given Change or Full Control permission in the document tree.

• When you try to save a file, FrontPage returns an error message saying it cannot write to a given file, or FrontPage corrupts the document (caused by problems in the _borders and _derived directories).

The previous solutions remove problem accounts either through FrontPage or the Cacls command. Using the Windows Explorer to reset permissions replaces all other permissions with the new ones. Once Cacls or FrontPage have done their work, the FrontPage Server Administrator verifies the results.

After making the appropriate change, reactivate anonymous browsing through the FrontPage client, so that FrontPage will put IUSR_computername only where it has to be, and with the tightest possible security.

Configuring E-mail

This section offers solutions to two common problems that can occur when you try to submit a form through FrontPage. These problems are illustrated in the following scenarios:

Scenario 1 Errors appear in a client's browser when a form is sent through e-mail.

Scenario 2 After filling out a form, the client receives a confirmation, but the form isn't sent.

Scenario 1

Suppose a client publishes a form on the Web server. Although the form is designed to send e-mail results, when it is submitted a FrontPage error appears in the Web browser and no e-mail is sent. Or, suppose a client is authoring live on the server and attempts to e-mail a form. The client receives the following error message, instead of the form:

The FrontPage Server Extensions have not been configured to send e-mail.
Please direct your system administrator or Internet Service Provider
to follow the instructions at "Setting Up Your E-mail Transport" in the
\SERK\enu\admin.htm file on the FrontPage CD-ROM.
Would you like to remove the e-mail recipient? Yes/No

Solution

To keep your clients from receiving an error message, make sure you have configured mail settings in the IIS snap-in.

Some features, such as an e-mail form handler, require that e-mail be sent to visitors who browse a web. To allow these features to send e-mail, you must specify the following in the IIS snap-in:

• Web server's mail address

• Contact address

• Simple Mail Transfer Protocol (SMTP) host

• Mail-encoding scheme

• Mail character set

To configure mail settings

1. In the IIS snap-in console tree, right-click the Web site for which you want to set e­mail options.

2. Click Properties on the shortcut menu, and then click the Server Extensions tab.

3. In the Options box, click Settings.

   Enter the appropriate settings:

   • Web Server's Mail Address Type the e-mail address that you want to appear in the From line of any e-mail messages that FrontPage components send. (For example, the form results component sends e-mail when someone fills out a form on a Web page and sends the information to the author of the form.) This setting is equivalent to the MailSender setting in Microsoft® FrontPage® 98, but is now stored in the registry, instead of in the Frontpg.ini file.

   • Contact Address Type the e-mail address that users should write to if they have problems. This address will appear on any error messages that are displayed, should FrontPage users encounter problems.

   • SMTP Host Type the name of the SMTP server that will deliver all mail sent from the web, or accept the default value, port 25. When a user submits a form whose results are to be sent through e-mail, the FrontPage Server Extensions connect to the SMTP server, in order to deliver the mail. By default, FrontPage assumes that the server is listening on port 25 (the standard for SMTP), but you can override this port by appending ":nn" to the name and IP address. (The nn is the number of the new port.) This setting is equivalent to the SMTPHOST setting in FrontPage 98, but is now stored in the registry instead of in the Frontpg.ini file.

     For example:

     reskit.microsoft.com (standard mail server name)

     - 172.16.29.38 (mail server's IP address)

     reskit.microsoft.com:31 (standard mail server name on different port)

     - 172.97.31.87 (mail server's IP address on different port)

   • Mail-Encoding Scheme Select the mail-encoding scheme you want, or accept the default. This scheme encodes the contents of your mail messages in binary format. You should select default encoding if you want to allow FrontPage to detect the correct encoding for you, which it will, in most cases. However, you should change the encoding, if you know that the receiver of your e-mail has a different encoding setting from the default.

   • Mail Character Set Select the appropriate character set to be used in e-mail messages, or accept the default. Each character set is the alphabet or character set of a different language. Any given byte does not necessarily map to a fixed character, since not all machines necessarily use the same character sets. When you accept the default setting, FrontPage automatically detects the character set for you.

Scenario 2

The second common problem can occur when a form appears to be sent and the person filling out the form receives a confirmation page, but the form never reaches the target address.

Solution

A filter at the local or remote mail server could be deleting junk mail. Many mail servers check that the From address of e-mail they process is valid. By default, FrontPage server extensions send e-mail indicating that the user has submitted the form. So, on an IIS 5.0 server the e-mail might appear to come from IUSR@webserver or, on a Netscape Server, from system@webserver. You can solve this problem by verifying that the mail server accepts the Web server's mail address specified in the IIS snap-in. If it does not, change the account setting to one that the mail server is configured to accept. See the previous scenario for instructions about configuring this setting.

If mail still doesn't reach the server, see if mail sent from another e-mail client on the same server is received.

Uploading Executable Scripts or Programs

When a web author wants to include a CGI script or a script in an ASP page within a web, make sure that the author isn't inadvertently uploading a virus or a program that has bugs onto your Web server. You can avoid this risk by preventing an author from uploading scripts and programs to any folder that is part of a web.

To control the uploading of executables

1. In the IIS snap-in, right-click the root web for the appropriate folders.

2. On the menu, click Properties, and then click the Server Extensions tab.

3. To prevent the folder from containing executable scripts or programs, make sure that the Allow authors to upload executables check box is cleared. To allow the folder to contain executable scripts or programs, make sure that the Allow authors to upload executables check box is selected.

Because the default setting prevents authors from uploading executables, you may find that your authors get an error message similar to the following:

Server error: The folder "/Cgi-bin" is marked executable. You are not allowed to put files into an executable folder on this server.

Note: In this example error message, the Cgi-bin directory can be any folder with Executable permission on the server.

This error will occur if the author tries to upload files from an executable folder that is on a client computer to an executable folder that is on the server. When this happens, ask the author to let you test the files before publishing them. If you are confident that the executables are safe, allow the author to upload these files by following the steps that were just listed.

Uploading Content through FTP

Once content for sites is created, you need to upload it onto a server for publication. The advantage to uploading content through FTP is speed.

FTP, which is integrated into the Microsoft® Windows® operating system as an Internet service, publishes information on a Web server through a standard FTP client. Depending on the client, you can operate FTP through the command-line or through a GUI-based interface.

Although FTP is efficient at uploading, it has two drawbacks:

• Minimal Support for Querying and Retrieving Information on the Server Although searching was not part of the original purpose of FTP, you can set up a filter on the client (or server, for that matter). This filter can return result sets for specific information. While this solution might seem a bit cumbersome, it is a viable one.

• Lack of Strict Security FTP connections are not secure, because passwords are exchanged as clear text. At this time, extensions are being developed that will create a secure way of authenticating clients and transmitting files. Of course, sensitive information should never be sent as clear text because it can be intercepted, modified, and replayed. When these new extensions become available, FTP will be a secure solution to the current problem.

Internet Connection Services for Remote Access

The components that previously made up Internet Connection Services for remote access are now components of Windows 2000 Server. They are no longer referred to as Internet Connection Services for remote access, but by their individual component names:

• Connection Manager Administration Kit

• Connection Point Services

• Internet Authentication Services

These connection components are designed to help corporations and ISPs build comprehensive Internet-access solutions, including dial-up VPNs. Whether you are building an Internet service or managing a corporate network, these connection components help you quickly set up, customize, and manage a remote-access network. You can give your subscribers a seamless connection to the Internet, a global dial-up service, as well as secure connections over the Internet to a private network.

Whether you're an ISP or a corporate network administrator, the steps for installing these components are the same. If you installed Internet Connection Services for remote access as part of IIS 4.0, you can upgrade to the latest versions of the individual components through Windows Setup.

To install the three components during Windows Setup

1. On the Windows Optional Components screen, click Networking Options, and then click Details.

2. Select the check box for the component you want to install.

If you have already installed Windows, you can install the components by using Add/Remove Programs in Control Panel.

To add the components after installing Windows

1. Click Start, point to Settings, and then point to Control Panel.

2. Click Add/Remove Programs.

For details about how to use these connection components, see the Windows 2000 Server online product documentation.

Administering Older Version Servers

This section tells you how to use the IIS snap-in to administer servers running previous versions of IIS. (Previous versions are also referred to as downlevel versions.)

If, for example, you have five Web servers running IIS 3.0 and you initially upgrade one of them to IIS 5.0, you can administer all of them from the IIS snap-in.

To administer older version Web servers

1. Create a temporary folder.

   This folder lets you rename the files that you copy in step 2, so that you don't overwrite existing files (that currently live in your C:\WINNT\System32\Inetsrv directory) with the same name.

2. From the Windows 2000 Server CD, copy the following files into the temporary folder you have created:

   File Name	Directory Location
   Fscfg.dll W3scfg.dll Gscfg.dll	\I386\inetsrv\
   Fscfg.hlp W3scfg.hlp Gscfg.hlp	\I386\inetsrv\help\

3. Rename the files in the temporary folder. For example:

   Old Name	New Name
   Fscfg.dll	Fscfg3.dll
   W3scfg.dll	W3scfg3.dll
   Gscfg.dll	Gscfg3.dll
   Fscfg.hlp	Fscfg3.hlp
   W3scfg.hlp	W3scfg3.hlp
   Gscfg.hlp	Gscfg3.hlp

   The Gopher DLL (Gscfg.dll) does not have to be renamed, but this has been done for consistency.

4. Copy the renamed files into your C:\WINNT\System32\Inetsrv directory.

5. Add the following registry values (with data type REG_SZ) to

   HKEY_LOCAL_MACHINE \Software \Microsoft \InetMgr \Parameters \AddOnServices

WWW3 = C:\WINNT\System32\inetsrv\w3scfg3.dll::SUPCFG:C:\WINNT\system32\inetsrv\w3scfg.dll FTP3 = C:\WINNT\System32\inetsrv\fscfg3.dll::SUPCFG:C:\WINNT\system32\inetsrv\fscfg.dll GOPHER3 = C:\WINNT\System32\inetsrv\gscfg3.dll

**Caution** Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft® Management Console (MMC) whenever possible.

This step appends "::SUPCFG:\<newer dll\>" to the existing DLL file name, indicating that the current files have been superseded.

6. From the IIS snap-in, connect to a server running IIS 3.0. To do this, open the IIS snap­in, select Internet Information Services, click Action, then click Connect. Enter the name of the Web server you want to connect to.

At this point, you can see the Web server from the IIS snap-in.

The Properties toolbar button in the IIS snap-in is not available for some older sites. Instead, you must right-click the name of the site and select Properties. You can also select Properties on the Action menu.

Figure 8.6 shows the IIS snap-in connected to a server (called "someone") that is running IIS 3.0.

Figure 8.6 Remote Connection to an Older Version Server of IIS

Allocating Resources

This section discusses logging activity on sites. It gives examples of how to configure logging, in order to record information needed for managing your Web sites efficiently. It shows how to adjust bandwidth in order to improve performance on each server in your installation. This section also describes extended logging through process accounting and tells you how to throttle processes in order to prevent any one site from taking up too much processor time. Also discussed is the HTTP Monitoring Tool, which monitors the performance of Web sites.

Logging Resources

Historically, logging has been a complex and time-consuming task. Web servers had to collect information about activity on a server and put it into a single file (sometimes several hundred megabytes in size). ISPs were then forced to extract information about specific Web sites from this file.

IIS 5.0 simplifies logging. You can now set various levels of granularity when analyzing the activity on your server. Log files can include or exclude information about individual Web sites, individual directories, and individual files.

By using IIS 5.0 logging, you can track which users access a site and when, which helps to identify potential security and performance problems. You can direct logging either to a file that can be studied offline, or to an Open Database Connectivity (ODBC) Data Source Name (DSN) for online evaluation.

IIS 5.0 has several logging features to help customize information about an IIS 5.0 Web site:

• Customized Extended Logging IIS 5.0 supports the latest industry-standard W3C extended logging format, a customizable ASCII format that allows you to rerecord a variety of fields (items). You can gather detailed information and still limit log size by omitting unneeded fields. These fields include about 20 different items, such as date, time, client IP address, and browser type.

• Resource Logging As with most configuration settings in IIS 5.0, logging can be set on a per-file basis. With resource logging, you can limit logging to specific resources. This will improve performance, reduce the size of the log file, and make it easier to interpret log files. For example, to reduce the log file size, you could put all the image files in one directory and choose not to log the files in that directory.

• COM Logging Interface Developers can create custom modules to log information about a Web site. Each module is responsible for processing request events and writing either to a SQL Server data source or to a log file. IIS 5.0 logging capabilities can be extended by "plugging in" additional logging modules that developers or third-party vendors create.

To see the various levels of logging

1. Right-click the Web site for which you want to record a log.

2. On the Web Site property sheet, click the down arrow in the Active log format box.

3. Select the style of logging you want, and click the Properties button.

4. On the General Properties (or ODBC Properties) dialog box, select the desired granularity of logging.

5. If you've selected the W3C Extended Log File Format, select your preferred logging options in the Extended Logging Options dialog box.

For example, in the following log file, requests for files in the Images directory are included. If this page were to be requested several thousand times, the GET request for the image would be logged several thousand times as well.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 1999-01-01 22:20:57
#Fields: time c-ip cs-method cs-uri-stem sc-status
22:20:57 172.16.1.1 GET /samplecorp/ 404
22:21:03 172.16.1.1 GET /Default.htm 304
22:21:37 172.16.1.1 GET /images/undercon.gif 304

The following example shows a log file that doesn't log the Images directory. Note that it doesn't include the GET request for /Images/Undercon.gif.

CLIENT REQUEST
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 1997-10-16 22:23:32
#Fields: time c-ip cs-method cs-uri-stem sc-status
22:23:32 172.16.1.1 GET /samplecorp/ 404
22:24:14 172.16.1.1 GET /Default.htm 304

To further customize logging, you can create other logging modules with Microsoft® Visual C++® or Visual Basic. For more information, see the IIS 5.0 online product documentation.

For information about how to set extended logging options, see the "Customizing W3C Extended Logging" topic in the IIS 5.0 online product documentation. For a list of logging options and other information, see the "Logging Properties Reference" topic in the IIS 5.0 online product documentation.

Controlling Bandwidth

One of the administrator's tasks is setting and monitoring bandwidth for various sites. As the bandwidth utilization of a Web site approaches the limit set by the administrator, response times slow down. If requests are received faster than the site can respond (meaning that the queue is full), the server will return an error message (500: Server Too Busy) to the client.

IIS 5.0 allows you to control the bandwidth of each Web site on a server, distributing it where needed most.

To throttle bandwidth on a server

1. In the IIS snap-in under Internet Information Services, right-click the Web site on which you want to throttle bandwidth.

2. Click Properties.

3. On the Internet Information Services property sheet, select Enable Bandwidth Throttling, and click OK.

By throttling (adjusting) bandwidth, an ISP can offer Web hosting solutions that are tailored to the bandwidth needs of individual customers. In IIS 5.0, you can throttle bandwidth for static content, including .htm, .jpg, and .gif files. However, you can distribute bandwidth on your server by throttling only the static HTML (files with .htm or .html extensions).

The metabase stores the configuration options for the bandwidth throttler, and IIS 5.0 is notified as soon as changes are made. You can manipulate the threshold values (bandwidth limits), and turn on or turn off bandwidth throttling, without stopping and restarting IIS 5.0.

Disabling Socket Pooling

IIS 5.0 sites that are bound to different IP addresses—but the same port number—share the same set of sockets. This feature allows more sites bound to an IP address to be created on the same machine than was possible in IIS 4.0. In IIS 5.0, these sockets are used flexibly among all of the sites, in order to reduce resource consumption.

Socket pooling is now the default for IIS 5.0, and in general, you don't need to change it. However, both bandwidth throttling and performance adjustments will apply to all Web sites configured for the same port. So, if you intend to enable bandwidth throttling or do performance tuning on a per-site basis, you will need to disable socket pooling.

• To disable socket pooling, type the following at the command prompt:

c:\inetpub\adminscripts\cscript adsutil.vbs set w3svc\disablesocketpooling true

The command prompt will reply:

disablesocketpooling : (BOOLEAN) True

Process Accounting and Process Throttling

In addition to throttling static content, you can throttle processes on Web sites. If one of your customers is consuming too many resources, to the point that other Web sites are slowed down or otherwise affected, you might want to restrict the amount of resources this customer can consume. To do so, you must first measure resource consumption, in order to see which site is consuming too much. Then, limit its amount of resources. IIS 5.0 comes with two new features to help you do this:

• Process accounting logs the CPU time and other resources used by applications.

• Process throttling limits the amount of resources a Web site can consume.

Process accounting and process throttling work only for applications run out of process. You cannot activate accounting for in-process applications, or for applications run in the new IIS 5.0 out-of-process pool.

You can track the CPU time for applications, log information, and put throttling limits on the site, if necessary. Generally, process accounting and process throttling apply to an entire site and cannot be targeted toward any individual application, unless only one application is running on the site. If you have more than one application running on the site, you can target a specific application by writing a script in the metabase, using the appropriate property:

CpuAppEnabled Enables process accounting and throttling for an out-of-process IIS 5.0 Web Application Manager (WAM) application.

CpuCgiEnabled Enables process accounting and throttling for a CGI application.

For details, see the "CpuAppEnabled" topic in the IIS 5.0 online product documentation. For information about activating process accounting and process throttling, see the "Tracking Processor Use" and "Throttling Processes" topics in the IIS 5.0 online product documentation.

Measuring Resource Consumption

To measure the amount of resources consumed by the sites in your installation, turn on process accounting. Once you know which site is using too many resources, you can decide whether to limit resources on that customer's Web site (through process throttling) or whether you should take other actions.

To turn on process accounting

1. On the site's property sheet, click the Home Directory tab.

2. Configure the Application Settings to High (Isolated).

   These first two steps make all applications on the site run out of process.

3. On the site's property sheet, click the Web Site tab, and make sure Enable Logging is selected.

4. On the Web Site property sheet, click the logging Properties button, and select Process Accounting.

   The last two steps activate process accounting for that site.

With process accounting activated, you extend logging so that figures for the Job Object counters are recorded. With the information gathered from process accounting, you can then decide whether to upgrade the servers in your installation, to adjust the billing for this particular customer, or to limit the amount of resources the site can consume.

For more information about activating process accounting, see the "Tracking Processor Use" topic in the IIS 5.0 online product documentation.

Limiting Resources

After determining the amount of resources the customer's site is consuming, you might want to limit that customer to a certain percentage of your available resources. This will free up resources for other customers. To limit a site's resources, run the site's applications out of process, and then turn on process throttling.

To turn on process throttling

1. On the site's property sheet, click the Performance tab.

2. Select Enable process throttling.

3. In the Maximum CPU use box, set the percentage of CPU resources dedicated to the site.

4. Enable Enforce limits.

When the site reaches a predefined limit, it will take the defined action, such as reduce process priority, halt processes, or halt the site.

For information about process throttling, see the "Throttling Processes" topic in the IIS 5.0 online product documentation.

Stopping CGI Applications

You might discover that a customer has a CGI application that consumes CPU resources continuously. To keep this application from using CPU resources, you can turn on process throttling for the site (as described in the previous section), and then limit the total CPU time for each instance of the CGI application. When the true limit is reached (which is usually a maximum of 200 percent of the limit you set), the applications on that site are stopped.

For more information, see the "About Processor Utilization" topic in the IIS 5.0 online product documentation.

Monitoring Performance with the HTTP Monitoring Tool

The HTTP Monitoring Tool is a browser-based tool, available on the Resource Kit companion CD, that monitors the performance of Web sites in an installation. To use this tool, you must first install Microsoft® SQL Server 6.5 or later on a computer that can be accessed by computers that run the HTTP Monitoring Tool.

The tool's interface looks similar to the screen shown in Figure 8.7.

Figure 8.7 The HTTP Monitoring Tool's Real-Time Display in Internet Explorer 5

Using the HTTP Monitoring Tool

You can run the HTTP Monitoring Tool on several servers concurrently, in order to test connectivity and to display the connectivity statistics of the sites in your installation. The database for these Windows-based servers is centralized on a single SQL Server.

The HTTP Monitoring Tool, which emulates the way that users attempt to connect to Web sites, is a multithreaded process that operates according to the parameters and values set in its associated HTTPMon.ini file. These parameters specify the Web sites to be tested, as well as the number of times and frequency to retry a failed connection, before moving on to the next specified site. You can set other parameters that optimize the HTTP Monitoring Tool for your particular installation, including a maximum thread pool count, an output file and directory, a working directory, and so on.

Customizing Your Installation

In this section, you'll learn how IIS 5.0 can help simplify the task of managing multiple Web sites and content. You'll learn how to host multiple Web sites or domains on one IP address, by assigning host header names to each site. You'll also see how to bring older browsers into compliance with HTTP 1.1, so that they can support host headers. Since sites often change locations, you'll learn how to redirect requests to the new location. Next, you'll see how to control Web content that is held in a browser's cache, by using custom HTTP headers, as well as how to use custom HTML footers for all pages contained in a Web site. And finally, for a site that needs a footer in each document it publishes, you'll learn how to embed a link to an include file. This will make it easier to update the footer content throughout the site.

Hosting Multiple Sites with One IP Address

Many customers will not only request access to the Internet, but will also want to host their own domain (for example, domain.com ) or subdomain on an existing server. To handle this type of situation, IIS 5.0 offers two models for site configuration:

• Multiple IP addresses on one server

• Multiple host headers on one server with one IP address

Previous versions of IIS allowed you to host multiple Web sites (virtual servers or domains) on a single computer running Windows NT Server 4.0. By assigning a different IP address to each site (all on one computer), you could reduce the number of computers required in an ISP installation.

With IIS 4.0, a new feature was introduced that allowed hosting multiple Web sites with a single IP address. Continued in IIS 5.0, this feature works well if you do not have a lot of IP addresses to spare, but want to host several Web sites on one computer anyway. Instead of assigning each site a unique IP address, you give it a unique host header name. This feature works best for smaller sites with less traffic than it does for sites on a computer with unique IP addresses for each site.

Host header names are the key to hosting multiple Web sites on one computer. However, as mentioned earlier, not all browsers support them. Because host headers are part of HTTP 1.1, browsers must comply with HTTP 1.1 in order to access sites that do not have unique IP addresses. Microsoft® Internet Explorer 3.0, Netscape Navigator 2.0, and later versions of both browsers support host header names, but earlier versions of the two browsers do not. For information about allowing older browsers to access a site through host header names, see "Supporting Non-HTTP 1.1–"Compliant Browsers" later in this chapter.

The following examples show how to use host headers. The first example shows unique IP addresses assigned to multiple Web sites on one computer. The second example shows one IP address on one computer hosting multiple Web sites, differentiated only by their unique host header names.

One Computer, Multiple IP Addresses

IIS 3.0 offered this option as the sole way to publish multiple sites on the Internet. ISPs could direct customers to two or more separate IP addresses and have the addresses and the domain names registered with InterNIC. This option remains cost-effective for two reasons:

• ISPs can minimize their hardware costs.

• As a specific site grows, it can be migrated onto its own dedicated server without interrupting customer access.

Having multiple IP addresses enhances security of Web sites contained on the server. For example, in some cases an ISP might host customers' personal Web pages on one IP address. The ISP might then set up a second IP address, with IIS 5.0 and the FTP protocol enabled in order to let customers post content to their Web pages. This particular configuration will frustrate any would-be intruder, who might try to access the Web site. This intruder might try to capture FTP user names and passwords in two ways: either by attacking an FTP port on the site, or by performing a network "sniff" of the site.

The following example shows two Web sites (reskit1.microsoft.com and reskit2.microsoft.com) hosted on one computer with two different IP addresses (reskit1.microsoft.com = 172.21.13.45 and reskit2.microsoft.com = 192.168.114.201). Although you can see the host header field in the HTTP log, it is the network IP address (not the host header field) that differentiates between the Web sites.

This type of configuration works well for large installations that contain hundreds of Web sites and attract lots of hits.

CLIENT REQUEST FOR reskit1.microsoft.com
IP: Destination Address = 172.21.13.45
HTTP: Request Method = GET
HTTP: Uniform Resource Identifier = /
HTTP: Protocol Version = HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.
HTTP: Accept-Language = en-us
HTTP: Accept-Encoding = gzip, deflate
HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
HTTP: Host = reskit1.microsoft.com
HTTP: Connection = Keep-Alive
CLIENT REQUEST FOR reskit2.microsoft.com
IP: Destination Address = 192.168.114.201
HTTP: Request Method = GET
HTTP: Uniform Resource Identifier = /
HTTP: Protocol Version = HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.
HTTP: Accept-Language = en-us
HTTP: Accept-Encoding = gzip, deflate
HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
HTTP: Host = reskit2.microsoft.com
HTTP: Connection = Keep-Alive

One Computer, Same IP Address, Multiple Hosts

IIS 4.0 introduced host header names as a way to create many sites very quickly, without the need for IP addressing or subnet calculations. The advantage of host headers is that an Internet browser can access the IIS 5.0 Web server with a known URL (for example, reskit3.microsoft.com). The IIS 5.0 server will then map that URL path to an established location that matches each Web site's host header name. With this option, it is very easy (through the IIS snap-in) to create new sites, define their home pages, allocate bandwidth, and set specific access rights.

The following example shows two Web sites (reskit3.microsoft.com and reskit4.microsoft.com) hosted on one computer with the same IP address (172.21.13.45). In this case, the host header names differentiate between the sites.

CLIENT REQUEST FOR reskit3.microsoft.com
IP: Destination Address = 172.21.13.45
HTTP: Request Method = GET
HTTP: Uniform Resource Identifier = /
HTTP: Protocol Version = HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.
HTTP: Accept-Language = en-us
HTTP: Accept-Encoding = gzip, deflate
HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
HTTP: Host = reskit3.microsoft.com
HTTP: Connection = Keep-Alive
CLIENT REQUEST FOR reskit4.microsoft.com
IP: Destination Address = 172.21.13.45
HTTP: Request Method = GET
HTTP: Uniform Resource Identifier = /
HTTP: Protocol Version = HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.
HTTP: Accept-Language = en-us
HTTP: Accept-Encoding = gzip, deflate
HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
HTTP: Host = reskit4.microsoft.com
HTTP: Connection = Keep-Alive

For information about setting up host headers, see the "Naming Web Sites" topic in the IIS 5.0 online product documentation. For a general discussion about name resolution and IP addresses, see the "Name Resolution" topic in the IIS 5.0 online product documentation.

Supporting Non–"HTTP 1.1–"Compliant Browsers

Although many non-HTTP 1.1–"compliant browsers support host headers, some do not, particularly older browser versions. To make your site available to browsers that do not comply with HTTP 1.1, you can send cookies from a Web site. These are objects that are sent to a Web server along with client requests. Another option is to embed a host name in the URL of the Web site (also called URL munging).

Sending Cookies

Making a site accessible to noncompliant browsers through cookies targets only those browsers that can accept them. Cookies can be attached to hosts on the client side, and will be sent with a request whenever a client accesses the Web site in question. An older browser that supports cookies can use a cookie as a pseudo host header. To allow this, the administrator must set up several components, including registry settings, and add .asp files to the Scripts directory of the Web site.

When a noncompliant browser first accesses a site with multiple hosts, the server cannot detect which site the user wants to visit. With IIS 5.0, you can display a custom menu to these users, listing the Web sites available. This menu can be any document—an .htm file or an .asp file. There are two possible host menu documents that the administrator can set up: one for clients that support HTTP cookies, and the other for clients that do not. The menu documents must exist in a virtual directory of one of the sites on the Web server. The administrator must specify the document names and the host name of the site where these documents can be found. For example, the following process shows what happens if a client tries to access reskit1.microsoft.com through a noncompliant browser:

1. The client attempts to access https://reskit1.microsoft.com.

2. Since there is no host header with the request, the server does not know which Web site the client wants.

3. IIS 5.0 presents the client with an HTML menu prepared by the administrator, which lists the available sites on this particular IP address.

4. The client selects (and is redirected to) the desired site on the server.

5. A cookie is returned to the client. This cookie ensures that all subsequent requests for https://reskit1.microsoft.comdirectly access the appropriate documents. There is no need for a menu, at this point.

In the following example, a request was made for the reskit1.microsoft.com and reskit2.microsoft.com sites. Notice the HTTP 1.0 GET requests and the host lines below them. While initiating an HTTP 1.0 request, Microsoft® Internet Explorer 3.02 can communicate with IIS 5.0 through a host header.

CLIENT REQUEST FOR https://reskit1.microsoft.com(from an HTTP/1.0 browser)
GET / HTTP/1.0
Accept: application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
UA-pixels: 800x600
UA-color: color16
UA-OS: Windows 2000
UA-CPU: x86
User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows 2000)
Host: reskit1.microsoft.com
Connection: Keep-Alive
CLIENT REQUEST FOR https://reskit2.microsoft.com(from an HTTP/1.0 browser)
GET / HTTP/1.0
Accept: application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
UA-pixels: 800x600
UA-color: color16
UA-OS: Windows 2000
UA-CPU: x86
User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows 2000)
Host: reskit2.microsoft.com
Connection: Keep-Alive

In the example that follows, notice that the GET request does not have a host header. Clients that do not support host headers, such as Microsoft® Internet Explorer 2.0, will return the error message "404 Object Not Found."

CLIENT REQUEST FOR https://reskit1.microsoft.com(from Internet Explorer 2.0)
GET / HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, */*
Accept-Language: en
User-Agent: Mozilla/1.22 (compatible; MSIE 2.0d; Windows 2000)
Connection: Keep-Alive
SERVER RESPONSE
HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Wed, 14 Oct 1998 17:05:55 GMT
Content-Type: text/html
Content-Length: 102

Components for Administration (Sample Setup)

The following registry configuration is necessary to make the next example work. All of the host menu documents have been placed on the Web site https://reskit1.microsoft.com. Registry values have been added to

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \W3SVC \Parameters

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

The registry values include:

DLCMenuString = /HostMenu (Data Type is REG_SZ)

This parameter specifies the prefix of URLs that apply to the host menu. The server will check against this string on all requests from older browsers (in other words, requests without a host header).

DLCHostNameString = reskit1.microsoft.com

This parameter supplies the host name of the instance that contains the menu documents.

DLCMungeMenuDocumentString = /scripts/munge.asp

This host menu document will be sent to older browsers that don't support cookies.

DLCCookieMenuDocumentString = /scripts/cookie.asp

This host menu document will be sent to older browsers that do support cookies.

DLCCookieNameString = PseudoHost

This parameter specifies the name of the special cookie that will act as a pseudo host header. This can be used with clients that support cookies.

DLCSupport = 1 (Data Type is REG_DWORD)

This parameter enables support for older browsers.

The host menu documents include three files (Munge.asp, Cookie.asp, and Redirect.asp).

Contents of reskit1.microsoft.com/scripts/munge.asp

Copy this sample code into a text file and name it Munge.asp. Then copy the file into the Scripts directory of the instance you are using. In this example, it is reskit1.microsoft.com.

<HTML>
<HEAD>
<TITLE>Server Selection Page</TITLE>
</HEAD>
<BODY>
<A HREF="https://reskit1.microsoft.com/*reskit1.microsoft.com/<%=
Request.QueryString() %>">Try this Site reskit1.microsoft.com</A><BR>
<A HREF="https://reskit1.microsoft.com/*reskit2.microsoft.com/<%=
Request.QueryString() %>">Try this Site reskit2.microsoft.com</A><BR>
</BODY>
</HTML>

Contents of reskit1.microsoft.com/scripts/cookie.asp

Copy this sample code into a text file and name it Cookie.asp. Then copy the file into the Scripts directory of the instance you are using. In this example, it is reskit1.microsoft.com.

<HTML>
<HEAD>
<TITLE>Server Selection Page</TITLE>
</HEAD>
<BODY>
<A HREF="/HostMenu/Scripts/Redirect.asp?Host=reskit1.microsoft.com&NewLocation=<%=
Request.QueryString() %>">Try this Site reskit1.microsoft.com</A><BR>
<A HREF="/HostMenu/Scripts/Redirect.asp?Host=reskit2.microsoft.com&NewLocation=<%=
Request.QueryString() %>">Try this Site reskit1.microsoft.com</A><BR>
</BODY>
</HTML>

Contents of reskit1.microsoft.com/scripts/redirect.asp

Copy this sample code into a text file and name it Redirect.asp. Then copy the file into the Scripts directory of the instance you are using. In this example, it is reskit1.microsoft.com.

<%
Option Explicit
Dim DLCCookieNameString
DLCCookieNameString = "PseudoHost"
Response.Cookies(DLCCookieNameString) = Request.QueryString("Host")
Response.Cookies(DLCCookieNameString).Domain = Request.QueryString("Host")
Response.Cookies(DLCCookieNameString).Path = "/"
Response.Redirect "https://" & Request.QueryString("Host") &
Request.QueryString("NewLocation")
%>

Munging URLs to Support Older Browsers

Another way to support older browsers is to embed the host header name in the URLs that are being sent to the Web server. On the server side, these embedded hosts are recognized and stripped out of the URL and used as a pseudo host header, prior to regular URL processing. For URL munging to work, each request from the browser must have a host header embedded. If it does not (as is the case with an initial request), a host menu will be sent to the client. For an example of URL munging, see the ISAPI filter Cookie Munger provided on the Resource Kit companion CD.

Making Redirects Work for You

With the redirection feature of IIS 5.0, you can divert requests for one Web page to another. In an intranet environment, for example, many sites could point to a common resource such as a Human Resources Web site. If the location of that site were changed for some reason, all of the sites pointing to that page would also have to change, to reflect the new URL. Finding all links to the Human Resources site and then changing them can be an overwhelming project in a large installation. However, IIS 5.0 supplies an easier way.

You can use redirection in order to point the old URL to the new location. With redirection, the pages pointing to the old location will continue to work, giving you the chance to update the links in stages, as time permits.

See the IIS 5.0 online product documentation for information about how to configure redirection.

Setting Up Custom HTTP Headers

With custom HTTP headers, you can control various aspects of the Web page that is sent to clients. When you set an HTTP header, information is embedded with the page header and sent through the browser, allowing you to:

• Limit the time a page is stored in the client's cache.

• Extend the current HTML specification.

• Rate the content of Web pages.

• Determine the file types sent to the client.

Content Expiration Example

Enabling the content expiration feature works well for sites that publish time-sensitive information, such as announcements for events or special offers. By sending clients a custom HTTP header to delete the page from the client's cache after a certain period of time, you can be sure that the client won't access a cached version of a page that is out of date. For information about configuring custom headers, see the "Enabling Content Expiration" topic in the IIS 5.0 online product documentation.

Compare the following two examples, in which the client has made a request to a computer named https://bicent/samplecorp.

Without a Custom HTTP Header

This sample code shows a request that is sent without an HTTP header:

CLIENT REQUEST
GET /samplecorp/images/undercon.gif HTTP/1.1
Accept: */*
Referer: https://bicent/samplecorp/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
Host: bicent
Connection: Keep-Alive
Cookie: ASPSESSIONIDGQQGQGBE=OGIFFNMBNOHDMKLFECBOKFPM
SERVER RESPONSE
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 14 Oct 1999 17:49:38 GMT
Content-Type: image/gif
Accept-Ranges: bytes
Last-Modified: Tue, 14 Oct 1999 15:53:27 GMT
ETag: "0d1974fb9d8bc1:eca"
Content-Length: 293

With a Custom HTTP Header

This sample code shows the same request sent with an HTTP header that causes content to expire in 30 minutes:

CLIENT REQUEST
GET /samplecorp/images/undercon.gif HTTP/1.1
Accept: */*
Referer: https://bicent/samplecorp/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
Host: bicent
Connection: Keep-Alive
Cookie: ASPSESSIONIDGQQGQGBE=PGIFFNMBCAOPEHGGKOGJODID
SERVER RESPONSE
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Cache-Control: max-age= 1800
Expires: Tue, 14 Oct 1999 18:24:21 GMT
Date: Tue, 14 Oct 1999 17:54:21 GMT
Content-Type: image/gif
Accept-Ranges: bytes
Last-Modified: Tue, 14 Oct 1999 15:53:27 GMT
ETag: "0d1974fb9d8bc1:ecb"
Content-Length: 293

Notice the two lines enabling content expiration. While Cache-Control affects the proxy cache, Expires affects the browser cache.

You can set custom HTTP headers and content expiration globally or apply them to a specific directory.

To set HTTP headers for content expiration

1. In the IIS snap-in under Internet Information Services, right-click the Web site or virtual directory on which you want to set custom HTTP headers.

2. Click Properties.

3. Select Enable Content Expiration.

4. On the HTTP Headers property sheet, add a custom header in the Custom HTTP Headers box.

   For help in creating a custom header, click the Help button on the property sheet.

5. Click OK.

For more information, see the IIS 5.0 online product documentation.

Rating Content with PICS

Ratings were designed to help parents and teachers control what children could gain access to on the Internet. With IIS 5.0, you can apply Platform for Internet Content Selection (PICS) ratings to your site. PICS associates labels (metadata) with Internet content, by applying a custom HTTP header to the requested documents. By default, the assigned rating will apply for one year, but it can be customized to apply for any length of time.

The following example illustrates the HTTP custom header information, including a PICS rating. IIS 5.0 will append this information to all of the designated documents requested from the site.

CLIENT REQUEST
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 2000)
Host: reskit.microsoft.com
Connection: Keep-Alive
Cookie: HTMLA=FONTSIZE=SMALL; ASPSESSIONIDQGQGQGPQ=ADHNMFMDOCNECFKLJGGNMBBL
SERVER RESPONSE
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
PICS-Label: (PICS-1.0 "https://www.rsac.org/ratingsv01.html" l by "someone@microsoft.com" on "1997.10.17T12:35-0400" exp "1998.10.17T12:00-0400" r
(v 0 s 0 n 0 l 1))
Content-Location: https://domain.com/Default.htm
Date: Fri, 17 Oct 1997 16:36:16 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Tue, 14 Oct 1997 22:55:26 GMT
ETag: "50f59e42f4d8bc1:cd7"
Content-Length: 288

Customizing HTML Footers

Many corporations place a standard footer on each page within a Web site. This can be difficult to maintain, because each individual page must be updated when a change is made to the footer. With IIS 5.0, you can include custom footer information in an HTML file that can be appended to the bottom of specified pages. When the footer is changed, all pages are updated automatically.

Note: Customized HTML footers currently work only with static HTML pages. Since they degrade performance on high-volume servers, you should use them with care.

The footer file should contain only the HTML tags necessary for formatting the appearance and function of the footer content. For example, to create a custom footer that contains copyright information, write an HTML document that contains only the following tag: <B> Example1 Copyright 1997–"1998 </B>.

Building a Web Cluster

Windows 2000 Advanced Server offers customers highly scalable services. If you are an ISP, you are naturally concerned with meeting clients' needs. The best way to guarantee the availability and reliability of your services is by setting up your installation in Web clusters (also called Web farms). Once again, a Web cluster is any Web site served by more than one computer.

When building a Web cluster, you should choose three-tier Web architecture (consisting of Web server programs, COM+ applications, and database applications). The advantage of three-tier architecture is that you can separate the following layers onto different servers, rather than combine them all on one server:

• Publishing content

• Running applications

• Accessing databases

With several inexpensive computers, you can more easily handle large volumes of client requests, without creating any unwanted delays. Sharing the load among more than one computer is especially vital for an ISP that supports critical applications: for instance, those that conduct financial transactions, access databases, support corporate intranets, and perform other key functions on a daily basis.

There are two important terms associated with Web clusters: clustering and load balancing. The next two sections briefly review what these terms mean in the context of Web clusters.

Defining Clustering

Clustering involves grouping independent servers and managing them as a single system. The minimum requirements for a server cluster include the following:

• Two (or more) servers connected by a network

• Cluster management software, such as Network Load Balancing or Cluster Service

The cluster management software performs the following tasks:

• Detects failure on any computer in the cluster

• Recovers from any failure or server overload

• Balances the load of incoming requests over all the servers in the cluster

• Manages the servers as a single system

Clustering servers together into one system offers certain advantages:

• Always Available to Handle Incoming Requests Because incoming requests from clients can be balanced among several servers, the likelihood of overloading one server is diminished. If one server becomes overloaded and fails, load balancing can redistribute requests among the remaining servers, without interruption to clients.

• Easier to Manage Instead of managing each server separately, you can manage them as a unit.

• Greater Scalability You can easily add more servers to the cluster or upgrade existing ones without interruption to incoming client requests.

Defining Load Balancing

Load balancing involves distributing client requests across multiple servers within a Web cluster. Basically, load balancing boosts throughput while keeping response times low. With Network Load Balancing, which is built into Windows 2000 Server, the host detects every incoming IP packet, but only the intended recipient can accept it. Each Network Load Balancing host can specify the percentage of packets that it will handle. Alternatively, the packets can be equally distributed across all of the hosts. If one host fails, the load balancing mechanism redistributes the packets among the remaining hosts.

With the scalability that Network Load Balancing offers, as demand increases, you can upgrade the servers you already have or add new computers to the cluster in order to handle more IP traffic.

The next section describes the load balancing features offered by Windows 2000 Advanced Server: Network Load Balancing, and Cluster Service.

Grouping Load Balancing Features

Network Load Balancing and Cluster Service can enhance the reliability of any installation. Grouping them together is a powerful way to combine back-end database and transactional systems with a Web-based front end, in order to deliver the scalability, availability, and robustness that customers demand. The following list briefly describes each of these solutions and gives an example of how you can integrate them into a three­tier configuration.

• Network Load Balancing Balances the load that is primarily generated from incoming TCP/IP traffic. You can set up Network Load Balancing on the first tier, and balance access to your installation over clustered Web servers.

• Cluster Service Ideal for grouping database services such as Microsoft® SQL Server 7.0 and other data-intensive applications that require high availability. You can set up the Cluster Service on the third tier for tasks such as billing clients and ordering databases.

Creating a Three-Tier Web Cluster

Together or individually, these three load balancing features lend ideal support for three-tier applications. For example, if your ISP installation hosts a Web-based retail business, you could set up the clustering as follows:

• Use Network Load Balancing in order to balance and distribute client TCP/IP connections over multiple servers for the front-end, user interface (UI) layer. As traffic increases, upgrade your existing cluster or add computers to the configuration. Doing so ensures that the site will always be available to handle incoming connections.

• Use Cluster Service in order to offer two-node failover for the application and data­service layers of a three-tier application. This will create a reliable platform for services such as databases, messaging, and similar applications.

Since a traditional ISP will host all three tiers on a single Windows 2000 Server, this topology will introduce some new concepts.

Figure 8.8 shows what a sample Web cluster looks like, while the arrows show how content is replicated.

Figure 8.8 Sample Web Cluster

The next sections will help you create a Web cluster.

Calculating Hardware Needs

To set up an installation for a Web-based retail business, you need to determine how many Web servers are actually needed to host a certain application. You can start with one server, test it, and then upgrade it as necessary.

After testing the single server, you might find that the processor utilization is extremely high, that the cache-hit rates are low, and that the server has many requests lined up in the queue. At this point, you can solve the problem by adding processors, memory, and other hardware devices to increase performance. If these solutions fail to improve performance, you can add Web servers.

While there is no mathematical formula for determining the optimum number of servers you should add, you can select from a variety of Web stress tools to help you decide. One such tool is the Web Application Stress Tool. This tool allows you to simulate the load of thousands of users on your site. In conjunction with the System Monitor, you can easily determine at what point a single Web server will crash. A major bottleneck for any Web server is at the HTTP layer. To combat that bottleneck, you should add Web servers, with the ultimate goal of building a Web cluster.

After stressing the single server, you might decide to upgrade so that you can handle a customer's Web site more efficiently. For example, you can add two more Web servers to make up the first tier of your Web cluster.

Building the First Tier

With two new Web servers added to your installation, you now have to balance the load of requests among three servers by running Network Load Balancing. The three servers will now appear as one to the client. Because you assign only one IP address to the servers grouped into a cluster, managing the cluster is very easy. To configure a DNS server, you would set up reskit1.microsoft.com with the IP address 172.16.1.10. That IP address represents all of the hosts in the cluster (three servers at this point). To learn how to assign an IP address, see the "Configure TCP/IP Settings" topic in the Windows 2000 online product documentation.

With this configuration, you have changed the topology of the site from one Web server to three. Now you can use the Web Application Stress Tool again to test the application. You should see an immediate improvement in performance. Next, stress the cluster again, but this time with thousands of simulated users, making sure that the site consumes far fewer resources than the single computer running IIS 5.0. If the application demands higher availability, you can add more hosts, up to a total of 32.

In addition to building a cluster, another way to improve reliability is to bar customers from writing to the production Web servers (also called end-point servers). Set up a staging server (domain.com, for example), where customers can publish content and test their applications. You can then relegate all authoring and development to the staging server.

If you install FrontPage Server Extensions on the staging server (domain.com), customers can then connect with FrontPage to the staging server, write content, and create applications without bringing an application down on the production Web servers.

Once the data is ready for production, use the Content Deployment feature of Site Server 3.0 to replicate the data from the staging server to the production Web servers. The only element of replication that must be the same across the three Web servers is the Web content. When you need to replicate data, Content Deployment, which is very easy to implement, will save you a lot of time.

As your site grows, you might need a separate log file for each server. If you have three servers in a Web cluster, therefore, you would have to analyze three individual log files, presumably by importing all of them into one source to help simplify the task. The Site Server Usage Analyst offers you an easy way to import these files into a source. You can then generate custom reports representing all the traffic on a Web site.

For even more reliability and availability, you can add another cluster and restrict it to business clients only. In Figure 8.8, this cluster was called reskit.premium.com. The strategy here is to divert mission-critical business requests to reskit.premium.com, while leaving reskit.microsoft.com for the general public.

Once you have added servers, created a staging server, and simplified logging, you will notice that the site has become quite complex. To handle the increasing complexity and increased number of applications, you will probably need to build a second tier, in order to maintain the availability and performance of the Web site.

Building the Second Tier

A site quickly becomes more complicated when ASP applications are run in conjunction with Windows 2000 components. Think of ASP applications as the glue that connects the presentation layer to the application and data services layers. ASP provides a rich and robust development environment. But to really increase the overall application performance, consider adding components.

Use an ASP application to invoke a component that is already compiled with your business logic, which resides on the application servers in the second tier. An application server can simply be a Windows 2000 Server that primarily supplies processor power for components.

At this point, the ASP applications that reside on the first-tier Web servers call on the application servers in the second tier to process the business logic. Part of that process could require that the component fetch data from the back-end database, located on the third tier.

Building the Third Tier

To achieve high availability on the third tier, you need to install Cluster Service. To store all of the back-end data that makes up the third tier, most enterprise customers require a single, high-end symmetric multiprocessing (SMP) server (for example, an eight-processor SMP with 4 gigabytes of RAM) running SQL Server 7.0. Cluster Service can handle mission-critical database management, file and intranet data sharing, messaging, and general business applications.

Instead of relying on one high-end Windows 2000 Server, it's best to add a second server for failover. Joined together, these two servers offer higher availability for incoming requests and simplify the task of managing data and applications. Cluster Service not only allows you to connect two servers into a cluster, but can also automatically detect and recover from server or application failures. In addition, it can juggle server workloads, in order to allow for planned maintenance without downtime.

Cluster Service has a built-in mechanism that can handle server failure. If Cluster Service detects that a server has failed, it automatically transfers ownership of resources (such as disk drives and IP addresses) from a failed server to a functioning one. It then restarts the failed server's workload on the functioning server. The entire process, from detecting a failure to restarting the other server, typically takes under a minute.

If an individual application fails (but the server does not), Cluster Service will typically try to restart the application on the same server. If that fails, Cluster Service moves the application's resources and restarts the application on the other server. For detailed information about Cluster Service, see the Windows 2000 Advanced Server online documentation.

Reviewing the Three Tiers

Now it's time to quickly review the growth of domain.com. In this sample scenario, you started with a single IIS 5.0 Web server, from which you essentially ran everything. Since the customer's application demanded highly available, yet scalable, performance, you built a three-tier Web architecture and implemented high-availability Microsoft technologies to each tier. You then tested the single server with the Web Application Stress Tool and realized that, to achieve even higher availability, you needed to build a Web cluster.

To do this, you initially calculated that three servers would suffice. Then you installed Network Load Balancing, whereby three servers essentially appeared as one. Next, you added a fourth Web server as the development or staging server, to which your customer could publish. In order to replicate the developed content, you implemented the Content Deployment feature of Site Server 3.0 on the staging server and the production Web servers. The customer could then connect through FrontPage to the staging server (domain.com), and you were able to easily replicate content to the production Web servers.

To increase performance in the second tier, you added a COM+ application and used ASP applications from the first tier to call on precompiled components from the second tier. These second-tier components called on the third-tier data service.

A high-end SMP server running SQL 7.0 made up the third tier of the system. To achieve high availability, you added Cluster Service, to ensure a fault-tolerant failover system. This topology provides high availability and scalability in spite of planned failures (such as service-pack or hardware upgrades) or unplanned failures (such as hardware failure or the loss of software integrity). If you are an ISP, you can deploy this architecture for your enterprise-level customers who run e-commerce sites or other mission-critical business applications on the Web. You can also use this topology for your common or commodity­type hosting, in which many customers participate within the single cluster.

Adapting IIS 5.0 to a Sample Installation

The following section presents solutions to possible real-life requirements, by showing you how IIS 5.0 can be adapted and tailored to various configurations. Obviously, there is no set solution for a specific ISP installation. Each installation has its own unique requirements, resources, and budget constraints, some or all of which may force you to:

• Adapt your existing network infrastructure, instead of building everything from scratch.

• Tailor solutions to meet customer needs. For example, the architectural design of an e­commerce solution would differ from a home-banking or a Web-publishing solution.

• Work with the unique connectivity requirements of your installation, which most likely was built with specific constraints to solve specific problems.

Although this scenario might not fit your installation exactly, it can serve as a guide for creating your own solutions.

Several Business Clients

Inspired Technologies ISP wants to deliver services for several businesses that cannot afford or do not want to spend money on an in-house Internet gateway. These businesses do, however, want Internet services such as:

• Simple Mail Transfer Protocol (SMTP) and POP3 access to e-mail.

• A Network News Transfer Protocol (NNTP) server for dedicated use (in other words, customer support).

• A Web-hosting server.

Ken from Mightyflight Toys has decided to build three networks in one—an architecture that he mapped out in Figure 8.9.

Figure 8.9 Topology with Several Business Clients

Three Networks in One

The architecture for Mightyflight Toys is set up so that a firewall filters access to the Internet. Specifically, the firewall lets in data directed at the services listed in the previous section (SMTP, POP3, NNTP, and so forth), while filtering out unwanted data directed at the other servers. Behind the second router, the architecture is divided into three different networks:

• Front-end

• Back-end

• Administrative

Front-End Network

Since the front-end network consists of all the servers connected to the Internet (production Web servers), it handles traffic coming from and going to the Internet. It can also host the following:

• SMTP and POP3 servers for e-mail connectivity

• One NNTP server for private newsgroups

  Note: Mightyflight Toys doesn't support Usenet. If the company did, it would have to come up with a different topology, because Usenet news exchanges a large amount of data among the production Web servers.

• A production Web server and a staging Web server, in order to host and publish customer content.

  Both of these servers exchange data through the back-end network; here, the Content Deployment feature of Site Server copies content from one server to another. This synchronizes content on high-traffic, multiserver Web sites.

• A DNS server that holds the information for the Internet domains that are hosted in a server cluster.

  The secondary DNS for all of these domains can be here, too. This would balance the workload of the primary DNS, if it were to be overloaded, thus distributing primary and secondary domains between the two computers.

Back-End Network

The back-end network contains the following:

• Production Web servers

• Other servers (such as a mailbox storage server, as well as a SQL server for Web-based applications that require access to a database or to legacy systems)

• WINS Servers

• Domain Control Servers

• Internal DNS Servers

In this network, traffic flow is generated by the production-server applications, which do not go directly to the Internet.

Administrative Network

The administrative network contains computers that manage the platform. This network accesses the production Web servers through the back-end network. Note that the administrative network can be shared across many platforms. In other words, the computers dedicated to administration can also administer or monitor other servers or Web clusters in the same facility.

Advantages of This Topology

This topology works well for the following reasons:

• It does not overload the front-end network with traffic generated by applications or with network traffic coming from the administration servers. Therefore, the full front­end network bandwidth can be dedicated to the Internet connection.

• The back end, where the data is stored, is not directly exposed to the Internet. Instead, only the services in the production Web servers can gain access to the back-end network, thus interposing an isolation layer between the network where the actual data resides and the Internet.

  You might want to set up an isolation layer to protect the customers' stored data. If the data is eventually exposed to the Web through the Web server, you need to protect it from unwanted alteration. The domain controllers are in the back end in order to keep them from direct exposure to the Internet.

  Note: In this solution, all of the dual-homed computers must have the IP routing option turned off. Otherwise you will lose this layer of isolation.

In the front-end network you must use only officially released Internet addresses, because the front end is the only network connected to the Internet. In the back end, you should use private IP addresses (like 10.x.x.x class A addresses or 172.16.x.x class B addresses that are properly subnetted) in order to save officially released IP addresses for the front end. All traffic between the back-end and the front-end networks passes through the applications in the production Web servers.

Example: Querying a SQL Server

The following procedure shows how a query extracts data from a SQL server database:

1. The user sends a request through the Internet to the front-end network.

2. A Web application then queries the SQL server through the back-end network.

3. The SQL server sends the data back to the Web server through the back end.

4. The Web application builds the response HTML page dynamically and sends it back to the Internet user through the front-end network.

In this example, the network traffic can be divided in order to save bandwidth.

In summary, here are the steps that were used in planning a sample architecture:

1. The network segments were split in order to divide network traffic properly and save bandwidth.

2. An isolation layer was placed between the Internet and the back-end network, where the actual data was stored, thus enforcing the security of the data in the back-end network.

Every component (production Web servers, routers, firewall, switches, and so on) of a cluster can easily be duplicated to offer a greater failover. This way, if one of the components fails, the redundant one starts immediately, thereby reducing the number of off-line services.

Expanding the Platform: Considerations and Suggested Guidelines

You can expand this network architecture to fit your needs. When doing so, you should include the following factors in your plans.

Network Traffic

Even if 100 megabytes per second (MBps) of Ethernet seems to be enough bandwidth initially, remember that this bandwidth is actually shared by all the servers in the network segment. For example, if there are 10 Web servers accessed equally in a 100 MBps network segment, only 10 MBps of bandwidth will be available to each server. To increase bandwidth, you can add some other production Web servers to the existing architecture. Or you can build a similar architecture, if the traffic generated by the production Web servers will overload the existing architecture.

Legacy Applications

You can set up a similar architecture for hosting Web applications that require a connection with some legacy systems. Through the back-end network you can set up a gateway to the legacy system that supplies data to your Web application. You can also build an isolated architecture in order to better protect the legacy system from undesired access by other network segments.

Isolating the various networks helps you set up particular security policies (dictated by customers such as banks) for only a limited number of servers, rather than securing the entire facility. In addressing security issues, you also need to address the costs involved and strike a balance.

Future Expansion

Never underestimate the need for future expansion of Web clusters, because it is inevitable. Note, also, that in this architecture you can scale up the number of Internet connections (just before the firewall), if you need more bandwidth.

Bottlenecks

Sometimes the firewall can turn into a bottleneck if there is a lot of Internet traffic, because it must check every single packet of information flowing in and out of the cluster. To alleviate this problem, see if your firewall software allows you to set up multiple firewalls. If so, you can add other firewalls between the access router and the router connected to the switch, in order to meet the new bandwidth requirements. This way, traffic can be divided among multiple firewalls.

Some Notes on Security

While this section does not provide an exhaustive list of things to do in order to ensure a secure connection to the Internet, it does give some points to bear in mind when you set up an Internet connection. In general, it is better to talk about "levels" of security when discussing the subject. For detailed information about IIS 5.0 security, see "Security" in this book.

First, try to block all unwanted traffic at the router and firewall level. Routers can implement some very elementary rules to allow or deny packet traffic transported between networks or specific hosts, but they are hard to configure. In addition, routers usually do not implement every feature that you might need.

Second, try not to load the CPU of the router with complex access rules that can be easily implemented by a firewall. Usually, Internet Control Message Protocol (ICMP) traffic is blocked with routers. A firewall is a more sophisticated application than a router. It runs on a dedicated computer with two network interfaces, checking every network packet that flows in and out of these interfaces. It will block or allow packet traffic according to specific rules. Firewalls usually offer a better way of tracking dropped packets in log files, which could be a sign of potential network intrusion. For the highest level of security, monitor the log files constantly.

Third, you can set up the Windows operating system to audit accesses on specific resources and to have them recorded in the Security Log. For information, see the Windows 2000 Server online product documentation. For more information about auditing, see "Security" in this book.

In order to prevent unwanted Internet connections to your production Web servers, you can disable the bindings to the workstation, server, and NetBIOS interface.

To disable bindings

1. Open Control Panel.

2. Double-click the Network and Dialup Connections.

3. Right-click Local Area Connection, and click Properties.

4. Select the network adapter for which you want to disable the bindings.

5. Clear the check box in front of all components except Internet Protocol TCP/IP.

6. Select Internet Protocol TCP/IP, click Properties, and on the property sheet, click the Advanced button.

7. On the WINS property sheet, select Disable NetBIOS over TCP/IP, and click OK.

8. Click OK again and close each property sheet.

9. Restart your computer.

   Note: Only experienced administrators should perform this task. If you choose the wrong network adapter, the services might not perform correctly in the back-end network.

For a broader perspective on security in the Windows environment, as well as in-depth information about many aspects of the Windows operating system and Internet security, see "Security" in this book, as well as https://www.microsoft.com/security/default.asp.

Additional Resources

The following Web sites provide additional information about IIS 5.0 and about other features of Windows 2000 Server.

Web Links

https://www.microsoft.com/products/prodref/458_ov.htm

Discusses Microsoft® Windows NT® Enterprise Edition.

https://www.microsoft.com/products/prodref/636_ov.htm

Discusses Microsoft® Site Server® Commerce Edition.

Gives you an insider's view of how Microsoft operates and maintains its Web site.

https://www.microsoft.com/security/default.asp

Supplies a list of security issues related to Microsoft products.

https://www.microsoft.com/isn/

Gives the latest news and information about Microsoft Internet technologies.

https://search.office.microsoft.com/assistance/producttask.aspx?p=FrontPage

Links to updated information about FrontPage.