Come installare IIS su Windows Server 2019 e 2022

IIS su Windows Server 2019 e 2022 si installa in pochi minuti, ma la differenza tra “funziona” e “è pronto per stare in produzione” sta nei dettagli: ruoli corretti, feature minime, verifica del servizio, logging attivo e una base di hardening che eviti sorprese al primo deploy.

Qui sotto trovi un percorso pratico: installazione dal Server Manager, alternativa PowerShell, controlli post-installazione e qualche accorgimento utile quando IIS deve ospitare siti interni o pubblici. L’obiettivo non è solo accendere il servizio, ma farlo in modo ripetibile e reversibile.

Prima di installare: cosa serve davvero

Su Windows Server 2019 e 2022 IIS non è un pacchetto singolo, ma un insieme di ruoli e feature del ruolo Web Server (IIS). In pratica, il sistema installa il motore web e, se richiesto, componenti aggiuntivi come gestione remota, autenticazione, ASP.NET o strumenti di compatibilità.

La scelta giusta dipende dall’uso. Per un sito statico o una web app dietro reverse proxy, spesso bastano poche feature. Per applicazioni .NET, servono anche i componenti ASP.NET e .NET Extensibility. Installare tutto “per sicurezza” aumenta superficie d’attacco e complessità senza benefici reali.

Prima di toccare il server, verifica questi punti:

• accesso con privilegi amministrativi;
• finestra di manutenzione se il server è già in uso;
• spazio disco sufficiente per log e contenuti web;
• nome host e IP già pianificati, se il sito dovrà essere pubblicato;
• eventuale firewall o security group da aggiornare dopo l’installazione.

Installazione da Server Manager

Il percorso grafico è il più semplice quando stai configurando un server singolo o quando vuoi evitare errori di digitazione. Su Server Manager l’installazione segue una logica guidata e rende visibili i componenti selezionati prima del commit finale.

1. Apri Server Manager.
2. Vai su Manage e scegli Add Roles and Features.
3. Lascia selezionato Role-based or feature-based installation.
4. Seleziona il server di destinazione.
5. Espandi Web Server (IIS).
6. Accetta le feature richieste dal wizard se vuoi la configurazione base.
7. Conferma e avvia l’installazione.

Per una installazione minimale, IIS abilita il nucleo del web server e la console di gestione. Se ti serve solo servire contenuto statico o fare da front-end per un’app dietro un bilanciatore, questa base è spesso sufficiente.

Dopo il completamento, apri Internet Information Services (IIS) Manager dal menu Start e verifica che il server locale compaia nel pannello a sinistra. Se il nodo si apre senza errori, il ruolo è installato correttamente e il servizio di amministrazione risponde.

Installazione con PowerShell: più veloce e ripetibile

Se devi replicare la configurazione su più host, PowerShell è la strada giusta. Ti permette di installare il ruolo con lo stesso comando su più server, documentare la change e ridurre la dipendenza dall’interfaccia grafica.

Per una installazione base:

Install-WindowsFeature Web-Server -IncludeManagementTools

Questo comando installa il ruolo Web Server e gli strumenti di gestione. Il risultato tipico mostra Success e l’elenco delle feature aggiunte. Se vuoi verificare subito lo stato del ruolo:

Get-WindowsFeature Web-Server

Per controllare anche il dettaglio delle sottocomponenti già installate:

Get-WindowsFeature *Web*

Se l’ambiente ospita applicazioni ASP.NET, aggiungi solo i moduli necessari. Un esempio comune per siti .NET Framework è questo:

Install-WindowsFeature Web-Asp-Net45, Web-Net-Ext45, Web-ISAPI-Ext, Web-ISAPI-Filter -IncludeManagementTools

Non tutte le applicazioni richiedono questi componenti. Se non hai un requisito esplicito, meglio partire dal minimo e aggiungere solo quando il deploy lo chiede.

Quali feature abilitare davvero

La parte più utile di IIS è anche quella che viene usata male: la selezione delle feature. Ogni modulo aggiuntivo apre capacità ma anche superficie di esposizione. La regola pratica è semplice: installa ciò che serve all’applicazione, non ciò che “potrebbe servire un domani”.

Una baseline ragionevole per molti scenari include:

• Web Server per il core HTTP;
• Static Content se devi servire file statici;
• Default Document per gestire index e landing page;
• HTTP Errors per pagine di errore coerenti;
• Logging per tracciare richieste e problemi;
• Request Filtering per un minimo di protezione lato input;
• Management Tools per amministrare il server.

Se la macchina ospita applicazioni ASP.NET, aggiungi solo il runtime compatibile con l’app. Per esempio, una web app legacy su .NET Framework può richiedere feature diverse da una app moderna che gira altrove dietro reverse proxy. La compatibilità va verificata sul deployment package, non “a occhio”.

Verifica immediata dopo l’installazione

Non considerare l’installazione conclusa finché non hai verificato che il sito predefinito risponda localmente. Il controllo minimo è una richiesta HTTP verso localhost.

curl http://localhost

Su Windows, se curl non è disponibile nel contesto che usi, puoi testare anche con PowerShell:

Invoke-WebRequest http://localhost -UseBasicParsing

Il risultato atteso è una risposta HTTP valida, in genere la pagina di benvenuto di IIS o la pagina configurata sul sito predefinito. Se ottieni errore di connessione, controlla che il servizio sia in esecuzione e che non ci siano conflitti sulla porta 80.

Per vedere lo stato del servizio web:

Get-Service W3SVC

Stato atteso: Running. Se è fermo, prova l’avvio manuale:

Start-Service W3SVC

Se il servizio parte ma il sito non risponde, il problema non è l’installazione in sé: guarda binding, firewall o un eventuale software che occupa la porta HTTP.

