IIS Sites, Application Pools, and Bindings

A binding defines where and how a website listens for traffic. It has three components: IP Address — a specific IP address on the server or * (all unassigned IPs). Port — the TCP port (80 for HTTP, 443 for HTTPS, or any custom port). Host Name (Host Header) — the HTTP Host header value the site responds to (e.g., www.example.com). All three together form the unique key. Two sites cannot share the same IP:Port:HostName combination. Multiple bindings on one site allow it to answer on HTTP and HTTPS, or on multiple hostnames (with or without SNI). An empty hostname means "respond to any Host header on this IP:port that isn't claimed by another site."

DefaultAppPool is the application pool that IIS creates automatically with the Default Web Site. It runs as ApplicationPoolIdentity under .NET v4.0, Integrated pipeline mode. Production applications should NOT use DefaultAppPool because: (1) it is shared — if you put multiple sites or apps in DefaultAppPool, they lose isolation; a crash in one app crashes the pool for all. (2) It uses the generic system account rather than a dedicated identity — security principle of least privilege requires each app to run under its own identity. (3) Default recycling settings (29-hour cycle at an arbitrary time) are not appropriate for production. Best practice: create a named application pool for every production application.

The idle timeout setting (default 20 minutes) causes WAS to shut down the worker process if no new requests arrive within that period. When the pool is idle-stopped and a new request arrives, WAS must start a new w3wp.exe, initialise the CLR, warm up application state, and process the request — this creates a "cold start" delay of potentially tens of seconds for the first request after idle. For always-on production APIs (especially those with health check pings from load balancers), set idle timeout to 0 to disable it. For infrequently accessed internal tools, the default is fine as it conserves memory. Never use idle timeout with Application Initialization warm-up — they conflict.

Use Host Headers (also called Host Name in the binding configuration). Configure Site A with binding: *:80:siteA.example.com. Configure Site B with binding: *:80:siteB.example.com. DNS must resolve both hostnames to the same server IP. When an HTTP request arrives, HTTP.sys reads the Host header from the request and routes it to the matching site. This is the standard method for multi-site IIS hosting — you can host hundreds of sites on a single IP:port combination, each identified by its Host header value. IIS 10.0 added Wildcard Host Headers support (*.example.com) to capture all subdomains with a single binding.

Application Pool Identity (identityType=4) is a virtual service account automatically created by IIS when an application pool is started. The account name follows the pattern IIS AppPool\PoolName. It is not a real user account you can log into — it exists only while the pool is running. Benefits: automatic creation (no manual account management), automatic membership in IIS_IUSRS group, minimal privilege (no logon rights, no admin rights), and isolated between pools (IIS AppPool\Pool1 and IIS AppPool\Pool2 are different security principals). Limitation: it cannot authenticate to remote resources over the network — for network access (SQL Server, file shares, AD), use a gMSA or domain user account instead.

