What is IIS and How It Works

IIS (Internet Information Services) is Microsoft's web server component included with Windows. It receives HTTP/HTTPS requests from clients, routes them to the appropriate web application or file resource, and returns the response. It handles static file serving, ASP.NET application hosting, SSL/TLS termination, authentication, compression, request logging, and URL rewriting. IIS runs as a Windows service (W3SVC) and is managed through IIS Manager GUI, PowerShell, or command-line tools like appcmd. It is the standard web server for .NET Framework applications and is widely used for hosting ASP.NET Core, PHP, and static sites on Windows Server.

The Default Web Site is the web site that IIS creates automatically when installed. It is bound to port 80 on all IP addresses (*:80) and serves content from C:\inetpub\wwwroot. It runs in the DefaultAppPool application pool. In a fresh IIS installation, browsing http://localhost returns the IIS welcome page (iisstart.htm). In production environments, the Default Web Site is often either deleted or repurposed — deploying actual applications as separate sites with their own bindings, application pools, and physical paths rather than placing content directly in wwwroot. Leaving the default site active without content exposes a recognisable IIS fingerprint to reconnaissance tools.

IISRESET is a command-line tool that stops and restarts all IIS services: W3SVC, WAS, and the related HTTP listeners. It is used after: configuration changes that require service restart (most config changes in IIS are hot-loaded and do NOT require iisreset — only changes to the applicationHost.config schema or global module registration need a restart). Also used when IIS is in a stuck/degraded state that prevents normal operation. Warning: iisreset drops all active connections to all hosted sites simultaneously — on a busy production server this causes a traffic spike to load balancer fallbacks and session loss for stateful apps. For production, prefer recycling the specific app pool (appcmd recycle apppool /apppool.name:MyPool) rather than a full iisreset.

Site (top-level): A named container that has one or more bindings (IP:port:hostname combinations) and a root application. Each site maps to a physical directory on disk. Application: A named sub-path within a site that runs in its own application pool and has its own web.config. For example, a site at http://example.com could have an application at /api/ running in a separate app pool with a different .NET version. Virtual Directory: An alias path within an application that maps to a physical directory elsewhere on disk (e.g., /images → D:\SharedImages). Virtual directories do not run code — they just provide a URL path to filesystem mapping. A site contains applications; an application contains virtual directories.

Kestrel is the lightweight, cross-platform web server built into ASP.NET Core itself. IIS is the full-featured Windows web server. In production on Windows, they are typically used together in two patterns: Out-of-process: IIS receives HTTP requests and forwards them to a separate Kestrel process via the ASP.NET Core Module (ANCM). Kestrel handles the .NET runtime. IIS handles SSL termination, authentication, URL rewriting, and static files. In-process: IIS hosts the .NET runtime directly inside w3wp.exe via ANCM in-process hosting — better performance but the application lifecycle is coupled to the w3wp process. In-process is the default for ASP.NET Core 3.0+. Kestrel alone is not recommended for direct internet exposure — it lacks the security hardening, logging, and management features of IIS.

The IIS request pipeline is the ordered sequence of processing stages a request passes through. There are 19 defined request processing stages from BeginRequest to EndRequest. At each stage, registered IIS modules can execute code. Modules are of two types: Native modules — C++ DLLs registered as IIS modules (e.g., RequestFilteringModule, StaticFileModule, AnonymousAuthenticationModule, HttpLoggingModule). These run with almost no overhead. Managed modules — .NET classes implementing IHttpModule, registered in web.config. These run only in Integrated Pipeline mode. The most critical modules: StaticFileModule, DefaultDocumentModule, DirectoryBrowsingModule, AnonymousAuthenticationModule, ManagedEngine (loads CLR for .NET requests). Missing a module causes 404.7 or 500.19 errors depending on what was referenced in config.

Each application pool specifies a .NET CLR version (No Managed Code, v2.0, or v4.0) and a managed pipeline mode (Classic or Integrated). v2.0 includes .NET 2.0, 3.0, and 3.5. v4.0 includes .NET 4.0 through 4.8.x. For ASP.NET Core, the .NET version is handled within the w3wp process via the ANCM — set pool to "No Managed Code" and the ANCM bootstraps the correct Core runtime version as specified in the app's runtimeconfig.json. This means you can host .NET Framework 3.5, .NET 4.8, and ASP.NET Core 8.0 simultaneously on the same IIS server by placing each application in a separate pool with the correct settings.

ARR (Application Request Routing) is an IIS extension that turns IIS into a reverse proxy and load balancer. It can distribute incoming requests across a server farm (multiple backend web servers), provide health monitoring and failover, implement content-based routing (route /api/ to one farm and /static/ to another), and enable URL rewriting at the proxy layer. Use cases: IIS as a front-end reverse proxy in front of multiple application servers, enabling HTTPS termination at one point for a farm, blue-green deployment by routing traffic to new/old server groups, and providing a single entry point for multiple backend services. ARR pairs with the URL Rewrite module to define routing rules in web.config.

