At the time of writing this article, in the latest version of Windows (Vista,7 and Server 2008), IIS management has changed quite a bit.
IIS7 features some very cool remote management capabilities. In an environment where developers may need access to IIS, but not necessarily the server, or too many remote logins to the server fill up the TS licenses, using IIS remote management can save ALOT of your time and money.
Consider the following scenarios:
New site needs to be added to IIS or changes to existing site need to be made.
1) Developer does not have RDP access due to corporate security policies or may be outside consultant, etc and submits ticket/request for new site to be added
2) Count the time delay until ticket is responded, time to form responses and time spent on actual technical changes.
3) If details regarding site changes sent by developer are adequate, IT helpdesk applies the changes and notifies developer setup successful. If additional info is needed, helpdesk must request more information, then repeat steps 2-3 until complete.
Even if only 1% of all sites require follow up, and approximate ticket response and IIS configuration time is lets say 3-4 hours including delay until ticket is received; if you create 50 sites / annually this equates to 150-200 hours spent simply on site setup.
If your company outsources IT helpdesk, or response time is even slower, 12-24 hours, this is now 600-1200 hours of delay at the same rate of 50 sites / annually.
To save time (and money), consider cross-training developers that don’t know IIS, and setup remote administration in IIS7.
Note some Vista and Windows 7 installations do not come with the manager, and it will have to be downloaded from IIS.net.
For walkthroughs on this configuration and more information, see references below.
TrainSignalTraining, “Remote Administration of IIS 7: Install, Configure, Connect”, http://www.trainsignaltraining.com/iis-7-remote-administration
IIS.Net, “IIS Manager for Remote Administration”, http://www.iis.net/download/IISManager
A great many documents, blogs and references exist on IIS which cover it comprehensively. This article simply serves to discuss one aspect – the application pool.
When configuring IIS in an environment that will contain many websites, there are a few important considerations:
– Will each site potentially run different versions of .NET? Sites with different frameworks should not share the same app pool. This will cause a conflict and they will not be functional.
– Is it a large web application that requires many resources? If yes, you may also want to consider creating it’s own app pool, which allows you to manage detailed information regarding how the server prioritizes the site.
The first tab for the app pool properties displays information regarding memory resource usage. If you have multiple sites on a server which are hit very often and would like to force the amount of memory each one uses, you can create an app pool for each and manage it here.
Or if it will be split evenly among various sites, you can create “groups” of app pools with assigned memory and IIS will allocate among children accordingly.
You can also force the worker process to automatically free up memory after specified interval and/or at different times of the day.
The performance tab allows for CPU resource management. Certain sites may have functions that, left unchecked or still under development, can cause excessive CPU load and affect other processes running on the same server.
Max CPU usage can be assigned here setup in conjunction with events to trigger when these scenarios occur.
A remote exploit or overflow attempt of your server can also be secured here by limiting the maximum number of kernel requests.
Idle timeout can help free up CPU for a site that is not very active. Legacy sites or informational areas which are rarely visited are still using a fraction of the CPU usage, and setting an idle timeout can help release some of those resources.
The health tab can help you diagnose potential issues with your site or application. By forcing certain restrictions such as maximum failures and/or maximum failures within a specific time period, as well as enabling pinging, you can check for periods of down time or help identify timeout issues a specific web service may be experiencing.
This tab works well in conjunction with third party testing tools used to benchmark and stress test your site, application or service.
Depending on the size and nature of your infrastructure, you may want to configure certain application pools to run under different credentials. For highly security conscious people this can theoretically reduce the likelihood of certain privilege escalation techniques that may be executed in the event of a remote application pool exploit.
Hope the above information was helpful. This was a condensed version based on a similar article I read on Windows Networking. See reference below for full article.