Logging
A server's logging capabilities rarely get top billing, but you rely on them for the day-to-day management and monitoring of a server. IIS 6.0 provides several significant logging enhancements, but unfortunately, you still can't record W3SVC log events in local time.
In IIS 6.0, the code for recording logs has been moved into http.sys, which runs in the kernel. This setup writes logs more quickly and prevents contention among worker processes for one log file. In some cases, http.sys encounters an error that it should but can't record in a Web site's logs. For example, a worker process might be recycling, preventing http.sys from processing a request, or a user might make a request to connect to the server but send only part of the information IIS requires. Http.sys records these events in a new log file called httperr.log.
Httperr.log is vital in troubleshooting and performance-tuning IIS 6.0. By default, the log is in \system32\logfiles, but you can change the location by adding to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters registry subkey a string value named ErrorLoggingDir that contains the full path to the target folder. Items you'll find in the log include all 503 errors, idle connection timeouts, errors incurred while parsing the URL, and the last 10 requests submitted to a failed application pool.
IIS 6.0 also sports a feature called binary logging that, when enabled, writes to one log file in a binary format all the logging information for a Web site. To turn on binary logging and create a centralized binary log file ending in .ibl, you set the metabase entry W3SVCC/CentralBinaryLoggingEnabled to true (1). This feature could prove useful to ISPs that host 1000 or more Web sites per box. If each Web site creates a log file each day, the resulting number of log files quickly becomes astronomical. The recently released Microsoft Log Parser 2.0 tool can read the binary log file and create reports. You can obtain the tool at http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe. (Log Parser can also read and report on the httperr.log file mentioned earlier.)
If you want to write log files in a language other than English, you can also tell http.sys to use UTF-8 instead of ASCII for the log-file character set. To do so, right-click the local computer in IIS Manager to open the Properties dialog box and select the Encode Web logs in UTF-8 check box.
IIS has long let you specify in which folder on the local server you want to store log files. However, although IIS 5.0 and IIS 4.0 IIS Manager let you enter the Universal Naming Convention (UNC) pathname of a remote server as the location for log files, the Web server wouldn't actually store the files on a remote server. IIS 6.0 supports a UNC pathname for the log-file directory.
Site ID Generation
A number, not a name, uniquely identifies Web sites to IIS. When you create a new Web site in IIS 5.0 and IIS 4.0, the Web server gives that Web site the next available number in sequential order (i.e., the Web server gives the default Web site the number 1 and subsequent Web sites that you create the numbers 2, 3, and so on). You need to know the site ID number to access the site's set of log files, which has a path that ends with \W3SVC\siteIDnumber. If you have more than one site, you can't tell by looking at the log-file folder names which log-file folder belongs to which Web site. You also need the site ID number for any serious scripting or metabase modifications because specifying the Microsoft Active Directory Service Interfaces (ADSI) path to a metabase key often involves specifying the correct ID.
Nevertheless, site ID numbers aren't obviously visible in IIS 5.0 and IIS 4.0 IIS Manager. To remedy this situation, IIS 6.0 IIS Manager has a new Identifier column that lists the site ID number. You might be surprised to see that your IIS 6.0 site ID numbers are large, even if you have only two or three sites. The first site I created had the site ID 387660891 (and the path \W3SVC\387660891). IIS 6.0 doesn't number sites sequentially—it uses a formula based on the site name. This approach can be useful in a Web farm in which you want identical Web sites, including identical site ID numbers.
You might have scripts or utilities that are dependent on the sequential numbering system for site IDs. To disable the new numbering system and use the sequential system, open the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters registry subkey, create a REG_DWORD value named IncrementalSiteIDCreation, and set it to 2. This subkey isn't present by default.
Prev. page
1
2
[3]
4
next page 
