IIS Installation & Configuration

What IIS Is and What Gets Installed

Internet Information Services (IIS) is the web server role built into Windows Server. Installing it doesn't just drop in an executable — it adds a Windows feature called Web-Server that brings along the HTTP.sys kernel-mode driver, the World Wide Web Publishing Service (W3SVC), a default website, and optionally the IIS Manager MMC console. Windows Server 2016 through 2022 all ship IIS 10.0, so the installation steps and management tools are identical across those versions.

Unlike a standalone web server product, IIS is modular: you choose which role services to enable at install time (or add later), and each one maps to a specific feature — serving static files, compressing responses, running ASP.NET, logging, authentication, and so on. This modularity keeps the attack surface small on servers that only need to serve plain HTML or a reverse-proxied API, while still supporting full ASP.NET applications when you turn on the right pieces.

Installing IIS via Server Manager

The graphical path uses the Add Roles and Features Wizard:

1. Open Server Manager, click Manage > Add Roles and Features.
2. Click through Before You Begin, choose Role-based or feature-based installation, and select the target server from the pool.
3. On the Server Roles page, check Web Server (IIS). A dialog will prompt you to add the required management tools — accept it so IIS Manager gets installed alongside the role.
4. Click Next through Features (nothing extra is required for a basic install) until you reach Role Services.
5. This is where you pick which IIS sub-features to enable (covered in detail below). The wizard pre-selects a sensible default set for static content.
6. Confirm your selections and click Install. No reboot is required for a standard IIS install.

When it finishes, the default website is already running — the wizard both installs the binaries and starts the W3SVC service.

Installing IIS with PowerShell

For repeatable deployments, scripted installs, or Server Core (which has no Server Manager GUI), PowerShell is the standard route. The minimal command that mirrors what the wizard does is:

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Web-Server is the feature name for the core IIS role; -IncludeManagementTools pulls in IIS Manager (Web-Mgmt-Console) and the management service, which are not installed by default when you use PowerShell. Skipping that flag gives you a working web server with no GUI to manage it — you'd be limited to appcmd.exe or the WebAdministration/IISAdministration PowerShell modules.

To install specific role services instead of relying on defaults, list them explicitly:

Install-WindowsFeature -Name Web-Server, Web-Asp-Net45, Web-Net-Ext45, `
  Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Mgmt-Console -IncludeManagementTools

Before or after installing, Get-WindowsFeature Web-* lists every IIS-related feature and shows which ones are already installed — useful for auditing a server or confirming a script did what you expected. On Server Core, this PowerShell approach is the only option since there's no Add Roles and Features GUI.

Choosing the Right Role Services

IIS groups its optional features into a handful of categories. Three matter for almost every deployment:

Common HTTP Features — covers the basics of serving content: Default Document (serves index.html/default.aspx when a URL has no filename), Directory Browsing (lists files when no default document exists — leave this off in production), HTTP Errors (custom error pages), Static Content (serving files like HTML, CSS, images), and HTTP Redirection. Any site serving files needs Static Content and HTTP Errors at minimum.

Application Development — required if the server will run anything beyond static files. This is where ASP.NET support lives: ASP.NET 4.8 (or the newer ASP.NET Core Module if you're hosting .NET applications), .NET Extensibility, ISAPI Extensions, and ISAPI Filters. Also included here is WebSocket Protocol support, needed for SignalR or other real-time connections. If you're only serving static content or proxying to another backend, you can skip this entire category.

Management Tools — IIS Management Console (the inetmgr.exe GUI), IIS Management Scripts and Tools (the PowerShell/WebAdministration cmdlets), IIS Management Service (allows remote management from another machine's IIS Manager), and IIS 6 Management Compatibility (only needed for legacy metabase-based scripts). Nearly every server benefits from at least the Management Console; the Management Service is worth enabling if you plan to administer IIS remotely rather than via RDP.

Enable only what you need. Every role service is additional code loaded into the request pipeline, and features like WebDAV Publishing or Basic Authentication carry real security implications if turned on without a specific reason.

Sites, Bindings, and Application Pools

A single IIS installation can host many independent websites, and understanding how is central to configuring IIS correctly. Each site is defined by one or more bindings, and a binding is the combination of three values: an IP address (or "All Unassigned"), a port, and — for HTTP/HTTPS — an optional host header. The default site's out-of-the-box binding is *:80: — any IP address, port 80, no host header — which is why a fresh install responds on http://localhost without any configuration.

To host multiple sites on the same IP and port 80, you add a host header to each site's binding matching its domain name (e.g., site-a.contoso.com and site-b.contoso.com). IIS reads the Host header on the incoming HTTP request and routes it to the matching site — this is the same mechanism virtual hosting uses on any web server. Alternatively, sites can be separated by port (8080, 8081, ...) or by binding each to a distinct IP address if you have multiple NICs or IP aliases; that approach is required for older TLS setups where SNI isn't available, though modern IIS supports SNI-based host headers over HTTPS too.

Every site runs its content inside an application pool, and this is a separate concept from the site itself. The app pool defines the worker process (w3wp.exe) that actually executes requests — its identity, its recycling schedule, and critically its pipeline mode. A fresh install creates DefaultAppPool and assigns the default site to it. Isolating sites into their own app pools means one site's crashed or hung worker process doesn't take down others on the same server, which is standard practice once you're hosting more than a single application.

Pipeline mode has two options. Integrated mode, the default and recommended setting for ASP.NET applications, runs the ASP.NET request pipeline as an integral part of IIS's own pipeline — modules like authentication and URL rewriting apply uniformly to both ASP.NET and static content requests. Classic mode recreates the IIS 6 behavior, where IIS handles the request first and only hands off to ASP.NET (aspnet_isapi.dll) for .aspx-mapped extensions, keeping the two pipelines separate. Classic mode exists purely for backward compatibility with legacy applications that depend on the old two-stage request lifecycle; new applications should stay on Integrated mode unless a specific legacy dependency requires otherwise.

Verifying the Installation

Once the role finishes installing, confirm it two ways. First, open a browser on the server (or use Invoke-WebRequest http://localhost from PowerShell if there's no GUI) and navigate to http://localhost. A successful install shows the default IIS splash page — a blue-and-gray "IIS Windows Server" welcome screen served from C:\inetpub\wwwroot\iisstart.htm. Seeing this confirms that the W3SVC service is running, HTTP.sys is bound to port 80, and the default site is serving content correctly.

Second, open IIS Manager — run inetmgr from the Start menu or a command prompt. In the Connections pane on the left, expand the server node to see Application Pools and Sites. You should see DefaultAppPool in a Started state and the Default Web Site listed under Sites, also Started, with its *:80: binding visible when you click Bindings in the Actions pane. If either shows as Stopped, right-click and choose Start, then check Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > IIS-* for the underlying error — a stopped default site after a clean install is almost always a port 80 conflict with another process.

From here, replacing the default content, adding your own site with its own bindings and app pool, and layering in the role services your application actually requires are the next steps in turning this base install into a working web server.