For ASP.NET Framework: Web-Asp-Net (ASP.NET 3.5), Web-Asp-Net45 (ASP.NET 4.5+), Web-Net-Ext (for 2.0/3.5 extensibility), Web-Net-Ext45 (for 4.x extensibility), Web-ISAPI-Ext, Web-ISAPI-Filter. After installing features, run aspnet_regiis -iru to register ASP.NET with IIS (required on Server 2008, not needed on 2012+). For ASP.NET Core: install the .NET Core Hosting Bundle (which includes ANCM), set the app pool to "No Managed Code". Without the Hosting Bundle, ASP.NET Core apps return HTTP 500.0 or 502.5. For both: ensure the IIS application pool's .NET CLR version matches the framework — using v4.0 CLR for a .NET 4.8 app, or No Managed Code for Core apps.

Classic mode (legacy, IIS 6 compatibility): ASP.NET is invoked as an ISAPI extension, running outside the IIS native pipeline. Managed modules (IHttpModule) only execute for requests that match ASP.NET handler extensions (.aspx, .asmx etc.) — not for static files or PHP requests. Integrated mode (IIS 7+): the ASP.NET pipeline is unified with the IIS native pipeline. Managed modules can intercept ALL requests regardless of file extension, enabling global auth, logging, and processing for static files, images, and any URL. Integrated mode is required for many modern ASP.NET features — use Classic only for legacy apps that explicitly break in Integrated mode (typically very old ISAPI-dependent apps from the IIS 5/6 era). New applications should always use Integrated mode.

Single PowerShell script: Import-Module WebAdministration; Get-Website | Select-Object Name,State,@{N='Bindings';E={($_.Bindings.Collection | Select-Object -ExpandProperty bindingInformation) -join ','}}; Get-ChildItem IIS:\AppPools | Select-Object Name,State,@{N='NetVersion';E={$_.ManagedRuntimeVersion}},@{N='PipelineMode';E={$_.ManagedPipelineMode}}. This renders a table of: all sites with their states and bindings, all pools with their .NET version, pipeline mode, and started/stopped state. Stopped pools (State = Stopped) indicate an app pool disabled due to too many crashes (check Event ID 5010 in Application log) — these are the sites currently returning 503. Combine with appcmd list wp to see which pools currently have running worker processes vs. which have not received requests yet.

HTTP 502.5 is "ANCM Out-Of-Process Startup Failure" — the ASP.NET Core Module tried to start the application process (Kestrel or the Core web host) but failed. Check in order: (1) Is the .NET Core Hosting Bundle installed on the server? dotnet --info from command prompt on the server. If missing, install from Microsoft. (2) Is the app pool configured as "No Managed Code"? The CLR version must be No Managed Code for Core apps. (3) Can the application binary run directly? Navigate to site root, run dotnet MyApp.dll — the error message from dotnet run is more informative than IIS's 502. (4) Check stdout logs: in web.config set stdoutLogEnabled=true and stdoutLogFile=.\logs\stdout — this captures the Core startup exception. (5) Check Event Viewer Application log for Application Error or ANCM events detailing the startup failure.

Use Web Deploy (msdeploy): (1) Install Web Deploy 3.6 on both servers. (2) On source: msdeploy -verb:sync -source:webServer -dest:package=C:\backup\site.zip. (3) On destination: msdeploy -verb:sync -source:package=C:\backup\site.zip -dest:webServer. The package includes site configurations, applications, virtual directories, SSL certificate bindings (certs must be re-imported separately — export from source cert store), and application pool settings. Post-migration: verify .NET frameworks needed by the app are installed on the new server, confirm NTFS permissions are correct for new pool identities, update DNS to point to new server IP, run smoke tests, and monitor Event Viewer for the first 30 minutes. Keep the old server running for at least 24 hours in case rollback is needed.

IISRESET stops W3SVC, which signals all w3wp.exe worker processes to stop. Long stop time causes: (1) Active long-running requests — w3wp waits up to the shutdown time limit (default 90 seconds) for in-flight requests to complete before forcibly terminating. Many slow requests = long shutdown. Reduce with app pool Advanced Settings → Shutdown Time Limit. (2) Application-level shutdown logic — .NET applications handle Application_End in Global.asax, which may do cleanup work (flush caches, close database connections). (3) Many app pools — if 15 pools each take 5 seconds to shut down sequentially, total = 75 seconds. IISRESET /noforce doesn't force stop, making this worse. Solution for production: never run full iisreset — recycle individual pools with appcmd recycle apppool /apppool.name:xxx, which does a graceful replacement without dropping connections to other pools.

Immediate: recycle the app pool — if the .NET update introduced a new default in machine.config that conflicts with the app's web.config, the pool may crash once and then stabilise. If it keeps crashing: check Event 1000 in Application log for the faulting assembly. Identify if it's a CLR assembly (mscorlib, System.Web) vs application assembly. For .NET patch rollback: Windows Update allows individual update uninstall. Open Settings → Update and Security → View Update History → Uninstall Updates. Find the .NET Framework cumulative update and uninstall it. Reboot or run iisreset. Note: in enterprise environments, coordinate .NET update rollback with WSUS team and document in change management. Long-term: establish a staging environment that receives .NET patches 5 business days before production — this is the standard enterprise practice for catching regression before production impact.