Creare il primo sito in modo pulito

Il sito predefinito serve solo come test iniziale. In produzione conviene creare un sito dedicato con una propria directory, un proprio binding e, se possibile, un application pool separato. Questo isola applicazioni diverse e semplifica il troubleshooting.

1. Apri IIS Manager.
2. Espandi il server e vai su Sites.
3. Seleziona Add Website.
4. Imposta nome sito, percorso fisico e binding.
5. Definisci host header se il server ospita più siti.
6. Crea o assegna un application pool dedicato.

Un esempio pratico: se il sito è intranet.example.local, il binding HTTP può usare la porta 80 e l’host header corrispondente. Se usi HTTPS, il certificato deve essere già presente nello store del computer locale e associato al binding corretto.

Per molte installazioni è utile separare il contenuto web in una directory come C: ginx no, qui meglio evitare confusione: per IIS usa una cartella dedicata, per esempio C: Siti ome-sito o D: eleases ome-sito, a seconda della tua struttura. L’importante è che il percorso sia chiaro e con permessi coerenti.

Permessi filesystem e identità dell’application pool

Molti problemi di IIS non nascono da IIS, ma dai permessi NTFS. L’application pool gira con un’identità specifica e deve poter leggere i file del sito; se l’applicazione scrive upload o cache, servono permessi aggiuntivi solo su quelle directory.

La buona pratica è questa:

• lettura sul root del sito per l’identità dell’application pool;
• scrittura solo sulle directory che la richiedono;
• niente permessi troppo ampi su Users o Everyone;
• se possibile, usa un pool dedicato invece di riutilizzare quello di default.

Per vedere quale identità usa il pool, apri Application Pools in IIS Manager e controlla Advanced Settings. In molti casi vedrai ApplicationPoolIdentity, che è una scelta sensata come punto di partenza.

Se un sito restituisce 500 appena pubblicato, controlla subito il log eventi e i log IIS prima di cambiare permessi a caso. Una modifica troppo ampia maschera il problema reale e peggiora la sicurezza.

Logging, diagnostica e punti dove guardare per primi

IIS scrive log di accesso in una cartella separata per sito. Il percorso standard è sotto C:\inetpub\logs\LogFiles. Se il sito non risponde come previsto, i log ti dicono almeno se la richiesta arriva al server e con quale codice HTTP esce.

Tre controlli rapidi aiutano a restringere il problema:

1. log IIS per status code e tempo di risposta;
2. Event Viewer per errori di application pool o runtime;
3. configurazione del binding nel sito e nel certificato, se HTTPS.

Nel caso di errore 503, spesso il pool non è avviato o si arresta subito dopo il tentativo di startup. Nel caso di 500.19, il problema è quasi sempre nella configurazione del sito o in un modulo mancante. In entrambi i casi, la lettura dei log è più utile di qualsiasi tentativo di reinstallazione.

Abilitare HTTPS senza improvvisare

Se il sito è esposto in rete, HTTPS va pianificato subito. IIS supporta binding TLS nativamente, ma il certificato deve essere presente nello store corretto e associato al sito con il nome host giusto, soprattutto se ospiti più domini sulla stessa macchina.

Il flusso corretto è:

1. importare il certificato nello store Local Computer;
2. verificare che la chiave privata sia leggibile dal servizio;
3. creare o modificare il binding HTTPS del sito;
4. se usi SNI, specificare il nome host;
5. testare con un client che veda il certificato atteso.

Per un controllo rapido lato server, puoi usare il browser o un tool come curl -vk https://localhost, sapendo che il certificato potrebbe non combaciare con localhost. In quel caso, il test utile è verso il nome host reale del sito.

Hardening minimo che vale la pena fare subito

Installare IIS e lasciare tutto ai default è accettabile solo per un laboratorio. In un ambiente reale vale la pena fare almeno questi interventi minimi:

• rimuovere o disabilitare il sito predefinito se non serve;
• usare application pool separati per app diverse;
• abilitare solo i moduli necessari;
• limitare i permessi NTFS al minimo indispensabile;
• tenere aggiornato Windows con patch di sicurezza;
• verificare che i log ruotino e non saturino il disco;
• esporre solo le porte necessarie nel firewall.

La superficie d’attacco di IIS dipende molto più da come lo configuri che dal ruolo in sé. Una installazione pulita con moduli ridotti, logging attivo e permessi stretti è molto più gestibile di un server “completo” lasciato con configurazioni standard.

Disinstallare o tornare indietro

Se l’installazione è stata fatta come change controllato, anche il rollback deve essere chiaro. Dal punto di vista operativo, disinstallare IIS è semplice quanto installarlo, ma va fatto solo se sai che nessun servizio dipende dal ruolo.

PowerShell per rimuovere il ruolo base:

Uninstall-WindowsFeature Web-Server -IncludeManagementTools

Prima di usare questo comando, verifica che non ci siano siti in produzione, binding attivi o applicazioni che puntano al server. Se la macchina ospita anche altri componenti, il rollback va pensato per singola feature, non come rimozione totale e cieca.

In alternativa, se il problema è solo una feature aggiuntiva, puoi rimuovere il modulo specifico invece di abbattere tutto il ruolo. È spesso la scelta migliore quando il sito base funziona e il guasto è legato a un’estensione introdotta dopo.

Comando finale utile: inventario rapido dello stato

Quando devi documentare il server o preparare una change, questo comando ti dà un quadro sintetico delle feature IIS installate:

Get-WindowsFeature Web-*

Se vedi il ruolo installato ma il sito non risponde, il problema non è più “come installare IIS”. A quel punto il lavoro passa su binding, permessi, pool, log e rete. È lì che si separa una installazione corretta da una configurazione davvero operativa.