How to Host ASP.NET Core on Windows with IIS: A Complete Setup Guide 2026 July

If you need to host ASP.NET Core on Windows with IIS, you are working with one of the most production-proven deployment stacks in the .NET ecosystem. Internet Information Services (IIS) has been the default web server for Windows-based .NET applications for over two decades, and Microsoft has continued to invest in making it a first-class host for modern ASP.NET Core workloads. Whether you are deploying an internal enterprise application, a public-facing API, or a Blazor Server app, IIS on Windows Server gives you fine-grained control over process management, security, and certificate handling.

Understanding how IIS interacts with ASP.NET Core requires grasping a key architectural shift. Unlike classic ASP.NET, which ran entirely inside the IIS worker process, ASP.NET Core is built on top of Kestrel, a cross-platform web server. When you deploy to IIS, you have two hosting models to choose from: In-Process hosting, where your application runs inside the IIS worker process (w3wp.exe), and Out-of-Process hosting, where IIS acts as a reverse proxy forwarding requests to a separate Kestrel process. Choosing the right model depends on your performance requirements, legacy constraints, and operational preferences.

The bridge between IIS and ASP.NET Core is a native module called the ASP.NET Core Module (ANCM). This module must be installed on the server before any ASP.NET Core application will run correctly under IIS. The ANCM ships as part of the .NET Hosting Bundle, which you download directly from Microsoft. Installing the Hosting Bundle on your Windows Server installs the runtime, the ASP.NET Core shared framework, and the ANCM simultaneously, ensuring all the necessary pieces are in place before you deploy your application files.

Server configuration matters as much as application code when it comes to reliable deployments. IIS Application Pools must be configured with No Managed Code when running ASP.NET Core applications, because the .NET CLR lifecycle is managed by the Hosting Bundle itself rather than by IIS's legacy managed pipeline. Failing to set this correctly is one of the most common mistakes developers make when first deploying ASP.NET Core to IIS, and it often results in 500.19 or 500.30 errors that can be confusing to diagnose without understanding the underlying architecture.

Security considerations are central to any IIS deployment. IIS provides robust support for Windows Authentication, SSL/TLS termination, IP address restrictions, and URL Authorization rules. ASP.NET Core applications running behind IIS can take advantage of these platform-level security features while still using the framework's own middleware pipeline for application-level concerns like JWT bearer authentication or cookie-based identity. Understanding where the security boundary sits between IIS and your application middleware is essential to avoiding gaps in your protection model.

Logging and diagnostics are another area where IIS hosting shines. The Enhanced Diagnostic Logging feature of the ASP.NET Core Module can capture startup errors and write them to disk even before your application's own logging infrastructure has initialized. This is invaluable when troubleshooting deployment failures in environments where you cannot easily attach a debugger. Combined with IIS's native request logging (W3C logs), Event Viewer integration, and ASP.NET Core's structured logging support via Serilog or Microsoft.Extensions.Logging, you have a deep toolkit for diagnosing production issues.

This guide covers the complete end-to-end process of setting up and optimizing hosting asp.net core on windows, from installing prerequisites on a fresh Windows Server instance through configuring IIS, deploying your application, and tuning the environment for production reliability. By the end, you will have a clear mental model of how all the pieces fit together and the practical knowledge to deploy confidently.

Configuring IIS correctly for ASP.NET Core goes beyond the initial installation steps. One of the first things to verify after creating your site is the presence and correct configuration of the web.config file in your application's publish output. ASP.NET Core generates this file automatically when you run dotnet publish, and it contains the critical aspNetCore element that tells the ASP.NET Core Module how to start your application. The processPath attribute points to dotnet.exe for framework-dependent deployments or directly to your application executable for self-contained deployments.

The hosting model attribute inside web.config controls whether your application runs In-Process or Out-of-Process. For most new deployments on IIS 10 and later (Windows Server 2016 and above), you should use hostingModel="inprocess" to get the best performance. In-Process hosting avoids the overhead of proxying requests between IIS and a separate Kestrel process, resulting in significantly lower latency and higher throughput. Out-of-Process hosting (hostingModel="outofprocess") is still valuable when you need process isolation, when migrating older applications that depend on Kestrel-specific behavior, or when running on older versions of IIS that do not support In-Process.

