Capstone: Designing and Hardening a Production IIS Deployment

Web Servers Fundamentals' own capstone compared three servers across several scenarios. This one is different, by design — the same shape Nginx In Depth's and Apache In Depth's own capstones both used: a single, cohesive worked example, layering in each of this course's own eight prior chapters, one at a time, until one complete, production-shaped IIS deployment exists.

The Scenario

One IIS server hosts one site, www.example.com, serving a customer-facing ASP.NET Core storefront application at the site root, plus a small internal reporting API reachable at /api — used only by staff on the corporate network, never by customers. Both need to keep working reliably, and the internal API specifically must never be able to take the storefront down with it if something goes wrong.

Step 1 — Application Pool Design (Chapter 2)

Two separate pools, each under its own dedicated ApplicationPoolIdentity — no shared built-in account, so a compromise or misconfiguration in one pool's identity carries no access to the other's resources. The storefront pool runs AlwaysRunning, since checkout traffic can't tolerate a cold-start latency spike. The reporting API pool keeps the default 29-hour scheduled recycle — it's genuinely low-traffic, so a brief overlapped recycle is a non-issue.

Step 2 — Locking the Configuration Model (Chapter 3)

The authentication section ships Deny-locked by default, exactly as Chapter 3 covered — so enabling Windows Authentication for /api specifically (needed in Step 7) has to happen via a <location> block in applicationHost.config, not from /api's own web.config. Every other section stays at its default overrideModeDefault, since neither application needs anything else locked down beyond this one deliberate exception.

Step 3 — Handler Mapping for ASP.NET Core (Chapter 4)

Both applications run in Integrated mode, the modern default from Chapter 4 — the storefront's own managed authentication and session modules see every request uniformly, static assets included, exactly the unified pipeline that would have been impossible under the old Classic mode's split native/ASP.NET handling.

Step 4 — Promoting /api to Its Own Application (Chapter 5)

/api is deliberately an application, not a plain virtual directory — precisely so it gets its own Application Pool and its own isolated .NET AppDomain, per Chapter 5. If the reporting API ever crash-loops into Rapid-Fail Protection, only ReportingApiPool goes offline — the storefront's own StorefrontPool is a completely separate worker process, untouched.

Step 5 — URL Rewrite for the Storefront (Chapter 6)

Applied only to the storefront, not /api — a real customer-facing Redirect to enforce HTTPS, and an internal Rewrite for clean product URLs, exactly the Rewrite-vs-Redirect distinction Chapter 6 drew. No rule here ever points at a different backend server's URL — this stays entirely within-server rewriting, deliberately not reaching for ARR.

Step 6 — HTTPS Binding with SNI (Chapter 7)

A single certificate, installed in the Windows Certificate Store and bound by thumbprint via SNI — /api shares this exact binding, since it's a path under the same site, not a separate site with its own certificate needs. A recurring calendar reminder is set for 30 days before expiry, specifically so the binding's thumbprint gets updated the moment the certificate is renewed, per Chapter 7's own renewal gotcha.

Step 7 — Authentication and Filtering for /api (Chapter 8)

/api uses Windows Authentication (enabled via Step 2's own <location> override) with an SPN explicitly registered for www.example.com against the reporting service account — done up front here specifically to avoid Chapter 8's own silent-NTLM-fallback trap. ipSecurity restricts /api to the corporate network's own subnet, deny-by-default. Request Filtering blocks .config requests site-wide, so neither application can ever accidentally expose its own web.config contents.

Step 8 — Performance, Logging & a Pre-Flight Tracing Check (Chapter 9)

Static assets (.css, images) get kernel-mode caching — genuinely eligible, since they're anonymous and untouched by URL Rewrite. The storefront's own product pages stay out of kernel-mode caching deliberately, since Step 5's own Rewrite rule applies to them, exactly the eligibility gotcha Chapter 9 named. Failed Request Tracing is scoped tightly to /api alone and only to genuine failure status codes — enabled for the initial rollout window to verify the new Windows Authentication and IP restriction rules actually behave as intended, with a plan to disable it once that's confirmed rather than leaving it running indefinitely.

Hands-On Exercises