IIS Informant - 08 Mar 2000

Update
In response to the December 1999 IIS Informant question regarding security in IIS 5.0, IIS Administrator received a letter from Michael Howard, who works for Microsoft in Windows 2000 (Win2K) security. Howard provided additional information regarding IIS 5.0 security that I think you'll find interesting.

Integrated Windows authentication. In this column and in various Microsoft TechNet articles, Integrated Windows authentication appeared to be a renaming of Windows NT Challenge/Response authentication. Howard correctly pointed out that Integrated Windows authentication applies not only to legacy NT Challenge/Response authentication but also to Kerberos-based authentication when

Digest authentication. Regarding Digest authentication, the Microsoft article "IIS 4.0 and 5.0 Authentication Methods Chart" at http://www.microsoft.com/technet/iis/technote/authmeth.asp states that the first step in enabling Digest authentication is to "make copies of user passwords on the Windows 2000 domain controller," which is what I reported. As it turns out, however, the process is easier than manually making copies of the passwords and managing them as a clear text document on a domain controller. Thank goodness.

Instead of copying passwords as the above article suggests, if you're running a Win2K domain server in Native mode, go to a user's Account tab in Active Directory Users and Computers, then check the Store password using reversible encryption check box, which Screen 1 shows. Selecting this check box creates a locally encrypted file of the passwords for users with this option enabled. (Even though the file is encrypted, it's considered plaintext because the OS, not IIS or the client's browser, does the decrypting.) Rather than specifying this setting for each user, you can use Group Policies to turn this setting on or off for the entire domain, site, or organizational unit (OU). In the beta and release candidate (RC) versions of Win2K, Microsoft called this option Save passwords as encrypted clear text. The Microsoft Internet Information Services 5.0 Resource Guide, which is part of the Microsoft Windows 2000 Resource Kit, incorrectly specified that now-nonexistent option as the means of enabling Digest authentication. The guide should, instead, refer to the new option, Store password using reversible encryption.

I've inherited an IIS 4.0 server at work. The Web site has several virtual directories that are mapped to almost identical physical directories. In other words, the path listed on the virtual directory is essentially the same as the actual path. How do I remove the virtual status of these directories? I need the directories and their contents, but I don't want them to be virtual directories.

Fortunately, the virtual directory is just an alias for the path to the actual directory. Using the Microsoft Management Console (MMC), you can highlight and delete the virtual directory without affecting the underlying file structure. However, this action might affect access to the Web pages in those directories. Before you remove the virtual directories, make sure the actual folders reside under the home folder for the Web site; otherwise, users won't have a path to the folders' contents.

I've come across an apparent bottleneck in my Web application. I used NT Performance Monitor to observe the Active Server Pages Object: Requests Executing counter, which will reach up to 20 requests under stress but doesn't rise above that. When this counter hits the threshold of 20, the Requests Queued counter starts to rise, signaling that Active Server Pages (ASP) processing is maxed out. What can I do to increase the server's capacity to process ASP requests?

You can tune several Registry entries to help with ASP processing, but the results are unpredictable. What works for one installation can be a disaster on another, so you need to test carefully. For example, 20 on the Object: Requests Executing counter refers to the number of threads that your processor can execute. A thread (a small section of code that executes on a processor) is part of an overall program called a process. A process that uses multiple threads is multithreaded. IIS can not only use multiple threads but can also take advantage of NT's ability to use multiple CPUs and simultaneously execute a thread on each CPU. This feature is one of IIS's strengths and leads to great scalability.

To prevent threads from overrunning a CPU, IIS limits the number of threads per processor that can exist at one time to 10. This limitation exists because putting threads onto and removing them from a processor takes time and can impede processor performance. When threads can't execute, they queue to execute. My guess is that you have a dual-CPU server, so when you hit 20 executing threads (10 on each processor), requests start to queue instead of execute.

Knowing that your system is limiting execution to 10 threads per CPU isn't enough information. Before loading your CPUs with more threads, you must find out whether those CPUs have any extra horsepower to handle the additional load. The usual procedure in this situation is to measure the CPU utilization. If the Processor: %Processor Time counter is near 50 percent when you reach your 20-requests bottleneck, then increasing the maximum number of threads per CPU can improve your performance. However, if your CPU usage is near capacity, increasing the number of threads per CPU will hurt performance. In that event, you need to either streamline your code, add CPUs (which might or might not help), or balance the load with other servers.

Adjust the Registry. To adjust the number of threads permitted per CPU, add the parameter ProcessorThreadMax as a REG_DWORD value to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesw3svcaspparameters Registry key. (Use extreme caution when making changes to the Registry.) In addition to a CPU-related bottleneck, if your queue rate goes up and processor usage goes down after you raise this setting, it can signify that the threads are running code that is blocking the next thread from executing in a timely way. Blocking happens as a result of poorly designed objects, code that waits on other events to occur before completing, or other errors. If, however, processor usage stays under 60 percent and performance improves, you can increment ProcessorThreadMax until you reach a CPU utilization that is acceptable while leaving some headroom for peak usage. Be sure to use care on this setting.