Environment variables are a clean way to pass configuration into your ASP.NET Core application when running under IIS. Rather than embedding sensitive connection strings or secrets in your web.config, you can set environment variables at the Application Pool level using the IIS Manager GUI or via the applicationHost.config file directly. These environment variables are available to your application through the standard IIS passes them into the worker process environment, where ASP.NET Core's configuration system picks them up automatically just like any other environment variable.

The stdoutLogEnabled and stdoutLogFile attributes in web.config control startup logging at the ANCM level. By default, stdout logging is disabled because writing every stdout message to disk can impact performance at scale. However, you should temporarily enable it whenever you are troubleshooting a startup failure. Set stdoutLogEnabled to true and stdoutLogFile to a path like .\logs\stdout, then make sure IIS has write access to that directory. After reviewing the logs, disable it again to avoid unnecessary disk I/O in production.

IIS Request Filtering is a security feature that is enabled by default and can sometimes cause unexpected 404 or 405 responses for ASP.NET Core APIs. If your application accepts HTTP verbs like PATCH or DELETE, verify that Request Filtering is not blocking these verbs at the IIS level. You can configure Request Filtering through IIS Manager under the site's feature view, or by adding explicit rules in web.config. This is especially relevant for REST APIs that rely on the full set of HTTP methods for their resource operations.

Windows Authentication deserves special attention when configuring IIS for intranet ASP.NET Core applications. To enable Windows Authentication, you must both enable it in IIS (and disable Anonymous Authentication if you want it enforced for all requests) and configure your ASP.NET Core application to use it via AddAuthentication(IISDefaults.AuthenticationScheme). The ANCM forwards the Windows identity token to your application when running In-Process. Note that when running Out-of-Process, Windows Authentication requires additional configuration because Kestrel itself needs to be informed about the forwarded identity.

Application recycling settings in IIS control how often your Application Pool worker process is restarted. By default, IIS recycles the worker process every 1,740 minutes (29 hours) or when memory usage crosses a threshold. For ASP.NET Core applications, frequent recycling can disrupt in-memory caches, background services, and long-running operations. Consider setting the recycling interval based on your application's memory growth patterns, and configure the Shutdown Time Limit to give your app enough time to drain active connections gracefully during a recycle event using ASP.NET Core's IHostApplicationLifetime hooks.

Securing an ASP.NET Core application on IIS requires a layered approach that spans both the IIS configuration and your application's middleware pipeline. At the transport layer, IIS handles SSL/TLS termination, which means you install your certificates in Windows Certificate Store and bind them to your IIS site rather than configuring Kestrel to use certificates directly. This centralized model makes certificate management easier in enterprises where certificates are provisioned and renewed by a dedicated team or automation tooling like Windows ACME Simple (WACS) for Let's Encrypt.

HTTPS enforcement is a two-part configuration. In IIS, you can enable HTTP to HTTPS redirection using URL Rewrite rules, which ensure that any plain HTTP request is redirected to the HTTPS equivalent before it even reaches your application. Inside your ASP.NET Core application, you should also call app.UseHttpsRedirection() in the middleware pipeline as a defense-in-depth measure. When running In-Process, these two redirect mechanisms work together cleanly. When running Out-of-Process, ensure UseForwardedHeaders is called before UseHttpsRedirection so the application correctly reads the X-Forwarded-Proto header from IIS and knows the original request was HTTP.

HTTP Security Headers add another layer of protection and are best applied at the IIS level using Custom Response Headers configured in IIS Manager or via the system.webServer/httpProtocol/customHeaders section of web.config. Headers to consider include Strict-Transport-Security (HSTS) with a max-age of at least one year, X-Content-Type-Options set to nosniff, X-Frame-Options set to SAMEORIGIN or DENY, and Content-Security-Policy tuned to your application's needs. Adding these at the IIS level means they apply regardless of which ASP.NET Core middleware runs, reducing the risk of a misconfigured middleware chain leaving a gap.

IP Address and Domain Restrictions in IIS provide a coarse-grained access control mechanism useful for restricting administrative endpoints or API paths to known IP ranges. For example, an admin panel or health check endpoint can be locked down to your internal network's IP range at the IIS level without any changes to your application code. This is particularly valuable in multi-tenant environments where different site paths serve different audiences with different trust levels.

