When it comes to standing up a web server on Windows, Internet Information Services (IIS) has been the default answer for decades. Yet, despite its deep integration into Windows Server, the role ships dormant. Administrators must deliberately activate it—and the method they choose can determine how quickly they can scale, automate, or lock down the environment. Far from being a one-click affair, installing IIS is a strategic decision that ties into an organization's broader server management practices.

Three primary paths exist: the familiar Server Manager GUI, the scriptable simplicity of PowerShell, and the low-level power of DISM. Each approach targets a different operational scenario—ad hoc setups, repeatable automation, or bare-metal image servicing—but the underlying feature set remains identical. The real art lies in selecting only the role services your applications demand, then hardening what’s left. With more Windows Server workloads moving to hybrid and containerized models, a disciplined IIS deployment playbook has never been more relevant.

Server Manager: The GUI path for visual feedback

For one-off installations or environments where administrators prefer a visual audit of feature dependencies, the Add Roles and Features wizard is the tool of choice. It starts with a click: Server Manager > Manage > Add Roles and Features. After selecting the local server, check “Web Server (IIS)” and let the wizard walk you through optional role services.

During the wizard, expand the Web Server node and its sub-branches to cherry-pick components. At minimum, select Static Content, Default Document, and HTTP Errors under Common HTTP Features. If you’ll host .NET apps, add ASP.NET and .NET Extensibility. For intranet sites that rely on domain authentication, Windows Authentication is a must. Don’t skip the management tools—IIS Management Console and IIS Management Scripts and Tools give you both the graphical inetmgr interface and command-line instrumentation.

A critical best practice here is restraint. Every additional role service — ISAPI Extensions, CGI, WebDAV, or legacy IIS 6 compatibility shims — expands the server’s attack surface and patching footprint. The wizard will auto-select dependencies, but it’s still your job to uncheck what you don’t need. Once committed, the installation completes in minutes, and a quick browser request to http://localhost confirms the default welcome page is live.

PowerShell: The automation workhorse

For administrators chaining IIS deployment into configuration management workflows—think Ansible, Puppet, or just a plain .ps1 in a GitHub repo—PowerShell’s Install-WindowsFeature cmdlet is indispensable. It’s idempotent, returns an object that scripts can inspect, and works on Server Core where Server Manager doesn’t exist.

A minimal, common command covers the web server engine and management tools:

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Add ASP.NET and WebSocket support with a single line:

Install-WindowsFeature -Name Web-Server, Web-ASP, Web-Mgmt-Tools, Web-WebSockets

Run these from an elevated session. The cmdlet’s output includes Success, ExitCode, and RestartNeeded flags, making it easy to wrap in error-checking logic. For fine-grained control, list available features with Get-WindowsFeature and pipe only what you need into Install-WindowsFeature. This approach is essential for Infrastructure-as-Code (IaC) pipelines: define the exact feature set in a DSC configuration or Ansible playbook, and ensure every server built from that definition starts identically.

DISM: The offline and container-friendly option

For image-based servicing, Windows Server Core, and container hosts, DISM (Deployment Image Servicing and Management) is the heavy lifter. It operates directly against the system’s component store, either online or against an offline image. The basic invocation to enable the full Web Server role looks like:

dism /online /enable-feature /featurename:IIS-WebServerRole /all

The /all flag pulls in every dependency, avoiding the whack-a-mole of missing parents. Need ASP.NET 4.5 and WebSockets? Add them explicitly:

dism /online /enable-feature /featurename:IIS-ASPNET45 /all
dism /online /enable-feature /featurename:IIS-WebSockets /all

DISM’s strength lies in its precision and scriptability. It works when the GUI can’t and doesn’t require PowerShell’s overhead. However, feature names are exact and case‑sensitive—we’ve seen administrators mistype IIS-ASPNET and wonder why the installation fails. Use dism /online /get-features to list what’s available and verify the correct name. For air‑gapped systems or when the component store is missing payloads, direct DISM to a source with /source:D:\sources\sxs and add /limitaccess to prevent fallback to Windows Update.

Verifying the installation: beyond the welcome page

Regardless of method, validation follows the same checklist. First, the default site: browse to http://localhost and confirm the IIS welcome page renders. Second, services: Get-Service W3SVC, WAS should show both World Wide Web Publishing Service and Windows Process Activation Service running. Third, management tools: launch inetmgr and verify that sites, application pools, and modules appear.

For PowerShell installs, Get-WindowsFeature -Name Web-Server provides a clean status check. DISM users run dism /online /Get-Features and look for “Enabled” next to IIS features. Skipping these checks has caused countless production surprises—especially when the service appears running but content permissions are wrong.

Optional components: just enough, nothing more

IIS’s modular architecture is both a blessing and a risk. The following components appear often in real‑world deployments, but only enable them if your application depends on them:

  • ASP.NET / .NET Extensibility – mandatory for classic ASP.NET and .NET Framework apps; not needed for pure static sites or apps running under ASP.NET Core (which uses the ASP.NET Core Module).
  • WebSockets – required for chat apps, live dashboards, and SignalR. Without it, the WebSocket handshake fails silently.
  • URL Rewrite – the swiss‑army knife for friendly URLs, redirects, and reverse proxy rewrite rules. It’s a standalone download, not a built‑in role service.
  • Application Request Routing (ARR) – install URL Rewrite first, then ARR; it turns IIS into a reverse proxy and load balancer with disk caching, health monitoring, and cookie‑based affinity. Use it when you need HTTP‑level routing without a separate appliance.

Post‑install configuration: sites, bindings, and TLS