Another potentially useful Registry parameter is RequestQueueMax. This key exists under the same Registry key as ProcessorThreadMax and controls the number of queued threads your system permits. Remember that a thread queues only when the processor is too busy to execute it. When demand on the server is heavy and the RequestQueueMax setting is too large, users simply sit waiting for something to happen. If you reduce the size of RequestQueueMax, users receive a Server Too Busy message instead of starting yet another set of requests on an already-overburdened system. (Of course, you've scaled your server better so that you won't have this problem!) A good rule of thumb (and a place to start) is to set RequestQueueMax equal to the number of threads. For example, if you have two processors with 30 threads each, set RequestQueueMax to 60.

There's a great deal to know about this topic. Before making any changes to a production IIS server, you must have a good baseline, target, and plan. A good place to start learning about these and other settings is the Microsoft white paper "Navigating the Maze of Settings for Web Server Performance Optimization" (http://www.microsoft.com/backstage/whitepaper.htm). Also, the Microsoft Windows Internet Information Server Resource Kit contains an excellent chapter about performance tuning. The Microsoft Developer Network (MSDN) has a quick reference for IIS tuning parameters at http://msdn.microsoft.com/workshop/server/feature/tune.asp.

These parameters have changed locations in IIS 5.0 (Win2K only) because many properties that used to be in the Registry are now in the metabase. For more information about the ASPProcessorThreadMax metabase property, see the Microsoft article "How to Tune the ASPProcessorThreadMax" at http://support.microsoft.com/support/kb/articles/q238/5/83.asp.

I need to be able to send mail from my IIS 4.0 server and have determined that using Collaboration Data Objects for NT Server (CDONTS) is the best option. I found a CDONTS mail script at http://www.15seconds.com, but I'm having trouble running it. When I run the script, the following error appears:

Microsoft VBScript runtime error '800a0046'Permission deniedcdomail.asp, line 20

Line 20 has only one entry—objmail.send. Of course, this line sends the mail. Both the IUSR and IWAM accounts have access to cdonts.dll, and SMTP permits Anonymous access. What's the problem?

CDONTS is an excellent way to send email on an IIS system. You can use the CDONTS objects directly from ASP, which lets you gather information from a form and mail out results, send automatic replies, send administrative alerts from error pages, or just about anything else you can think of. CDONTS works in conjunction with the SMTP service.

You said you're getting a permission denied message and you checked permissions for access to CDONTS. However, you must also check your permissions on the mailroot folder and its subfolders, which the SMTP service created during installation and which CDONTS through SMTP uses to write the outgoing email.

Another, more obscure possibility exists, too. If you're running your ASP applications out of process, you can receive the same message you cited. By default, out-of-process applications don't have access to the metabase in which the SMTP settings reside, so when the application attempts to use SMTP, the SMTP settings aren't available. One workaround is to make the IWAM account (which SMTP uses by default for out-of-process applications) an operator in SMTP. (I don't recommend this change for security reasons, but you can do it.) Alternatively, don't run the application out of process.

As you said, http://www.15seconds.com is an outstanding resource for these and many other IIS matters. For more information about CDONTS and SMTP, see the Microsoft articles "HOW TO: Use CDONTS to Collect and Mail Information from a User" at http://support.microsoft.com/support/kb/articles/q186/2/04.asp and "PRB: ASP Running CDONTS Applications Out of Process Fails" at http://support.microsoft.com/support/kb/articles/q184/2/70.asp.

I recently installed Microsoft FrontPage 2000 Server Extensions on my IIS 4.0 Service Pack 6a (SP6a) system. Occasionally, when I perform Recalculate Web, a crash occurs with the following Dr. Watson error:

Dr. Watson for Windows NTAn error has occurred and an application error log is being generated.mmc.exeException: access violation (0xc0000005), Address: 0x67f26153

Is this a bug in the server extensions?

When you perform Recalculate Web, an OK message box, such as Screen 2 shows, appears when the recalculation is complete. You must click OK before you perform Recalculate Web for any other web, or you'll receive the Dr. Watson error. For more information about this error and its cause, see the Microsoft article "Dr. Watson Occurs Recalculating Web or Check and Fix in MMC" at http://support.microsoft.com/support/kb/articles/q217/7/56.asp.

Occasionally, IIS seems to stop logging. I can't seem to pin down the cause. Do you have any suggestions?

This behavior occurs if the log files become corrupted. Changing the log file folder or renaming the log file usually fixes the problem. Also, periodically, IIS flushes the log cache; when it does, IIS uses the security context of the currently running thread. If that context doesn't have rights to the log files, the logging process can falter. To avoid this problem, grant Everyone or the Anonymous account Change permission to the log folder.