IIS Insider - November 2004

By Brett Hill

Limiting CPU Usage of IIS on the Server

Q: Our Windows Server 2003 Enterprise Edition hosts a number of applications we rely on. We've noticed that response on the server is sometimes sluggish when our IIS 6 applications are in use. In looking at the CPU use, the IIS applications sometimes consume considerable CPU time when doing certain tasks. Is there some way to limit the amount of CPU use that IIS uses on the server?

A: Within IIS 6, you can use Enable CPU monitoring (show below) which permits limited control of an application pools CPU use.

If your browser does not support inline frames, click here to view on a separate page.

When set to No action, an event viewer message is recorded when the applications pools CPU use exceeds the designated threshold. When set to Shutdown, the application pool is shut down for the interval designated in Refresh CPU usage number.

While this may be useful in a limited number of circumstances, true CPU throttling can be achieved with the Windows Services Resource Manager (WSRM) available with Windows Server 2003 Enterprise Edition. This jewel allows you to not only constrain any applications CPU use to a predefined amount, but to schedule such constraints and assign them to specific users and groups.

Shown below is the Add Running Process form in WSRM that allows you to designate a running process, including any instance of W3WP.exe (your application pool).

If your browser does not support inline frames, click here to view on a separate page.

In this way, you define a rule known as the "Process Matching Criteria." This rule is used to by WSRM in choosing what processes WSRM. Then you create a "Resource Allocation Policy" that enforces your designated CPU limits on the processes identified in the Process Matching Criteria.

For more details on the capability of WSRM, see https://www.microsoft.com/windowsserver2003/technologies/management/wsrm/default.mspx

Restricting Specific User Permissions for Multiple Web Sites

Q: I was reading some of the IIS Insider articles and found them very helpful. I am having trouble finding info on a particular area of IIS and that is permissions for multiple web sites.

What I will be doing in the near future is setting up a shared hosting environment in Windows Server 2003. I will have multiple web sites and I want to restrict particular users to their web sites.

I didn't see anything specifically on this topic. Do you have any insight on this topic?

A: If the users have Windows accounts that are used to authenticate to the server, then access is controlled through NTFS, the same way you harden a file server. This requires judicious use of the large groups like Everyone, Users, Authenticated Users, Domain Users, and the Network groups. Anytime you use one of these big buckets for permissions, you give access to most users that authenticate including the anonymous user.

One of the first things you have to decide is if you need a unique anonymous user for each site. This will provide the highest degree of isolation between web sites, but is more difficult to administer. With a unique anonymous user, you ensure that someone who is permitted to browse content anonymously in one web site cannot access directly or indirectly content on another web site (while in the security context of the anonymous account).

I recommend you manage permissions for web sites you want to isolate from each other using groups. Create a group for "class" of users for the web site and assign users to the group. This method is one of the best practices for managing permissions on a local server and makes it easier to change who can have access to the files by simply controlling group membership. For example, you can create a group called Web Site A Browsers and assign to it "Read" permissions for static content and scripts and "Read and Execute" to .dll and .exe programs. Next, consider applying the "Deny Write" permission for this group to the entire webcontent directory tree to ensure that anonymous users cannot write to the web server. This protects you in the event that someone applies the "Write" permission to a group such as Users or Authenticated Users, both of which include the IUSR_<servername> account. Of course, this will disable writing on locations where the web application attempts to write content to the server using the anonymous user account, such as an Access database; so you will need to explicitly assign the "Write" permission for any such locations and remove the "Deny Write" permission if you implemented that suggestion. Be sure you don't assign "Execute" and "Write" to any location that a non-trusted user can access!

Depending on the degree of security you require, you may want to create a unique anonymous user account for each web site. Place the account you use for anonymous access into the Web Site A Browser group and you have site that is properly configured for your anonymous access. One of the advantages of securing with groups in this way is that if you have other users that have authenticated accounts, but you want to treat them as if they were anonymous users, you can make them "anonymous equivalents" by adding them to the Web Site A Browser group.

Next, create a Web Site A Authors group and place users into the group that you want to publish to the web site. Assign this group "Write" permissions to the entire web site directory tree.

Finally, you should consider using Domain local groups and users rather than local groups for permissions. The primary reason for this is that local users and groups cannot be copied to another server. In the event that you need to upgrade to a new operating system by doing a clean installation and moving your web sites, you would need to completely rebuild your users, local groups, and permissions. For some servers, this is a complex and error-prone task. If you copy files with permissions assigned to domain groups and user accounts, the new server is able to enforce those permissions presuming it is a member of the domain or trusted domain. This can also be an issue during disaster recovery. As usual, this is a tradeoff of functionality versus security as it is not recommended from a security perspective that your anonymous user be a domain based account. However, for some setups, such as a trusted intranet or stand-alone forest in the DMZ or web farm, a domain based anonymous user is an acceptable risk.

These suggestions permit you the greatest flexibility when managing your web server so that users from one site do not have privileges on another site. For even higher security with IIS 6.0, you may need to have unique application pool identities. For details on how to create a high degree of isolation, see the white paper Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0.

Should IISReset Be Used in IIS 6.0?

Q: I've heard that I should not use IISReset to reset IIS 5 or IIS 6, even though it is recommended in the documentation for IIS 5. The KB article 286196 suggests using net stop iisadmin and then to net start the individual services. Is this more reliable in IIS 6 and why is it a risk in IIS 5?

A: IISReset appeared first in IIS 5 as an alternative to stopping and starting IIS related services with the net command, as was required with IIS 4. It does provide a generally reliable way to reset IIS 5 in most situations. As the KB article explains, "The IISReset command line tool waits for a normal shutdown of the services before it starts them again. Because of the number of services that are dependent on the IISAdmin service, the shutdown may not occur in a timely manner." If IIS has not shut down before the timeout, the services are killed and changes you have made to the Metabase may not be written, and as a result your IIS configuration will seem to "revert" to a previous configuration. This will only occur in situations where either IIS is hung or you have a very large Metabase.

The solution is issue IISRESET with the /NOFORCE command along with /TIMEOUT:xxx, where xxx indicates the number of seconds you want to use before IISRESET stops waiting on the reset.

Keep in mind that using IISRESET with IIS 6 is rarely required. In most cases, you can recycle an application pool and achieve the same results. Recycling is much less severe than an IISRESET which causes the server to shut down all applications including FTP, SMTP and NNTP. As a result, if you are in the habit of using IISRESET to restart applications, retrain yourself and rewrite your scripts to recycle the application pools instead.

You can find more information on IISRESET in the IIS 6 Resource Guide and the following Microsoft KB articles:

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months' questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.