Data Protection is an ASP.NET Core framework feature that underpins cookie encryption, anti-forgery tokens, and session ticket protection. By default, Data Protection stores its key ring on the file system in a location tied to the current user profile. Under IIS, the Application Pool runs as a service account (often ApplicationPoolIdentity), which may have a non-persistent profile or a profile that changes after a recycle.

In practice this means Data Protection keys can be lost on recycle, causing users to be unexpectedly logged out or anti-forgery validation to fail. For production IIS deployments, configure Data Protection to persist keys to a shared location — either a UNC file share, SQL Server via the EF Core provider, or Azure Blob Storage — so keys survive process recycling.

Audit logging is an often-overlooked security requirement in enterprise IIS deployments. Windows Server includes Security Event Logging that can capture IIS authentication events, and IIS itself generates W3C-format access logs capturing every request with method, URL, status code, response time, and client IP.

Feed these logs into a SIEM tool or centralized logging platform (Elastic Stack, Splunk, Azure Monitor Logs) to enable real-time alerting on anomalies like sudden spikes in 401 responses, SQL injection attempt patterns in URL parameters, or unusual geographic access patterns. Combining IIS access logs with ASP.NET Core's structured application logs gives you a complete picture of both transport-level and application-level security events.

Certificate renewal automation deserves explicit planning before you go to production. Let's Encrypt certificates expire after 90 days, and even commercial certificates expire annually or bi-annually. Automate renewal using tools like Certbot with a Windows IIS plugin, WACS (Windows ACME Simple), or Azure Key Vault certificate rotation if your server has Azure connectivity.

Store renewal scripts and their scheduled tasks in source control so that a rebuild of the server from scratch does not leave you scrambling to remember the renewal setup. A failed certificate renewal that is not caught before expiry will take your application offline as browsers reject the expired certificate.

Performance tuning an ASP.NET Core application running under IIS on Windows starts with choosing the right hosting model and Application Pool configuration. As covered earlier, In-Process hosting eliminates the loopback network hop and is the right default for most scenarios.

Beyond the hosting model, the Application Pool's maximum worker processes setting (commonly called web garden mode) can be set to more than one to spin up multiple w3wp.exe processes, but this requires that your application supports multi-process environments — shared in-memory state like static dictionaries or in-memory caches will not be shared between worker processes, which can lead to cache inconsistencies.

Response compression is a straightforward win for text-heavy APIs and web applications. IIS supports dynamic and static compression natively through its built-in modules. For ASP.NET Core applications, you can choose between letting IIS handle compression at the server level or using the ResponseCompression middleware in your pipeline. IIS-level compression offloads the CPU work to the IIS layer before it even enters your managed code, which is typically more efficient. However, if you need fine-grained control over which content types and response sizes are compressed, the ASP.NET Core middleware gives you more flexibility.

Output caching and distributed caching dramatically reduce the load on your application and database for read-heavy workloads. ASP.NET Core includes an output caching middleware (introduced in .NET 7) that can cache full HTTP responses in memory or in a distributed store like Redis. For IIS deployments, combining IIS's kernel-mode output cache for truly static responses with ASP.NET Core's in-process output cache for dynamic-but-stable content gives you a multi-tier caching architecture that can handle substantial traffic spikes without proportional increases in backend resource consumption.

Thread pool and connection pool tuning becomes relevant at higher traffic volumes. The .NET thread pool's default minimum thread count is calibrated for general workloads, but I/O-bound ASP.NET Core applications under IIS can benefit from increasing the minimum thread count using ThreadPool.SetMinThreads() in your application startup to reduce the latency spikes that occur when the thread pool is cold. Similarly, ensure your SQL Server or other database connection pools are sized appropriately for the number of concurrent worker processes and threads your IIS configuration might spawn during traffic peaks.

Monitoring production performance requires connecting your IIS metrics to a centralized observability platform. Windows Performance Monitor exposes IIS-specific counters including requests per second, current connections, bytes sent/received, and application pool restarts. Export these counters to Azure Monitor, Prometheus (via the windows_exporter), or any SNMP-compatible monitoring system. Pair IIS counters with ASP.NET Core's built-in metrics (available via EventCounters and, in .NET 8, OpenTelemetry) to get a full picture of both the IIS layer and your application's internal behavior including request duration histograms, garbage collection pressure, and exception rates.