In App Pool Advanced Settings → CPU section: set Limit (percentage). Specify in thousandths of a percent: 25% = 25000. Set Limit Action: NoAction (just log), KillW3wp (terminate the process when limit is reached), Throttle (reduce CPU allocation but don't kill), ThrottleUnderLoad (throttle only when overall CPU is high). Set Limit Interval (minutes, default 5 — the window over which CPU is averaged). Example: set 50000 (50%) with Throttle action to prevent any single app pool from monopolising more than half the CPU. This is critical for shared-hosting environments. PowerShell: Set-ItemProperty IIS:\AppPools\MyPool -Name cpu.limit -Value 50000; Set-ItemProperty IIS:\AppPools\MyPool -Name cpu.action -Value "Throttle".

Technically IIS supports tens of thousands of sites — there is no hard-coded limit in the software. Practical limits: (1) Memory: each app pool worker process uses 10-50 MB baseline. 1000 pools × 50 MB = 50 GB RAM required. (2) SSL: each HTTPS site traditionally needed a dedicated IP for SSL (pre-SNI). With SNI (IIS 8+), multiple HTTPS sites share one IP. (3) W3SVC startup: IIS reads all site configuration on start — thousands of sites cause long startup delays. (4) applicationHost.config: the configuration file gets large and complex with hundreds of sites. Real-world large IIS deployments (shared hosting) keep pools to 50-200 and use idle timeout to keep only active pools alive. For elastic scaling, prefer containerised deployments (Windows containers) over packing hundreds of sites on one IIS server.

Export full IIS config including sites, pools, and bindings: %windir%\system32\inetsrv\appcmd list config /config.section:system.applicationHost > applicationHost_backup.xml. More precisely for migration: appcmd add backup "PreMigrationBackup" — this creates a backup in %windir%\system32\inetsrv\backup\PreMigrationBackup. To restore: appcmd restore backup "PreMigrationBackup". For individual site export: use Web Deploy (msdeploy) which packages a site with its content, config, and certificates. The IIS configuration backup/restore approach is the fastest way to recover a corrupted applicationHost.config without reinstalling IIS — a critical runbook step in disaster recovery planning for IIS environments.

The site's physical path is the root directory for the site's root application (/). All relative URL paths that don't match an application or virtual directory map inside this root path. A virtual directory's physical path is a separate directory that is mapped to a URL alias within the site. Example: Site root = C:\inetpub\wwwroot\MySite → request to /index.html serves C:\inetpub\wwwroot\MySite\index.html. Virtual directory /uploads → D:\SharedUploads → request to /uploads/file.pdf serves D:\SharedUploads\file.pdf. Virtual directories are used when content lives on a different drive/server (mapping UNC paths like \\fileserver\docs is also supported). Important: virtual directories inherit the app pool identity of their parent application for NTFS access checks.

SNI (Server Name Indication) is a TLS extension that allows the client to specify which hostname it wants to connect to during the TLS handshake — before the server has sent the certificate. Before SNI, each HTTPS hostname required its own dedicated IP address (because TLS handshake happens before the HTTP Host header is sent — so IIS couldn't distinguish which certificate to present without reading the Host header, which wasn't available yet). With SNI: IIS reads the SNI extension in the TLS ClientHello and selects the matching certificate. Multiple HTTPS sites can share one IP. IIS 8.0 (Server 2012) added SNI support. Configure in IIS Manager → Bindings → Add HTTPS binding → check "Require Server Name Indication" and enter the hostname. Required for Let's Encrypt certificates on multi-site IIS servers.

1. Install IIS and the web-deploy (msdeploy) role on the new server. Match IIS version, .NET Framework versions, and URL Rewrite/ARR modules. 2. Export each site with msdeploy: msdeploy -verb:sync -source:webServer,computerName=OldServer -dest:package=allsites.zip or per-site packages for individual control. 3. Export SSL certificates from the old server's certificate store (MMC → Certificates → Personal → export with private key as PFX). 4. Import SSL certificates on the new server, noting the new thumbprints. 5. Import sites from package: msdeploy -verb:sync -source:package=allsites.zip -dest:webServer,computerName=NewServer. 6. Update SSL certificate bindings in IIS to reference the new thumbprints: netsh http show sslcert and re-bind with appcmd set site. 7. Verify NTFS permissions on all site physical paths for the pool identities. 8. Test all 20 sites locally on the new server (modify hosts file). 9. Switch DNS. 10. Keep old server live for rollback for 24-48 hours.

This means another IIS site already has that exact binding. Find it: appcmd list site /bindings:"http/*:80:myapp.company.com". If the conflicting site is an old decommissioned site: delete or stop it, then add the binding to the new site. If the conflicting site is active and serving traffic: you need to differentiate them. Options: (a) use a different port for the new site (if it's internal and users can reach a non-standard port); (b) use HTTPS on the new binding instead; (c) update the conflicting site's binding to use a different hostname if appropriate. If the conflicting binding is on the same site but you want to add HTTPS: add a new binding for https/*:443:myapp.company.com — the HTTP and HTTPS bindings can coexist for the same hostname. Never delete a binding from a live site without confirming with the site's owner first.

The randomly stopping pools have the idle timeout setting enabled (default 20 minutes). When no requests arrive for 20 minutes, WAS shuts down the worker process. The pool itself remains configured and will restart on the next request (a 5-30 second delay for the cold start). This is intentional IIS behaviour to conserve memory on servers with many low-traffic sites. To fix for specific critical pools: in App Pool Advanced Settings → Process Model → "Idle Time-out (minutes)" set to 0. Alternatively, configure a health-check endpoint to ping the pool every few minutes, keeping it alive without changing configuration (a common approach for SLA-critical sites that must have sub-second response on all requests, even after quiet periods).

They are deploying to the same physical path and the same application pool. The second deployment's files are overwriting the first's (or partially overwriting causing a hybrid broken state). If the app pool hasn't recycled, some in-memory state from the first deployment is still running with files from the second on disk — catastrophic mix. Resolution: each developer or release needs its own isolated environment. Correct setup: create separate IIS applications under the site — /app-devA (physical path C:\dev\app-A, pool DevA-Pool) and /app-devB (physical path C:\dev\app-B, pool DevB-Pool). In production, use a staging slot pattern (Blue/Green): site "app-blue" and site "app-green" with a single load balancer rule switching traffic between them after validation. Never let two deployments share the same physical directory or application pool without a clear, atomic file swap mechanism.

The key is overlapping recycle (default enabled). Confirm it is on: App Pool → Advanced Settings → "Disable Overlapping Recycle" = False. Configure recycling at low-traffic time: set Specific Times under Recycling (e.g., 3:00 AM), remove the default 29-hour interval recycle (set Regular Time Interval to 0). Set Shutdown Time Limit to 300 seconds (give long-running in-flight requests adequate time to drain). Enable Application Initialization (Web-AppInit feature): configure startMode="AlwaysRunning" on the app pool and create a warm-up initializationPage in the application. IIS will spin up the new worker process, send the warm-up request, wait for a 200 response before switching HTTP.sys routing to the new process. With these settings, users will not see any visible interruption during a scheduled pool recycle — the new process is fully warm before any public traffic reaches it.