Install and Configure IIS

August 12, 2026 Khimananda Oli 7 min read DevOps

By Khimananda Oli | Last reviewed: August 2026

When you need to host .NET applications or legacy Windows services on-premises or in hybrid clouds, you must correctly install and configure IIS to ensure stability and security. Many administrators rely on the GUI, but manual clicks lead to drift and missed hardening steps that fail audits. This guide provides a repeatable, scriptable approach to deploying Internet Information Services on Windows Server 2026 that aligns with modern DevOps standards and compliance requirements.

Quick answer: To install and configure IIS on Windows Server 2026, use the Install-WindowsFeature Web-Server PowerShell cmdlet with management tools. Follow this by disabling unused modules, isolating application pools, enforcing TLS 1.3, and configuring structured logging to create a secure, production-ready web server environment.

How do you install and configure IIS using PowerShell?

While the Server Manager GUI is familiar, it is unsuitable for reproducible infrastructure. In my experience managing hybrid environments across Nepal and global regions, PowerShell is the only viable path for consistent deployments. Scripting ensures every server matches your baseline, which is critical when preparing for ISO 27001 or SOC 2 audits where configuration drift is a common finding.

Three-phase workflow to install and configure IIS securely on Windows Server 2026

The following command installs the core web server role along with essential management tools and ASP.NET Core support. Adjust the feature list based on your specific workload; avoid installing "kitchen sink" features that increase the attack surface.

