Internet Information Services (IIS) ist Microsofts hauseigener Webserver - und für Windows-Umgebungen oft die naheliegendste Wahl. Wenn du ASP.NET-Anwendungen hostest, in einer Active Directory-Umgebung arbeitest oder Enterprise-Features wie integrierte Windows-Authentifizierung benötigst, führt kaum ein Weg an IIS vorbei.

Die Geschichte von IIS reicht zurück bis 1995, als Microsoft den Webserver erstmals mit Windows NT 3.51 auslieferte. Seitdem hat sich IIS von einem einfachen HTTP-Server zu einer vollständigen Anwendungsplattform entwickelt. Mit jeder Windows Server-Version kamen neue Features hinzu: Application Pools für Prozessisolierung, das modulare Design ab IIS 7, und zuletzt HTTP/3-Support mit Windows Server 2022.

Der Marktanteil von IIS liegt 2026 bei etwa 8% - deutlich hinter Nginx und Apache, aber stabil. Das mag auf den ersten Blick wenig erscheinen, aber IIS dominiert seinen Zielmarkt: Enterprise-Umgebungen mit Windows-Infrastruktur, .NET-Entwicklung und Organisationen, die auf Microsoft-Support setzen. Große Unternehmen, Behörden und Konzerne mit bestehender Microsoft-Lizenzierung wählen IIS nicht trotz, sondern wegen der tiefen Windows-Integration.

Technische Architektur: Wie IIS unter der Haube funktioniert

Die Architektur von IIS unterscheidet sich fundamental von Unix-basierten Webservern wie Nginx oder Apache. Das Verständnis dieser Architektur hilft dir, IIS optimal zu konfigurieren und Performance-Probleme zu diagnostizieren.

Kernel-Mode und User-Mode: Das Zwei-Schichten-Modell

IIS besteht aus zwei Hauptkomponenten, die in unterschiedlichen Betriebsmodi laufen:

HTTP.sys (Kernel-Mode): Der HTTP-Protokoll-Stack läuft direkt im Windows-Kernel. HTTP.sys empfängt eingehende HTTP-Anfragen, führt URL-Parsing durch, handhabt SSL/TLS-Termination und cached statische Inhalte. Durch die Kernel-Mode-Ausführung ist HTTP.sys extrem schnell bei statischen Dateien - die Daten müssen nicht zwischen Kernel- und User-Space kopiert werden.

IIS Worker Process w3wp.exe (User-Mode): Die eigentliche Anwendungslogik läuft in Worker-Prozessen. Jeder Application Pool hat einen oder mehrere Worker-Prozesse, die ASP.NET-Code ausführen, ISAPI-Extensions laden und dynamische Inhalte generieren.

Diese Trennung bietet Vorteile: HTTP.sys kann selbst dann Anfragen entgegennehmen, wenn der Worker-Prozess abstürzt oder recycelt wird. Außerdem ist der Kernel-Mode-Cache unglaublich effizient für statische Inhalte.

Application Pools: Isolierung als Grundprinzip

Application Pools sind das zentrale Konzept für Prozessisolierung in IIS. Jeder Pool läuft in einem eigenen w3wp.exe-Prozess mit eigener Speicherverwaltung und eigenem Identitätskontext.

Die Vorteile dieser Isolation:

Fehlertoleranz: Ein Absturz in einer Anwendung beeinträchtigt keine anderen Pools
Sicherheit: Jeder Pool kann mit unterschiedlichen Berechtigungen laufen
Ressourcenkontrolle: CPU- und Speicherlimits pro Pool einstellbar
Unabhängige Recycling-Zyklen: Pools können individuell neugestartet werden

# Neuen Application Pool erstellen
New-WebAppPool -Name "MeineAnwendung"

# Pool-Identität konfigurieren
Set-ItemProperty IIS:\AppPools\MeineAnwendung -Name processModel.identityType -Value ApplicationPoolIdentity

Protokoll-Support

IIS unterstützt alle modernen HTTP-Protokolle:

HTTP/1.1: Vollständiger Support seit IIS 6
HTTP/2: Nativ ab IIS 10 (Windows Server 2016)
HTTP/3: Ab Windows Server 2022 mit QUIC-Unterstützung
WebSocket: Vollständig integriert für Echtzeit-Anwendungen
gRPC: Unterstützt über ASP.NET Core

