Windows Server 2025 / Configurare binding IIS e pool di applicazioni per due siti

Un binding IIS sceglie il sito in base a protocollo, indirizzo IP, porta e nome host. Il pool di applicazioni organizza esecuzione e identità delle applicazioni: DNS, binding, cartella dei contenuti e pool devono corrispondere per ricevere la pagina corretta.

Distinguere i quattro livelli di configurazione

Un record DNS traduce il nome in un indirizzo, senza creare un binding IIS; configurare il binding non registra il nome in DNS. Il riferimento ai binding IIS spiega protocollo e informazioni di IP, porta e host. Esaminate le combinazioni esistenti di tutti i siti prima di aggiungere o modificare; nomi visualizzati diversi non bastano a evitare conflitti.

Partite da LabSite funzionante su WEB1 a 172.24.50.30:8080, con la sua cartella e LabSitePool. Usate lo stesso client autorizzato e la regola di laboratorio già limitata a TCP 8080. Su WEB1 registrate binding completi, percorso, pool e stato prima delle modifiche, operando come amministratori. Su DC1 usate i diritti previsti di gestione DNS. Aggiungerete solo web.lab.example.test e status.lab.example.test nel laboratorio, senza modificare DNS pubblico o siti di produzione. Se StatusSite, cartella, pool o record esistono già, identificatene lo scopo e fermatevi prima di sostituirli.

Aggiungere e verificare i nomi DNS

1. Su DC1 aprite Gestore DNS → Zone di ricerca diretta → lab.example.test. Confermate la zona di prova esistente su quel server, non ad.example.test.
2. Controllate prima se web esiste come record A, alias o altro record. Solo se libero create Nuovo host (A) con nome web e indirizzo 172.24.50.30. Non sovrascrivete altri valori; un PTR non è necessario per questo accesso HTTP.
3. Ripetete controllo e creazione per status con lo stesso indirizzo. Registrate entrambi i nomi e valori come vostri oggetti di prova.
4. Verificate che CLIENT1 usi DC1, 172.24.50.10, per DNS interno. Il server interrogato espressamente in PowerShell può essere diverso dal resolver usato dal browser.
5. Da CLIENT1 interrogate entrambi i nomi e controllate i record di indirizzo restituiti. Risolvete prima errori o indirizzi diversi in DNS, senza compensarli modificando binding in modo scorretto.

Resolve-DnsName web.lab.example.test -Server 172.24.50.10
Resolve-DnsName status.lab.example.test -Server 172.24.50.10

Il parametro Server di Resolve-DnsName indica il DNS interrogato. Per entrambi i nomi si attende una risposta A 172.24.50.30. Senza Type i comandi interrogano normalmente A e AAAA; non inventate risposte IPv6 per un laboratorio soltanto IPv4. La query esplicita non dimostra che il browser usi DC1: verificate anche configurazione del client e risoluzione abituale prima della prova HTTP.

lab.example.test è la zona DNS di esercitazione del corso, separata dal dominio Active Directory ad.example.test. Una zona basata su file non si replica automaticamente a DC2 solo perché il server è controller di dominio. Se manca, controllate DC1 e la configurazione prevista prima di aggiungere record. Non usate la zona AD per somiglianza del nome e non convertite l’archiviazione della zona per proseguire.

Assegnare il nome host al binding del primo sito

1. In Gestione IIS → LabSite → Binding selezionate precisamente http / 172.24.50.30 / 8080 con nome host vuoto. Annotate i valori prima di modificarli.
2. Cambiate solo il nome host in web.lab.example.test e confermate. Conservate IP, porta, tipo, percorso e pool.
3. Esaminate i binding dopo la modifica e controllate che non rimanga una seconda combinazione identica. Non aggiungete una copia superflua con nome vuoto.
4. Su CLIENT1 aprite http://web.lab.example.test:8080/. Ci si aspetta la stessa pagina LabSite della prova precedente: controllate URL e contenuto, non solo una risposta qualunque.

L’intestazione Host di una richiesta HTTP indica il nome richiesto, non autentica un utente. Conoscere web.lab.example.test non dimostra identità né attribuisce altri permessi. Dopo aver sostituito il nome vuoto, l’accesso diretto per IP potrebbe non selezionare più LabSite o ricevere un’altra risposta se esiste un binding corrispondente diverso. Verificate ciascun sito con nome e porta previsti.

Se la richiesta fallisce, controllate prima che il nome risolva 172.24.50.30, poi confrontate protocollo, porta 8080 e nome richiesto con il binding reale. Se compare la pagina sbagliata, controllate anche binding senza nome e contenuto della cartella selezionata. DNS corretto non garantisce percorso di rete, firewall, permessi, autenticazione o pool corretti. Non sostituite DNS interno con DNS pubblico e non spegnete indiscriminatamente il firewall.