# Install IIS with Management Tools and ASP.NET Core support
Install-WindowsFeature -Name Web-Server,Web-Mgmt-Tools,Web-Asp-Net45,Web-Net-Ext45 `
    -IncludeManagementTools -Restart

# Verify installation state
Get-WindowsFeature -Name Web-* | Where-Object {$_.Installed -eq $true}

If you are integrating this into an automated pipeline similar to PowerShell automation for Windows Servers, wrap these commands in a DSC (Desired State Configuration) resource or Ansible playbook. This guarantees that future provisioning runs remain idempotent and compliant with your defined baseline.

How do you secure IIS application pools and site bindings?

Security in IIS is primarily about isolation and least privilege. A common mistake I see during assessments is running multiple sites under the default DefaultAppPool. If one site is compromised, the attacker gains access to all other sites sharing that pool. Always create dedicated application pools for each application with unique identities.

Isolate workloads with dedicated application pools

Create a new application pool with optimized settings for modern .NET workloads. Set the identity to ApplicationPoolIdentity unless the app requires specific domain resources. This virtual account has minimal permissions and reduces lateral movement risk.

# Create isolated App Pool with security best practices
New-WebAppPool -Name "MyApp-Pool"
Set-ItemProperty "IIS:\AppPools\MyApp-Pool" -Name managedRuntimeVersion -Value ""
Set-ItemProperty "IIS:\AppPools\MyApp-Pool" -Name processModel.identityType -Value 4
Set-ItemProperty "IIS:\AppPools\MyApp-Pool" -Name startMode -Value "AlwaysRunning"
Set-ItemProperty "IIS:\AppPools\MyApp-Pool" -Name recycling.periodicRestart.time -Value "00:00:00"

Enforce strict binding and TLS policies

Never leave HTTP port 80 open without redirection. Bind your site to HTTPS only and enforce TLS 1.3 where client compatibility allows. For internal services in Nepal-based data centers with older clients, TLS 1.2 remains acceptable, but disable all legacy protocols (SSL 3.0, TLS 1.0/1.1) via registry keys or tools like IIS Crypto.

Remove Default Site: Delete the "Default Web Site" immediately after installation to eliminate a known attack vector.
Bind Specific IPs: Avoid binding to "All Unassigned" (*). Specify the exact IP address to prevent accidental exposure on management interfaces.
HSTS Headers: Add Strict-Transport-Security headers directly in the web.config or via URL Rewrite module to prevent protocol downgrade attacks.

How does IIS compare to Nginx for Windows hosting?

Choosing between IIS and Nginx depends heavily on your technology stack and operational context. While Nginx dominates Linux environments, IIS remains the native choice for .NET Framework apps and integrated Windows authentication. Understanding these trade-offs prevents costly architectural pivots later.

Criteria	IIS (Windows Server)	Nginx (Cross-Platform)
Primary Use Case	.NET Framework, ASP.NET Core, Windows Auth	Static content, Reverse Proxy, Node.js/PHP
Configuration Model	XML (web.config), PowerShell, GUI	Text config files, CLI reload
Performance	Optimized for .NET via Kestrel integration	Superior static file serving & concurrency
Ecosystem Integration	Native AD/Kerberos, ETW, Event Log	Cloud-native, Container-friendly, Linux-first
Licensing Cost	Included with Windows Server license	Open Source / Commercial Plus available

For teams running mixed environments, consider using Nginx as a reverse proxy in front of IIS. This pattern lets you leverage Nginx's superior SSL termination and caching while retaining IIS for backend .NET processing. This hybrid approach mirrors strategies discussed in Nginx vs Apache performance comparisons, adapted for the Windows ecosystem.

How do you configure logging and monitoring for IIS?

You cannot manage what you cannot observe. Default IIS logging captures basic request data but lacks the structure needed for modern observability platforms. To align with practices outlined in structured logging best practices, enable Enhanced Logging or use the Advanced Logging module to emit JSON-formatted logs.

End-to-end observability pipeline for IIS logs flowing to centralized monitoring systems

Configure log rotation aggressively. IIS logs can consume gigabytes daily on busy servers. Use the built-in log truncation settings or external rotation tools to maintain disk hygiene. For compliance-heavy environments, ship logs to immutable storage immediately rather than relying solely on local retention.

# Enable detailed logging fields for better forensics
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' `
    -filter "system.applicationHost/sites/site[@name='MySite']/logFile" `
    -name "logFormat" -value "W3C"
    
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' `
    -filter "system.applicationHost/sites/site[@name='MySite']/logFile" `
    -name "logExtFileFlags" -value "Date,Time,ClientIP,UserName,ServerIP,Method,UriStem,UriQuery,HttpStatus,Win32Status,BytesSent,BytesRecv,TimeTaken,ServerPort,UserAgent,Referer,HttpSubStatus"

What are the essential hardening steps post-installation?

Installing IIS is just the beginning. Post-install hardening separates test servers from production-grade infrastructure. These steps reduce your attack surface and prepare the system for external validation.

Remove Unused Modules: Every loaded module is potential code execution surface. Disable CGI, ISAPI filters, and WebDAV if not explicitly required.
Restrict File System Permissions: Ensure application directories grant Read/Execute only to the AppPool identity. Write permissions should be limited to specific upload/temp folders.
Enable Request Filtering: Block dangerous extensions (.exe, .bat, .config) and limit maximum request sizes to prevent buffer overflow attempts.
Hide Version Headers: Remove the Server and X-Powered-By headers to deny attackers easy fingerprinting. Use URL Rewrite rules or registry edits to suppress them.
Patch Cadence: Subscribe to Microsoft Update Catalog alerts for IIS-specific CVEs. Automate patch testing in staging before production rollout.

For teams managing database backends alongside IIS, ensure connection strings use encrypted channels and managed identities where possible. Refer to MySQL performance tuning guide for optimizing backend connectivity patterns that complement your web tier security.

Visual comparison of IIS attack surface before and after applying security hardening controls

Production readiness checklist for IIS deployments

Successfully deploying IIS requires moving beyond basic installation to operational excellence. Your goal is a system that survives traffic spikes, passes security scans, and integrates cleanly with your broader monitoring stack. Before marking any IIS deployment as complete, verify that automated backups include both configuration exports (Backup-WebConfiguration) and content directories. Test restore procedures quarterly; untested backups are merely hopes.

Implement health check endpoints for load balancers and orchestrators. A simple /health endpoint returning 200 OK allows upstream systems to detect failures faster than TCP checks alone. Combine this with the monitoring strategies covered in the four golden signals of monitoring to distinguish between saturation, errors, and latency issues at the web tier.

If you are planning a migration or new deployment on Windows Server 2026, treat the initial install and configure IIS phase as foundational infrastructure code, not a one-time setup task. Document every deviation from defaults in your change management system. Reach out via contact me if you need assistance architecting compliant IIS environments or conducting pre-audit readiness assessments for your Windows infrastructure.

Frequently Asked Questions

IIS requires Windows Server 2025 Standard or Datacenter edition with at least 2GB RAM and 32GB disk space. The Web Server role installs via Server Manager or PowerShell. Ensure .NET Framework 4.8 or later is present for ASP.NET applications before beginning configuration.

Run Install-WindowsFeature Web-Server,Web-Asp-Net45,Web-Mgmt-Console -IncludeManagementTools in an elevated PowerShell session. This installs the web server, ASP.NET 4.5 support, and management console. Restart if prompted, then verify installation with Get-WindowsFeature Web-Server to confirm all components are active.

Yes, IIS is included with Windows Server licenses at no additional cost.

IIS supports PHP via FastCGI but generally trails Nginx in raw throughput for static content. Nginx uses less memory per connection and handles concurrent requests more efficiently. Choose IIS only if your stack requires Windows authentication, ASP.NET integration, or existing Active Directory dependencies that justify the performance trade-off.

C:\inetpub\wwwroot is the default physical path.

Open IIS Manager, select your site, click Bindings under Edit Site, then Add. Choose https type, select your certificate from the store, and specify port 443. For Let's Encrypt, use win-acme or Certify The Web to automate renewal. Always enable HSTS headers after binding to enforce secure connections.

This error indicates invalid configuration data in web.config. Check the Config Error field for the exact line number. Common causes include missing IIS modules like URL Rewrite or ASP.NET, malformed XML syntax, or locked configuration sections. Unlock sections via appcmd or reinstall the required feature through Server Manager.

In IIS Manager, open Error Pages, edit 500 status code, and select Detailed Errors. Alternatively, set customErrors mode="Off" in web.config for ASP.NET apps. Never leave detailed errors enabled in production as they expose sensitive stack traces. Use Failed Request Tracing instead for safe diagnostic logging.

Grant ApplicationPoolIdentity read access to the site folder and write access only to specific upload or log directories. Never assign full control or administrator rights. Use icacls to set precise NTFS permissions. Database connections should use dedicated service accounts, not the app pool identity, to maintain least privilege security boundaries.

Create separate sites in IIS Manager with unique host headers or IP addresses. Each site needs its own application pool for isolation. Configure bindings with distinct domain names pointing to different physical paths. Use SNI for multiple SSL certificates on port 443 without requiring dedicated IPs for each site.

Yes, install PHP via Web Platform Installer or manually configure FastCGI. Set up URL Rewrite rules to route requests through public/index.php. Configure OPcache and enable necessary PHP extensions like mbstring and openssl. Performance typically lags behind Linux deployments, so consider WSL2 or Docker for production Laravel workloads when possible.

Disable directory browsing, remove unnecessary modules, and hide version headers via web.config. Enable request filtering to block dangerous file extensions and URL sequences. Apply Windows Updates monthly and restrict management console access to administrators. Run sites under isolated application pools with minimal filesystem permissions and audit logs regularly for suspicious activity.

IIS supports W3C extended logging with customizable fields including client IP, URI, status code, and response time. Enable Failed Request Tracing for deep diagnostics on slow or failing requests. Forward logs to centralized platforms like Elastic Stack or Datadog for analysis. Rotate logs daily and retain them according to compliance requirements.

Convert .htaccess rewrite rules to IIS URL Rewrite format using the import tool. Map Apache modules to equivalent IIS features. Update file permissions for ApplicationPoolIdentity. Test thoroughly in staging before switching DNS. Expect configuration differences in authentication, caching directives, and environment variable handling that require manual adjustment during migration.

Use IIS as a reverse proxy for Kestrel in production for SSL termination, static file serving, and process management. Kestrel alone lacks these features and shouldn't face the internet directly. IIS provides automatic restarts, request queuing during restarts, and integrated Windows authentication that Kestrel cannot handle natively without significant custom middleware development.