Der HTTP/3-Support in Windows Server 2022 ist besonders interessant: Microsoft hat QUIC direkt in HTTP.sys integriert, was bedeutet, dass HTTP/3 auch ältere ASP.NET Framework-Anwendungen beschleunigen kann - ohne Code-Änderungen.

Installation und Konfiguration: IIS einrichten

Die Installation von IIS unterscheidet sich je nach Windows-Version. Hier die wichtigsten Installationswege.

Windows Server: Installation über Server Manager

Auf Windows Server installierst du IIS als Server-Rolle:

Öffne den Server Manager
Klicke auf Manage → Add Roles and Features
Wähle Role-based or feature-based installation
Selektiere deinen Server
Aktiviere Web Server (IIS) unter Server Roles
Wähle die benötigten Role Services (ASP.NET, Windows Authentication, etc.)
Schließe den Wizard ab

Alternativ per PowerShell - deutlich schneller und skriptbar:

# IIS mit Management-Tools installieren
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

# Zusätzliche Features für ASP.NET Core
Install-WindowsFeature -Name Web-Asp-Net45, Web-Net-Ext45

# Alle verfügbaren IIS-Features auflisten
Get-WindowsFeature -Name Web-*

Windows 10/11: IIS als optionales Feature

Auf Windows Desktop-Versionen aktivierst du IIS über die Windows-Features:

Öffne Systemsteuerung → Programme → Windows-Features aktivieren oder deaktivieren
Aktiviere Internetinformationsdienste
Erweitere den Eintrag und wähle die benötigten Unterfeatures
Klicke OK und warte auf die Installation

Per PowerShell (als Administrator):

# IIS auf Windows 10/11 aktivieren
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServer
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ManagementConsole

Der IIS Manager: Die zentrale Verwaltungsoberfläche

Nach der Installation ist der IIS Manager dein primäres Werkzeug. Starte ihn über inetmgr.exe oder das Startmenü.

Die Oberfläche ist hierarchisch aufgebaut:

Server-Ebene: Globale Einstellungen für alle Sites
Application Pool-Ebene: Pool-spezifische Konfiguration
Site-Ebene: Website-Konfiguration
Application/Virtual Directory: Unterverzeichnis-Einstellungen

Wichtige Bereiche im IIS Manager:

Bereich	Funktion
Sites	Websites erstellen, starten, stoppen
Application Pools	Worker-Prozesse verwalten
Authentication	Authentifizierungsmethoden konfigurieren
SSL Settings	HTTPS und Client-Zertifikate
Handler Mappings	Dateitypen zu Handlern zuordnen

Web.config: Die XML-basierte Konfiguration

Jede IIS-Website kann eine web.config-Datei im Root-Verzeichnis haben. Diese Datei überschreibt Server-Einstellungen auf Site-Ebene:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <!-- URL Rewrite -->
        <rewrite>
            <rules>
                <rule name="HTTPS Redirect" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                            redirectType="Permanent" />
                </rule>
            </rules>
        </rewrite>

        <!-- Statische Kompression -->
        <httpCompression>
            <staticTypes>
                <add mimeType="text/*" enabled="true" />
                <add mimeType="application/javascript" enabled="true" />
            </staticTypes>
        </httpCompression>

        <!-- Custom Error Pages -->
        <httpErrors errorMode="Custom">
            <remove statusCode="404" />
            <error statusCode="404" path="/errors/404.html" responseMode="File" />
        </httpErrors>
    </system.webServer>
</configuration>

Die web.config ist mächtig: Du kannst URL-Rewrites definieren, Caching steuern, Handler konfigurieren und Sicherheitseinstellungen setzen - alles ohne den IIS Manager zu öffnen.

ASP.NET und .NET Core Hosting: Die Stärke von IIS

IIS wurde für .NET-Anwendungen optimiert. Die Integration ist so tief, dass viele .NET-Features nur auf IIS vollständig verfügbar sind.

ASP.NET Framework: Das klassische .NET

Für traditionelle ASP.NET Framework-Anwendungen (Web Forms, MVC 5 und älter) ist IIS die native Plattform:

<!-- web.config für ASP.NET Framework -->
<configuration>
    <system.web>
        <compilation debug="false" targetFramework="4.8" />
        <httpRuntime targetFramework="4.8" maxRequestLength="30000" />
        <customErrors mode="RemoteOnly" defaultRedirect="/Error.aspx" />
    </system.web>
</configuration>

