In-depth analysis of IIS 6.0 (four)

If you right-click on an application pool, web site group, or individual website, then choose New → Application Pool (from file), or New → Site → From File, or New →→Virtual Directory (from file), you can create a new application pool, Web site or virtual directory from the saved configuration file. Therefore, when necessary, we can create and configure only one object, use the "Save configuration to a file" function to export the configuration information of the object, and then use the "New" → "Virtual directory (from file)" and other functions to configure the information. Import to multiple web sites. This means that we can carefully configure a template and then use it to create and configure a new website. Of course, a copy of the configuration information can also be used to restore the settings of the website in the event of a problem.
Since IIS 6.0 configuration information is portable, it has another benefit, which is convenient for upgrades. Suppose we can't install Windows 2003/IIS 6.0 directly on Win 2K/IIS 5.0 when upgrading. We must change one machine. At this time, we need to solve the problem of how to transfer IIS 5.0 non-portable configuration data to the new IIS 6.0 server. To make use of the portability of IIS 6.0 configuration data, the solution is: first install a new Windows 2003 server, do a complete backup for the original Win 2K server, and then install a second Windows 2003 server on the Win 2K server. Upgrade, export the configuration data of the second Windows 2003 server (encrypted with a password), and then import the configuration data to the new Windows 2003 server. The newly installed Windows 2003 server must make some adjustments, such as allowing the IUSR account, etc., but at least it is not necessary to re-execute all configuration operations.

The configuration data for IIS 6.0 is a standard text file (XML file), so it can be opened and edited with a text editor such as Notepad. If you modify the configuration data of IIS 5.0 or IIS 4.0, you sometimes have to restart IIS. If the number of websites on the system is large, it may take a lot of time. For example, the ISP's server is such a case. To solve this problem, IIS 6.0 supports a "Runtime Allow Editing" feature. The Runtime Allow Editing feature is enabled as follows: In the IIS Manager, right click on the server, select the menu "Properties", and then select the "Allow direct editing of the configuration database" option, as shown in Figure 3. After enabling this feature, if we open the configuration data file with Notepad, insert a virtual directory configuration, and then save and close the configuration file, IIS 6.0 can be modified almost immediately according to the configuration file settings, no need to restart .

Figure 3

Since the configuration file is allowed to be edited directly, the server and application failures caused by the invalid configuration files are bound to increase. To this end, IIS 6.0 provides a configuration file history version directory, ie \\system32\\inetsrv\\history, each time you modify the configuration data or restart IIS 6.0, IIS 6.0 will save a copy of the original configuration data in the directory.
Third, IIS Manager
Every major product upgrade, people will try to find exciting new features from the user interface. The IIS 6.0 manager did change, but the changes were unexpectedly small.

One of the changes is small but practical. If you right-click on a folder in IIS Manager, you can now select the Permissions menu to open the folder's Security dialog. In this dialog you can set the NTFS authorization for the folder without having to leave the IIS Manager. Although this is a minor change, perhaps it will save thousands of hours of work time for all IIS administrators worldwide this year.

Right-click on a Web site, select "Properties", go to the "Directory Security" page, click on the "Edit" button under "Secure Communications", where you can find another important change - - The Secure Communications Properties page allows you to configure SSL, Certificate Trust List (CTL), and client certificates. In IIS 5.0 and IIS 4.0, this property page cannot be accessed unless a certificate is installed on the Web site. This limitation is unpleasant because technically, configuring CTL and client certificates does not require a certificate to be installed on the server. In other words, the only use of the certificate we installed in IIS 5.0 was because the user interface needed it. IIS 6.0 corrects this extra requirement, and now we don't have to install a certificate on the web server to access and use the property page.

IV. Wildcard Applications

If you are familiar with ISAPI filters for IIS 5.0 and IIS 4.0, you may be familiar with their shortcomings. ISAPI filters are not only difficult to write, but because they run inside the Inetinfo process, if you accidentally leave a mistake when writing, it can easily lead to catastrophic consequences, and the wrong code may cause the entire IIS to crash. In addition, ISAPI filters cannot have the functionality that a regular ISAPI DLL has. Of course, in IIS 5.0 and IIS 4.0, ISAPI filters are still a very useful component and the only code that can perform operations on all requests coming into a web server or web site.