For detailed guidance on the runtime itself and how it interacts with the Windows hosting environment, the hosting asp.net core on windows runtime documentation covers runtime versioning, shared framework installation paths, and how to run multiple application versions side by side on a single IIS server. Understanding the runtime's installation structure is particularly important in environments with strict change management processes, where you need to pre-approve each new runtime version before it can be installed on production servers.

Health checks are a critical production readiness feature that integrates naturally with IIS through the ASP.NET Core Health Checks middleware. Map a /health endpoint in your application and configure IIS Application Request Routing (ARR) or an upstream load balancer to poll this endpoint and automatically remove unhealthy instances from rotation. The Health Checks API supports checking database connectivity, disk space, external service availability, and custom application conditions, giving you a single endpoint that aggregates the health of all your application's dependencies and reports a simple healthy or unhealthy status to your infrastructure layer.

Troubleshooting failed ASP.NET Core deployments on IIS follows a predictable diagnostic sequence that experienced developers learn to apply systematically. The first step is always to check the Windows Event Log under Applications and Services Logs > Microsoft > Windows > IIS-W3SVC-WP and under the Application event log. The ASP.NET Core Module writes startup failure details to the Application event log with source IIS AspNetCore Module V2, and these messages almost always contain enough information to identify the root cause without any additional investigation.

The 500.30 error code is one of the most frequent startup failures and indicates that the ASP.NET Core in-process handler failed to start the application. Common root causes include a mismatch between the application's target framework and the installed Hosting Bundle version, a missing or malformed web.config, a startup exception thrown by your application before the first middleware runs, or insufficient file system permissions on the application directory. Enable stdout logging as a first step and read the output file to see the exact exception and stack trace that caused the startup to abort.

The 500.19 error occurs when IIS cannot read or parse the web.config file. This is almost always a file permissions issue where the IIS Application Pool identity does not have read access to the web.config, or a malformed XML structure in the file itself. Verify permissions using icacls from the command line, checking that the IIS AppPool\YourPoolName identity has at least Read permission on the directory. When copying files to the server, some deployment tools strip ACLs, which can silently remove the permissions that were set correctly during the initial server setup.

Dependency loading failures are another class of deployment issue where the application fails because a native dependency (such as a native image for cryptography or compression) is missing or targets a different Windows architecture. If your application references packages with native components, ensure you are publishing for the correct runtime identifier (e.g., win-x64) and that the publish output includes the correct native binaries. Self-contained deployments bundle these binaries directly, but framework-dependent deployments rely on them being present in the runtime installed on the server.

Blue-green deployments on IIS reduce downtime and risk when releasing updates. The pattern involves maintaining two identical IIS site configurations (blue and green) pointing at different physical directories. Deployments go to the inactive slot while the active slot continues serving traffic. After verifying the new deployment in the inactive slot (using a separate test binding or host header), you swap the Application Pool's physical path to point to the new directory. IIS applies the change immediately on the next request, with no downtime for users currently being served by existing worker process threads.

Configuration management in production IIS environments benefits from Infrastructure as Code tooling. PowerShell's WebAdministration module and the newer Microsoft.Web.Administration managed API allow you to script every aspect of IIS configuration, from creating Application Pools to setting binding certificates. Storing these scripts in source control means you can rebuild a server from scratch to a known-good state in minutes rather than hours. Pair PowerShell scripts with Desired State Configuration (DSC) resources for IIS to enforce configuration drift detection, alerting you when a manual change to IIS settings deviates from the defined baseline.

Graceful shutdown is important for maintaining user experience during planned maintenance and deployments. ASP.NET Core integrates with IIS through the ANCM to support graceful shutdown: when IIS signals the worker process to stop, the ANCM notifies the ASP.NET Core host, which fires the IHostApplicationLifetime.ApplicationStopping cancellation token. Your application can hook into this token to stop accepting new background work and allow in-flight requests to complete before the process exits. Configure the Application Pool's Shutdown Time Limit (default 90 seconds) to be longer than your longest expected request processing time to ensure no requests are abruptly cut off during recycling events.