Internet Information Server (IIS) 4.0's numerous features can often overwhelm users familiar with IIS 3.0 or other Web servers. Two of the biggest concerns many users struggle with are how to properly set up IIS 4.0 and how to use IIS's built-in or add-on tools to resolve application problems. For example, you can easily omit a feature when you're installing IIS that you might need later. And if you're familiar with IIS 3.0, you can easily overlook many of IIS 4.0's new and helpful features, such as the debugging tools. I want to tackle these concerns this month by focusing on IIS setup and configuration. Specifically, I'll show you what you need to do during the IIS setup to use FrontPage and Visual InterDev with IIS and how to configure IIS to use Active Server Pages (ASP).
Setting Up IIS for Your Needs
The first step in using IIS 4.0 is to make sure you properly use the setup
process to install the software. If you don't select the options you need during
the setup process, your Web applications or Web sites might not work. Let's look
at the IIS setup options.
Minimum. The Minimum option minimizes the amount of disk space IIS consumes and installs only the components required to run ASP applications and to provide database connections with ActiveX Data Objects (ADOs) and Remote Data Services (RDSs). This option also installs the Internet Service Manager (ISM) snap-in for the Microsoft Management Console (MMC) to manage IIS.
Typical. The Typical option loads the same components as the Minimum option. In addition, this option installs the FTP service, the HTML version of ISM for Web-based IIS management, and the online documentation.
Custom. The Custom option lets you decide which components you want to install. When you select this option, you can specify the destination of the installation files and see how much disk space each component consumes. You can also choose to install part or all of the components. For example, you might want to install all the options for Microsoft Transaction Server (MTS).
When I install IIS, I always use the Custom option because the other two options make assumptions about how I want to set up the system. I prefer to review each component and choose the ones I need to meet my requirements. Likewise, you need to select and install the components that are right for your environment. For example, if you use FrontPage or Visual InterDev with IIS 4.0, you must install the FrontPage 98 Server Extensions that come with IIS and the Windows NT 4.0 Option Pack. Screen 1, page 180, shows the NT 4.0 Option Pack Setup dialog box with the FrontPage 98 Server Extensions selected. If you install and enable FrontPage 98 Server Extensions for your entire Web server, you can always use MMC to turn them off later for a particular Web site.
If you use Visual InterDev with IIS, you need to use the Custom option during IIS 4.0 setup to install the Visual InterDev rapid application development (RAD) Remote Deployment Support component. If you don't add this component, your users won't be able to use some of Visual InterDev 6.0's deployment features, such as remotely installing ActiveX components or MTS packages.
You must use the Custom option to install other optional components, including support for MTS and Microsoft Message Queue Server (MSMQ). Although the Minimum and Typical options install some MTS- or MSMQ-related components, these options don't include all the detailed components you need. Make sure you know every option that you install.
The IIS setup process can take between 35 minutes and 1 hour, depending on which components you install, how many applications you have on your Web server, and how many files each application has. You can safely upgrade an IIS 3.0 installation to IIS 4.0, although you must take the server offline while you perform the installation.
Configuring Specific Web Applications
After you install IIS 4.0, you can use several configuration options to
customize the software. For example, you can use these options to control ASP
for an entire Web server, a virtual directory, or a particular directory. When
you create a virtual directory, you are mapping the virtual directory to a
physical directory. To create a virtual directory, you right-click Default Web
Site in ISM, and select New, Virtual Directory from the context menu. This
process starts the New Virtual Directory Wizard. The first screen of the wizard
contains the permissions for the new virtual directory. If the directory will
contain ASP, you must select the Allow Script Access check box or Allow
Execute Access \[includes Script Access\] check box for the scripts to
execute. You might want to clear the Allow Read Access check box to stop
anyone from reading the contents of the script files. You can use the
application's properties dialog box to change the same application permissions.
To establish application permissions, place your script files in separate directories associated with the application. You can set script access on these directories and use other directories for .htm and other files that need read access. This approach protects the script directories from having read access, and protects the other file directories from using script access. This configuration prevents users from placing executable scripts in any directory except the script directories.
After you create a directory or virtual directory that you want to use as a Web application, you must change the AppRoot property setting to point to the directory or virtual directory; otherwise, IIS won't treat the directory or virtual directory as an application. Open ISM, and go to the Application Settings section at the bottom of the application's Properties dialog box to configure the AppRoot property setting. To set the AppRoot property, click Create. I entered NTMag into the Name text box, and clicked Create (after you set the AppRoot property, the Create button becomes the Remove button, as you see in Screen 2).
When you create a Web application, IIS uses MTS to add the application to the IIS In-Process Applications package. You can see the IISWAM.1_ROOT_NTMag entry in the package, as Screen 3 shows. This is the entry for your new Web application. The IIS In-Process Applications package runs all in-process applications in the IIS process space (netinfo.exe). This behavior is the same in IIS 3.0 and IIS 4.0.
You can change this behavior by selecting the Run in separate memory space (isolated process) check box under the Application Settings section of the application's Properties dialog box. When you select this option, IIS uses MTS to create a new package and move the Web application into the new package. I selected the Run in separate memory space (isolated process) check box, and refreshed the packages in the MTS Explorer. Screen 4 shows that IIS has removed the application entry (IISWAM.1_ROOT_NTMag) from the list in the left pane of the MTS Explorer. When I changed the isolated process setting, IIS created the new MTS package, IIS-\{Default Web Site//Root/NTMag\}, which you see in Screen 4. That package contains the Web application and runs in a separate memory space.
If you run the Web application and use Task Manager to watch the system processes, you notice that isolated applications use a few CPU resources from inetinfo.exe. However, the application is running in the mtx.exe (a part of MTS that executes the application) process space. As a result, mtx.exe uses the most resources.
Because isolated applications run in a separate memory space, they perform slower than non-isolated applications. When a process running in one memory space (such as inetinfo.exe) needs to communicate with a process in another memory space (such as mtx.exe), the operating system (OS) must go through an extra, resource-intensive step known as marshalling to facilitate the communication between the two applications. As a result, the application's performance degrades significantly.
So, if isolated applications run slower, why use them? Four good reasons to isolate an application in a separate memory space are
- You want to prevent an application that is misbehaving from bringing down IIS.
- The application is in development, and you want to protect IIS from application problems.
- You need to change components in the application over several days without stopping IIS.
- The application is using MTS components that you're testing.
If you isolate an application, you must monitor the server and the application to ensure that the performance doesn't degrade to the point where the application is unusable. You can use tools such as Performance Monitor, Task Manager, and MTS Explorer to monitor applications.
When a user requests a page from the Web server, IIS inspects the URL to determine whether the file type maps to an executable. If so, IIS passes the page to the Web Application Manager (WAM), which manages each application, and the WAM invokes the appropriate executable to handle the file. If you look at Screen 3 and Screen 4, you notice that each application has the string WAM in its name. If you look at the properties for a Web application, you will see that the entry maps to the c:\winnt\system32\inetsrv\wam.dll.
ASP map to the asp.dll processor you see in Screen 5. These mappings are the default settings for files in a Web application. By looking at these mappings, you can see how IIS maps various file types to a processor. If you change these settings, IIS will no longer use the default processor for files in that particular application. You can enable mappings for an Internet Server API (ISAPI) extension or Common Gateway Interface (CGI) program by adding entries to the list, or remove mappings by deleting entries.
Depending on the needs of your application (e.g., if your application uses .htm and .asp files), you might want to take particular actions. For example, if your application redirects users to a logon page from the Session_OnStart event in global.asa, users might be able to bypass this logon scheme. These users get around the logon page by entering a URL for a .htm page in the address line of the Web browser or by choosing a URL from the Favorites list that points to a .htm page. When IIS sees the .htm file, it will not execute the global.asa file because .htm files don't map to asp.dll.
You might encounter problems in an application that uses a session state when users access .htm pages and the application doesn't touch a .asp page during the session's timeout period. This situation causes the session to time out because the session timer doesn't update when the users access .htm pages.
You can solve both the logon bypass and the session timeout problem by mapping .htm files to asp.dll. When you map these files to asp.dll, IIS treats .htm files exactly the same as .asp files processed with asp.dll. When a user accesses a .htm file, IIS processes global.asa and updates the session state timer. The downside of mapping .htm files to asp.dll is that IIS processes these .htm files slightly slower than other .htm files. This slowdown is the result of asp.dll not processing each file directly, which adds to the overall processing time.
Whether you map .htm files to asp.dll depends on your Web site. You can evaluate the effect this action will have by testing your site and recording the results. You can monitor the mapping performance with Performance Monitor, and you can use the Web Capacity Analysis Tool (WCAT), which comes with the Microsoft Internet Information Server Resource Kit, to test various application configurations, including running the site with a mixture of .asp and .htm files and various combinations of users.
To map .htm files to asp.dll, you select the .asp entry you see in Screen 5, and click Edit. Highlight the text in the Executable box in the Add/Edit Application Extension Mapping dialog box, and press Ctrl+C to copy the entry to the clipboard. Next, note the other settings for the entry, and close this dialog box. Click Add, and press Ctrl+V to add the text string you copied from the .asp mapping into the Executable box in the Add/Edit Application Extension Mapping dialog box. Next, enter
.htm
in the Extension box. Your entry will look similar to what you see in Screen 6. Click OK to close the dialog box and make the change permanent. If you map .htm files to asp.dll, you must select the Script engine check box so IIS can process these files with asp.dll when they are in a directory with script access.
Another application setting you might want to change is the cache setting for script files. This setting is on the Process Options tab of the Application Configuration dialog box. You can set this application to one of the following three options: Do not cache ASP files, Cache all requested ASP files, or Max ASP files cached. These settings affect the performance of the application and how users use it. When asp.dll processes an ASP, it compiles, executes, and stores the page in the server's memory cache. IIS searches the cache first when a user requests an ASP. If IIS finds the page in the cache, the software executes the page without accessing the disk and recompiling the file, which results in large performance savings.
IIS defaults to using the second option, Cache all requested ASP files. This selection caches every ASP until the server runs out of available cache memory. You can control this setting by selecting the third option, Max ASP files cached, and entering the number of files you want to cache.
The Do not cache ASP files option is useful for application development. Often, when you are developing an application, you must take steps to ensure your server removes pages from the cache before you retest them. For example, when you edit an ASP, IIS automatically removes it from the cache and recompiles it. However, if you edit an include file (a script or HTML file that is included in another file at runtime), IIS doesn't remove the pages that use the include file from the cache when you make changes to those pages. Therefore, changing and retesting your Web pages can be difficult if you rely on include files. To work around this situation, you can set the Do not cache ASP files option and test files without worrying about which files are cached and which ones aren't. Then when the application is ready for limited testing, you can set the cache option to one of the other two settings.
Debugging IIS
IIS 4.0 provides many tools and features that simplify running ASP
applications. One tool, the Script Debugger, enhances IIS 4.0's features by
letting you gracefully debug your Web applications. Microsoft's Visual InterDev
6.0, which will soon be widely available in beta, also includes several
debugging features that you can use remotely to test your Web applications.
Visual InterDev 6.0 will be a valuable upgrade because it includes complete
round-trip (i.e., client and server code) debugging.
Next month, I'll show you how and why to use the debugging tools that come with IIS 4.0 and Visual InterDev 6.0. You will learn how these tools can help developers reduce the time they need to create Web applications and reduce the cost of maintaining these applications.