Once the role is active, the real work begins. The default website’s physical path sits at C:\inetpub\wwwroot—fine for testing, but production sites should live on a dedicated drive. Create a new site or modify the default, then configure bindings: at minimum, an HTTP binding on port 80 and, critically, an HTTPS binding on port 443.

SSL/TLS configuration is non‑negotiable. Bind a certificate—ideally from an internal PKI or a public CA—and disable protocols older than TLS 1.2 via the OS’s SCHANNEL registry keys. On Windows Server 2025, TLS 1.3 is available and should be prioritized where client compatibility allows. Application pools need attention, too: choose the correct .NET CLR version (No Managed Code for static/HTML; v4.0 for .NET Framework apps) and run each pool under a unique, least‑privileged identity—a managed service account or a custom account with minimal rights.

Automation and Infrastructure‑as‑Code

Repeatability is the hallmark of mature operations. Bake IIS into golden images with DISM, then layer site configuration with PowerShell DSC or Ansible. A typical DSC configuration might include the WindowsFeature resource to ensure Web-Server is present, followed by xWebSite and xWebAppPool resources to define sites. Version‑control these configurations alongside application code.

For packer‑based image pipelines, run DISM commands during the image build so every spawned VM starts web‑ready. Include idempotency checks: before applying a DSC configuration, run Get-WindowsFeature to detect drift. This approach eliminates the “it worked on my machine” syndrome and makes blue‑green deployments trivial.

Hardening: security by subtraction

A default IIS install is not production‑ready from a security standpoint. Adopt a defense‑in‑depth mindset:

  • Disable unused modules – open IIS Manager, go to the server’s Modules page, and remove anything not in use. Each module is a potential attack vector.
  • Request filtering – enforce limits on URL length, query strings, and HTTP verbs. Reject suspicious patterns.
  • Isolate application pools – separate high‑risk apps into their own pools with unique identities. Use application pool identity accounts where possible.
  • Patch religiously – subscribe to the Microsoft Security Update Guide and apply cumulative updates on a tested schedule. The March 2025 update, for instance, closed a critical vulnerability in IIS’s handling of HTTP/2 requests.

Community discussions often highlight that hardening is not a set‑and‑forget task. Enable failed request tracing to catch anomalies, and review the output of the IIS Crypto tool to confirm that only strong cipher suites are enabled.

Real‑world troubleshooting: lessons from the field

When installations fail, seasoned administrators follow a triage path that starts with logs. DISM failures leave breadcrumbs in C:\Windows\Logs\DISM\dism.log. Service startup failures appear in the System event log. A 0x800f0922 error during feature installation suggests a missing payload; point DISM to the installation media with /source.

A common pitfall is .NET dependencies: trying to enable ASP.NET role services without the .NET Framework installed leads to opaque errors. Install .NET Framework first if you’re on a clean Server Core image. Another recurring issue is permission mismatches. After adding the Web Server role, the W3SVC and WAS services must start. If they don’t, check group memberships—the service accounts often need membership in IIS_IUSRS. And if management scripts fail, ensure the executing user is a local administrator and the script execution policy allows it.

For WSUS‑related installs, if the post‑install ConfigureWebsite step bombs, recreate the WSUS Administration virtual directories manually (the community has documented this extensively) and grant NETWORK SERVICE modify rights on the content folder.

Using IIS as a reverse proxy with ARR

ARR plus URL Rewrite is a compelling alternative to hardware load balancers for HTTP‑only workloads. Install URL Rewrite first (it’s a prerequisite), then ARR. From the IIS Manager, create a server farm and define rewrite rules to forward traffic. ARR supports round‑robin, least‑response‑time, and weighted distribution, plus cookie‑based affinity for stateful applications. Health probes ensure backend servers are alive. This is a low‑cost way to run A/B tests or stage canary deployments, all managed from the same IIS console.

Backups: the safety net

The IIS configuration is essentially an XML file—applicationHost.config—and it is easily backed up with appcmd:

appcmd add backup "PrePatchBackup"

That command creates a timestamped copy under C:\Windows\System32\inetsrv\backup. Merge this into your nightly backup routine and store copies off‑server. When migrating servers, export site configuration to XML with Export-IISConfiguration or appcmd list site /config /xml > site.xml. And always archive SSL certificate secrets (with strong passphrases) so a rebuild doesn’t leave you scrambling for re‑issues.

Production go‑live checklist

Before letting real traffic hit the server, run through this list:

  • ✅ Role services match the application’s documented requirements.
  • ✅ Local and remote connectivity tests pass for all bindings.
  • ✅ HTTPS uses a valid certificate; TLS 1.2/1.3 only.
  • ✅ Application pools run as least‑privileged identities.
  • ✅ Failed request tracing and basic monitoring are enabled.
  • ✅ Configuration backup is current and stored securely.
  • ✅ Patch level is current and tested in staging.

The evolution of IIS in a hybrid world

IIS remains a cornerstone of Windows‑based web hosting, but its role is evolving. Containers running on Windows Server now often include ASP.NET Core atop Kestrel, bypassing IIS entirely. Yet IIS still dominates traditional enterprise workloads, internal portals, and WSUS servers. The techniques described here—especially the emphasis on automation and hardening—are transferable: DSC, Ansible, and DISM all work whether you’re deploying to bare metal or a Hyper‑V VM.

Looking ahead, the convergence of Windows Server and Azure Arc means that on‑prem IIS servers can be managed from the cloud with centralized policy. That will demand even greater discipline in how role services are selected and configured. For administrators who master the three installation paths and the security checklist, IIS will remain a reliable, secure, and scriptable asset for years to come.