ASP.NET Framework läuft ausschließlich auf Windows und erfordert das .NET Framework (nicht .NET Core). Die Ausführung erfolgt direkt im IIS Worker Process über das ASP.NET ISAPI-Modul.

ASP.NET Core: Zwei Hosting-Modelle

ASP.NET Core bietet mehr Flexibilität. Du hast zwei Optionen für das IIS-Hosting:

In-Process Hosting (empfohlen)

Die Anwendung läuft direkt im IIS Worker Process (w3wp.exe). Das ist schneller, da keine Prozess-zu-Prozess-Kommunikation nötig ist.

<!-- web.config für ASP.NET Core In-Process -->
<configuration>
    <system.webServer>
        <handlers>
            <add name="aspNetCore" path="*" verb="*"
                 modules="AspNetCoreModuleV2" resourceType="Unspecified" />
        </handlers>
        <aspNetCore processPath="dotnet"
                    arguments=".\MeineApp.dll"
                    stdoutLogEnabled="false"
                    hostingModel="InProcess">
        </aspNetCore>
    </system.webServer>
</configuration>

Out-of-Process Hosting

IIS fungiert als Reverse Proxy vor dem Kestrel-Server. Die Anwendung läuft in einem separaten dotnet-Prozess:

<!-- web.config für ASP.NET Core Out-of-Process -->
<aspNetCore processPath="dotnet"
            arguments=".\MeineApp.dll"
            hostingModel="OutOfProcess">
    <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
    </environmentVariables>
</aspNetCore>

Out-of-Process ist flexibler (du kannst Kestrel direkt konfigurieren), aber In-Process bietet bessere Performance - etwa 4-5x schneller bei kurzen Requests.

Kestrel und IIS: Das Zusammenspiel

Die Kombination von Kestrel (dem modernen .NET-Webserver) und IIS ist ein häufiges Setup:

IIS übernimmt: SSL-Termination, statische Dateien, HTTP/3, Windows-Authentifizierung
Kestrel übernimmt: ASP.NET Core-Anwendungslogik

Diese Architektur nutzt die Stärken beider Server. IIS profitiert von HTTP.sys für alles, was der Kernel schneller kann, während Kestrel die .NET-Anwendung effizient ausführt.

Deployment-Optionen

Für das Deployment von .NET-Anwendungen auf IIS gibt es mehrere Wege:

Web Deploy (MSDeploy)

# Deployment per Web Deploy
msdeploy.exe -verb:sync -source:contentPath="C:\Build\MeineApp"
             -dest:contentPath="Default Web Site/MeineApp",
             computerName="server.example.com"

FTP/SFTP: Einfach, aber ohne atomare Deployments

CI/CD-Integration: Azure DevOps, GitHub Actions oder Jenkins können direkt auf IIS deployen:

# GitHub Actions Beispiel
- name: Deploy to IIS
  uses: SamKirkland/FTP-Deploy-Action@4.3.0
  with:
    server: ftp.example.com
    username: ${{ secrets.FTP_USER }}
    password: ${{ secrets.FTP_PASS }}
    local-dir: ./publish/

Performance und Skalierung: IIS optimal nutzen

IIS bietet mehrere Mechanismen, um Performance zu optimieren und auf hohe Last zu skalieren.

Kernel-Mode Caching: Maximale Geschwindigkeit für statische Inhalte

HTTP.sys kann statische Dateien direkt aus dem Kernel-Mode ausliefern - ohne dass der Request jemals den User-Mode erreicht. Das ist extrem schnell.

<!-- Kernel-Mode Caching aktivieren -->
<configuration>
    <system.webServer>
        <caching>
            <profiles>
                <add extension=".css" policy="CacheUntilChange"
                     kernelCachePolicy="CacheUntilChange" />
                <add extension=".js" policy="CacheUntilChange"
                     kernelCachePolicy="CacheUntilChange" />
                <add extension=".jpg" policy="CacheUntilChange"
                     kernelCachePolicy="CacheUntilChange" />
            </profiles>
        </caching>
    </system.webServer>
</configuration>

In Benchmarks erreicht der Kernel-Mode-Cache Durchsatzraten, die mit Nginx vergleichbar sind - ein Bereich, in dem IIS oft unterschätzt wird.

Output Caching: Dynamische Inhalte beschleunigen

Für dynamische Seiten, die sich selten ändern, bietet IIS Output Caching:

<system.webServer>
    <caching>
        <profiles>
            <add extension=".aspx" policy="CacheForTimePeriod"
                 duration="00:05:00" location="ServerAndClient" />
        </profiles>
    </caching>