Creare il secondo sito con identità propria

1. Create C:\Sites\StatusSite soltanto se non esiste. Usate un index.html UTF-8 distinto: copiate il documento completo di LabSite della prova precedente e, solo nella copia, impostate il testo di title e h1 su StatusSite e il paragrafo su This page is served by StatusSite on WEB1. Conservate la struttura HTML senza modificare il file LabSite. Controllate l’estensione reale.
2. Create StatusSitePool solo se il nome è libero, con No Managed Code e ApplicationPoolIdentity. Non riutilizzate LabSitePool per comodità.
3. In Proprietà → Sicurezza della nuova cartella scegliete WEB1 come posizione e aggiungete IIS AppPool\StatusSitePool. Concedete Lettura ed esecuzione, Visualizzazione contenuto cartella e Lettura per cartella e file, mantenendo SYSTEM e amministratori, senza scrittura o Controllo completo al processo web.
4. In Siti → Aggiungi sito Web create StatusSite usando C:\Sites\StatusSite e StatusSitePool. Controllate tutti e tre i valori.
5. Usate binding http / 172.24.50.30 / 8080 / status.lab.example.test. Non copiate web.lab.example.test e non cambiate porta alterando il confronto.
6. Su StatusSite abilitate Autenticazione anonima e scegliete Identità pool di applicazioni. Controllate Documento predefinito abilitato con index.html e che pool e sito possano avviarsi.
7. Da CLIENT1 aprite http://web.lab.example.test:8080/ e http://status.lab.example.test:8080/. Le pagine devono mostrare messaggi distinti di LabSite e StatusSite. Se coincidono, controllate binding, percorso e file prima dell’arresto.

I siti condividono IP e porta perché il nome host distingue le richieste di questa prova HTTP. Non duplicate la combinazione completa né lasciate per errore lo stesso nome su entrambi. Esaminate le richieste che può ricevere un eventuale binding senza nome residuo; non rimuovete binding altrui senza conoscerne l’uso. La distinzione dei nomi non sostituisce autenticazione e non prepara automaticamente i certificati HTTPS.

Pool separati facilitano il controllo distinto di identità, arresto e riciclo. Condividono però sistema operativo, kernel, archiviazione e risorse host: non offrono lo stesso confine di VM separate e non garantiscono di contenere ogni sovraccarico. Applicate l’accesso minimo per identità secondo la guida alle identità dei pool. StatusSitePool non necessita di accesso superfluo ai contenuti dell’altro sito.

Confrontare arresto e riciclo del pool

1. Registrate risposte corrette dei due siti, URL, ora, pool assegnati e stato di entrambi. Senza questo riferimento, un guasto precedente non dimostra l’effetto dell’arresto.
2. In Gestione IIS → Pool di applicazioni selezionate soltanto StatusSitePool e Arresta. Ricontrollate il nome prima dell’azione, senza fermare LabSitePool o IIS intero.
3. Inviate da CLIENT1 nuove richieste ai due nomi, evitando che una pagina nella cache del browser sembri una nuova risposta del server. Esaminate stato HTTP nel pannello di rete e log, annotando i siti separatamente.
4. Scegliete StatusSitePool → Avvia e confermate il recupero con una nuova richiesta. Controllate anche LabSite prima di terminare.

Con StatusSitePool arrestato, il suo sito può restituire HTTP 503 mentre ci si aspetta che LabSite nel pool distinto continui a rispondere correttamente. Controllate entrambe le risposte: un errore qualsiasi non basta a dimostrare isolamento. Se falliscono entrambi, verificate assegnazione dei pool, stato dei siti e risorse condivise. Distinguete Arresta su un sito da Arresta su un pool; non usate iisreset né riavviate il server per questo confronto.

Il riciclo di un pool sostituisce il processo di lavoro e può influire su sessioni in memoria e attività in corso. IIS supporta condizioni di riciclo e sovrapposizione dei processi; osservare una pagina statica non garantisce continuità applicativa. Se confrontate manualmente Ricicla, fatelo solo su StatusSitePool dopo il recupero di entrambi i siti, registrando stato e richieste prima e dopo e ricontrollando le due pagine alla fine. Non cambiate soglie o pianificazioni per provocare guasti. Per pulire rimuovete soltanto StatusSite, StatusSitePool dopo aver verificato che nessun’altra applicazione lo usi, i vostri file sacrificabili e il record status creato. Conservate LabSite e il binding web se proseguite con HTTPS. Se terminate qui, ripristinate il binding originale annotato e rimuovete solo i vostri nuovi record dopo averne esaminato le dipendenze, senza eliminare zona o record del dominio.