Internet Information Services (IIS, formerly Internet Information Server).
All versions of IIS prior to 7.0 running on client operating systems supported only 10 simultaneous connections and a single website. IIS 7.0 on Vista does not limit the number of allowed connections as IIS on XP did, but limits concurrent requests to 10 (Windows Vista Ultimate, Business, and Enterprise Editions) or 3 (Vista Home Premium). Additional requests are queued, which hampers performance, but they are not rejected as with XP.
IIS use IUSR as the anonymous user.
IIS Express, a lightweight (4.5–6.6 MB) version of IIS, is available as a standalone freeware server.
It is portable, stores its configuration on a per-user basis, does not require administrative privileges and attempts to avoid conflicting with existing web servers on the same machine.
By default, IIS Express only serves local traffic.
In earlier versions of IIS, a local account called IUSR_MachineName is created during installation. IIS used the IUSR_MachineName account by default whenever anonymous authentication was enabled. This was used by both the FTP and HTTP services.
There was also a group called IIS_WPG, which was used as a container for all the application pool identities. During IIS setup, all the appropriate resources on the system were granted the correct user rights for the IIS_WPG group so that an administrator only needed to add their identity to that group when they created a new application pool account.
Drawbacks. The IUSR_MachineName account and the IIS_WPG group were both local to the system that they were created on.
This experience has been improved in IIS 7 and above by using a built-in account and group. A built-in account and group are guaranteed by the operating system to always have a unique SID. IIS 7 and above have taken this further and ensured that the actual names that are used by the new account and group will never be localized. For example, regardless of the language of Windows that you install, the IIS account name will always be IUSR and the group name will be IIS_IUSRS.
In summary, IIS 7 and above offer the following:
The IUSR built-in account replaces the IUSR_MachineName account.
The IIS_IUSRS built-in group replaces the IIS_WPG group.
The IUSR account no longer needs a password because it is a built-in account. Logically, you can think of it as being the same as the NETWORKSERVICE or LOCALSERVICE accounts.
The main difference in processing stages between IIS 7.0 and IIS 6.0 is in how ASP.NET is integrated with the IIS server. In IIS 6.0, there are two request processing pipelines. One pipeline is for native-code ISAPI filters and extension components. The other pipeline is for managed-code application components such as ASP.NET. In IIS 7.0, the ASP.NET runtime is integrated with the Web server so that there is one unified request processing pipeline for all requests.
When the unified pipeline receives the first request for any resource in an application, an instance of the ApplicationManager class is created, which is the application domain that the request is processed in. Application domains provide isolation between applications for global variables and enable each application to be unloaded separately. In the application domain, an instance of the HostingEnvironment class is created, which provides access to information about the application, such as the name of the folder where the application is stored.
Application objects such as HttpContext, HttpRequest, and HttpResponse are created and initialized. The HttpContext class contains objects that are specific to the current application request, such as the HttpRequest and HttpResponse objects.
The application is started by creating an instance of the HttpApplication class. If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class. To maximize performance, HttpApplication instances might be reused for multiple requests.
Tasks are performed by the HttpApplication class in processing the request. The events are useful for page developers who want to run code when key request pipeline events are raised.
An Application Pool is, in short, a region of memory that is maintained up and running by a process called W3WP.exe, aka Worker Process.
The process in memory, W3WP.exe in this case, is a macro memory region for applications that stores subset regions, called Application Domains. One process in memory may store different Application Domains, one for each application.
AppDomain is restarted when refreshing the existing configuration: web.config, machine.config, global.asax, Bin directory, App_Code.