</system.webServer>

In ASP.NET Core verwendest du Response Caching Middleware:

[ResponseCache(Duration = 300, Location = ResponseCacheLocation.Any)]
public IActionResult GetProducts()
{
    return View(products);
}

Application Request Routing (ARR): Load Balancing

ARR ist Microsofts Load-Balancing-Lösung für IIS. Du installierst es als separates Modul:

# ARR über Web Platform Installer
.\WebpiCmd.exe /Install /Products:ARRv3_0

Konfiguration einer Server Farm:

Öffne IIS Manager → Server Farms
Erstelle eine neue Farm
Füge Backend-Server hinzu
Konfiguriere Health Checks und Load-Balancing-Algorithmus

ARR unterstützt verschiedene Algorithmen:

Weighted Round Robin: Gleichmäßige Verteilung mit Gewichtung
Weighted Total Traffic: Basierend auf aktuellem Traffic
Response Time: Server mit schnellster Antwortzeit bevorzugen
Server Variable Hash: Sticky Sessions basierend auf Variablen

Web Farm Framework: Multi-Server-Deployments

Für größere Umgebungen ermöglicht das Web Farm Framework synchronisierte Deployments über mehrere Server:

Automatische Synchronisation von Inhalten und Konfiguration
Zentrales Management aller Farm-Mitglieder
Provisioning neuer Server aus einem Template

Sicherheit: IIS richtig absichern

IIS bietet umfangreiche Sicherheitsfeatures, die tief in Windows integriert sind.

Windows-Authentifizierung: NTLM und Kerberos

Die Integration mit Active Directory ist eine der größten Stärken von IIS. Benutzer können sich mit ihren Windows-Credentials anmelden - ohne separate Benutzerverwaltung.

<!-- Windows-Authentifizierung in web.config -->
<system.webServer>
    <security>
        <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true">
                <providers>
                    <add value="Negotiate" />
                    <add value="NTLM" />
                </providers>
            </windowsAuthentication>
        </authentication>
    </security>
</system.webServer>

Negotiate probiert zuerst Kerberos (sicherer, benötigt korrekten SPN) und fällt auf NTLM zurück. Für Intranet-Anwendungen ist das perfekt - Benutzer sind automatisch angemeldet.

SSL/TLS: Certificate Store Integration

IIS nutzt den Windows Certificate Store für SSL-Zertifikate. Das Zertifikatsmanagement erfolgt über:

IIS Manager: Server → Server Certificates
MMC Snap-in: certmgr.msc für lokale Zertifikate
PowerShell: Vollständige Automatisierung

# SSL-Binding erstellen
New-WebBinding -Name "Default Web Site" -Protocol https -Port 443

# Zertifikat binden
$cert = Get-ChildItem -Path Cert:\LocalMachine\My |
        Where-Object { $_.Subject -match "example.com" }

(Get-WebBinding -Name "Default Web Site" -Protocol https).
    AddSslCertificate($cert.Thumbprint, "my")

Für Let's Encrypt gibt es win-acme, ein Tool zur automatischen Zertifikatserneuerung:

# win-acme für automatische Let's Encrypt-Zertifikate
.\wacs.exe --target iis --siteid 1 --installation iis

Request Filtering: URL-basierte Sicherheit

Request Filtering blockiert verdächtige Anfragen bevor sie die Anwendung erreichen:

<system.webServer>
    <security>
        <requestFiltering>
            <!-- Maximale URL-Länge -->
            <requestLimits maxUrl="4096" maxQueryString="2048" />

            <!-- Gefährliche Dateiendungen blockieren -->
            <fileExtensions>
                <add fileExtension=".config" allowed="false" />
                <add fileExtension=".cs" allowed="false" />
            </fileExtensions>

            <!-- Bestimmte Verben einschränken -->
            <verbs>
                <add verb="TRACE" allowed="false" />
                <add verb="DEBUG" allowed="false" />
            </verbs>

            <!-- Versteckte Segmente blockieren -->
            <hiddenSegments>
                <add segment="bin" />
                <add segment="App_Code" />
            </hiddenSegments>
        </requestFiltering>
    </security>
</system.webServer>

Dynamic IP Restrictions: DDoS-Schutz

IIS kann IP-Adressen automatisch sperren, die zu viele Anfragen senden:

<system.webServer>
    <security>
        <dynamicIpSecurity>
            <denyByConcurrentRequests enabled="true" maxConcurrentRequests="20" />
            <denyByRequestRate enabled="true" maxRequests="100"
                               requestIntervalInMilliseconds="2000" />
        </dynamicIpSecurity>
    </security>
</system.webServer>

Diese Einstellung sperrt IPs, die mehr als 20 gleichzeitige Verbindungen haben oder mehr als 100 Requests in 2 Sekunden senden.

Vor- und Nachteile von IIS

Vorteile

Nahtlose Windows- und Active Directory-Integration Für Organisationen mit Windows-Infrastruktur ist IIS unschlagbar. Windows-Authentifizierung, Gruppenrichtlinien, Event-Log-Integration - alles funktioniert out-of-the-box.

Beste Plattform für ASP.NET Wenn du .NET entwickelst, ist IIS die natürlichste Wahl. Die Integration ist tief, das Tooling exzellent (Visual Studio, Web Deploy), und Microsofts Support ist umfassend.

GUI-basierte Verwaltung Der IIS Manager macht Administration zugänglich. Während Nginx und Apache Kommandozeilen-Kenntnisse erfordern, können auch weniger erfahrene Administratoren IIS verwalten.

Enterprise-Support von Microsoft Für Unternehmen mit Support-Verträgen bietet Microsoft direkten Support für IIS. Das ist für kritische Anwendungen ein wichtiger Faktor.

Nativer HTTP/3-Support Windows Server 2022 brachte HTTP/3 direkt in HTTP.sys - das bedeutet QUIC-Performance ohne Anwendungsänderungen.

Nachteile

Nur Windows verfügbar IIS läuft ausschließlich auf Windows. Das bedeutet Windows Server-Lizenzkosten und keine Linux-Container. Für Cloud-native Architekturen mit Kubernetes ist das eine signifikante Einschränkung.

Höhere Systemanforderungen Windows Server benötigt mehr RAM und CPU als ein minimales Linux-System. Ein IIS-Server braucht mindestens 2 GB RAM für den Betrieb, während Nginx auf 512 MB läuft.

Weniger flexibel als Nginx/Apache Die Konfigurationsoptionen sind begrenzter. Komplexe URL-Rewrites oder Edge-Cases erfordern manchmal kreative Lösungen oder zusätzliche Module.

Kleinere Community Die Open-Source-Community um Apache und Nginx ist größer. Es gibt mehr Tutorials, Stack Overflow-Antworten und Third-Party-Module für die Unix-Webserver.

Nicht für Linux-Container geeignet In einer Welt, die zunehmend auf Kubernetes und Linux-Container setzt, ist IIS limitiert. Windows-Container existieren, sind aber weniger verbreitet und ressourcenhungriger.

Fazit: Wann IIS die richtige Wahl ist

IIS hat seinen klaren Platz im Webserver-Ökosystem. Er ist nicht der schnellste, nicht der flexibelste und nicht der ressourceneffizienteste Webserver - aber für seinen Zielmarkt ist er oft die beste Wahl.

IIS ist ideal für dich, wenn:

Du in einer Windows-Umgebung mit Active Directory arbeitest
Deine Anwendungen auf ASP.NET oder ASP.NET Core basieren
Du Windows-Authentifizierung (Kerberos/NTLM) benötigst
Dein Unternehmen Microsoft-Support erwartet
Du eine GUI-basierte Administration bevorzugst

IIS ist weniger geeignet, wenn:

Du Linux-Server oder Container bevorzugst
Lizenzkosten minimiert werden sollen
Du maximale Flexibilität bei der Konfiguration brauchst
Dein Stack auf PHP, Python oder Node.js basiert

Für .NET-Entwickler und Windows-Shops bleibt IIS auch 2026 die solide, bewährte Wahl. Die HTTP/3-Unterstützung, die kontinuierlichen Verbesserungen in ASP.NET Core und die tiefe Windows-Integration machen IIS zu einer Plattform, die Microsoft weiterhin aktiv entwickelt.

Zurück zum Webserver-Vergleich 2026

Weiterführende Ressourcen

Hier findest du weitere Informationen zu IIS und verwandten Themen:

Microsoft IIS Dokumentation - Offizielle Referenz von Microsoft
Nginx Webserver 2026 - Der Marktführer im Vergleich
Apache HTTP Server 2026 - Der Open-Source-Klassiker

Letzte Aktualisierung: März 2026

IIS Windows Server 2026: Microsoft's Webserver für .NET & Enterprise