IIS 6.0 provides a new and more flexible mechanism to provide the services normally provided by ISAPI filters. It is an ISAPI Interceptor or a Wildcard Application. The wildcard application is configured by right-clicking on the Web site in IIS Manager, selecting the menu "Properties", going to the "Home Directory" page, clicking on the "Configuration" button under "Application Settings", and "Application Configuration" appears. Dialog box, as shown in Figure 4. In the "Mapping" page of the dialog, we can configure one or more ISAPI DLLs as wildcard applications. For each received request, IIS 6.0 will call each of the wildcard applications listed here. In addition to configuring wildcard applications for all websites, you can also configure wildcard applications for a single website or at the directory level. Since these ISAPI interceptors are standard ISAPI applications, they have all the features of a normal ISAPI application, including the ability to access the body of a message, rather than just accessing the header like an ISAPI filter.

The wildcard application can do anything the developer does, such as URL customization, verifying identity, logging special log information, detecting attack attempts, creating content, and more. After the wildcard application finishes processing, it forwards the request to the appropriate processing engine (for example, asp.dll that processes the ASP page), and the processing engine further processes the request. In addition, the wildcard application can also pass requests to any page in the same application pool by calling the new ExecuteURL function for the ISAPI application.
The new ISAPI wildcard app opens the door to creative application design. For example, the URL authorization feature of IIS 6.0 is implemented as an ISAPI wildcard application (urlauth.dll). The URL Authorization feature allows IIS 6.0 to grant access to a URL based on a set of rules, such as whether a user is a member of a group, a geographic location, and other information related to the user in the database or AD. For more information on ISAPI wildcard applications and URL authorization, see the IIS 6.0 help documentation.

V. Log Function

The log function of the server is rarely the primary concern, but it is an indispensable assistant for day-to-day server management and monitoring. IIS 6.0 has many major improvements in logging capabilities, but unfortunately, W3SVC log events are still not recorded in local time.

In IIS 6.0, logging has been changed to http.sys, and http.sys is running in kernel mode. This improvement speeds up log writes while avoiding multiple worker processes competing for the same log file. In some special cases, http.sys will encounter an error, when it should but can not write the log information to the log of the Web site, for example, the work process is being recycled, prohibiting http.sys from processing user requests, or users I tried to connect to the server, but the request only provided a portion of the information needed by IIS. If this happens, http.sys will write the event to a new log file, httperr.log.

In the process of troubleshooting and optimizing IIS 6.0, the httperr.log log file is very important. By default, the httperr.log file is saved in the \\system32\\logfiles directory, but can be modified by modifying the HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\HTTP\\Parameters registry subkey and adding a string named ErrorLoggingDir below it. Value, set the full path to the save log file in ErrorLoggingDir. Information that can be found in the httperr.log log file includes: all 503 (service unavailable) errors, idle connection timeouts, various errors when parsing URLs, and the last 10 requests submitted to the failed application pool.

IIS 6.0 also has a function called binary log. After enabling this function, IIS 6.0 will write all log information of the Web site to a log file in binary format. The extension of the log file is. Ibl. To enable the binary logging feature, simply set the W3SVCC/CentralBinaryLoggingEnabled entry of the configuration file to ture(1). This feature should be very useful for ISPs. There may be 1000 or more Web sites on each machine of the ISP. If each Web site generates a log file every day, the total number of log files will soon reach an astronomical number. Microsoft's recently released Log Parser 2.0 tool reads binary log files and generates reports. This tool can be downloaded at http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe. Log Parser 2.0 also reads the httperr.log file described earlier and generates reports.

Since a long time ago, IIS has allowed to specify a directory on the local server where log files are saved. However, although the IIS Manager for IIS 5.0 and IIS 4.0 allows you to enter a remote server's Universal Naming Convention (UNC) path when specifying the log file path, the Web server does not actually save the log to the remote server. Only IIS 6.0 really supports the UNC pathname of the log file path.