Windows Update su Windows Server: URL e porte da aprire su firewall e proxy

Guida operativa per far sì che Windows Server comunichi con Windows Update anche dietro firewall e proxy: elenco chiaro di URL e porte da consentire, note per WSUS, attenzioni su proxy autenticati e SSL inspection, più test rapidi per convalida e troubleshooting.

Indice

Domanda sintetica

Quali indirizzi (URL) e quali porte devono essere abilitati su firewall / proxy affinché un server Windows possa contattare correttamente il servizio Windows Update di Microsoft?

Soluzione riassunta

Tipo	Indirizzi da consentire*	Porte principali
Dominio principale e wildcard	`http://windowsupdate.microsoft.com` `http://.windowsupdate.microsoft.com` `https://.windowsupdate.microsoft.com`	80 (HTTP) 443 (HTTPS)
Endpoint di aggiornamento	`http://.update.microsoft.com` `https://.update.microsoft.com` `http://*.windowsupdate.com`	80 / 443
Download di pacchetti	`http://download.windowsupdate.com` `http://*.download.windowsupdate.com` `http://download.microsoft.com`	80 / 443
Telemetria e statistiche	`http://wustat.windows.com`	80
Service Pack legacy	`http://ntservicepack.microsoft.com`	80

Gli asterischi () indicano tutti i sottodomini di quel dominio.

Altre note operative

Ulteriori porte per WSUS – Se utilizzi Windows Server Update Services (WSUS) on‑premises, potrebbero servirti anche le porte 8530 (HTTP) e 8531 (HTTPS) per la replica interna fra server WSUS e i client.
Firewall/Proxy – Verifica che i dispositivi di sicurezza non facciano SSL inspection o URL filtering restrittivo sui domini wildcard, altrimenti gli update potrebbero non riuscire.
Regola di minima – In ambienti particolarmente chiusi, concedi almeno l’uscita verso i domini *.windowsupdate.microsoft.com e download.windowsupdate.com su 80 / 443; quasi tutti i pacchetti e i metadati transitano lì.
Aggiornamenti futuri – Microsoft può aggiungere nuovi endpoint; considera una policy che permetta domini Microsoft firmati con certificati validi per evitare manutenzioni manuali ricorrenti.

Perché servono queste porte e questi domini

Il flusso di Windows Update si compone di metadati (cataloghi, manifest e logiche di idoneità) e contenuti (pacchetti CAB/MSU/ESD). In genere i metadati e i servizi di orchetrazione passano su HTTPS 443 verso gli endpoint .windowsupdate.microsoft.com e .update.microsoft.com, mentre i file di grandi dimensioni sono distribuiti via CDN su HTTP 80 (ad esempio download.windowsupdate.com), comunque firmati digitalmente e verificati dal client. Per questo, anche se può sembrare controintuitivo, HTTP 80 è spesso indispensabile.

Quando l’infrastruttura impone l’uso di un proxy, ricordati che i componenti di sistema (servizi e agent) usano lo stack WinHTTP, non il proxy del browser. Di conseguenza è cruciale configurare il proxy a livello di sistema e consentire l’autenticazione compatibile con i servizi (NTLM/Negotiate o machine‑based auth se presente).

Come impostare correttamente firewall e proxy

Scelta della strategia di controllo

Allowlist per dominio – Consigliata. Consenti i domini con wildcard come in tabella; evita regole per IP, perché gli indirizzi della CDN variano e sono geolocalizzati.
Bypass dell’ispezione TLS – Escludi dalle policy di SSL inspection i domini Microsoft legati a Windows Update; l’ispezione può introdurre certificati intermedi che invalidano la catena attesa dal client.
Proxy trasparente – Evitalo per i flussi di aggiornamento. SNI e richieste di tipo range per BITS possono non funzionare correttamente.

Requisiti tecnici del proxy

Supporto HTTP Range e ripresa di download (necessario per BITS).
Keep‑Alive e gestione efficiente delle connessioni simultanee.
URL Filtering con wildcard di fine dominio (FQDN ends-with): .windowsupdate.microsoft.com, .update.microsoft.com, *.download.windowsupdate.com.
Autenticazione: se obbligatoria, preferisci NTLM/Negotiate ed evita richieste interattive (no captive portal); non tutti i servizi di sistema gestiscono credenziali utente.

WSUS e scenari ibridi

Con WSUS centralizzi il controllo degli aggiornamenti. In questo caso:

Apri 8530 (HTTP) e/o 8531 (HTTPS) tra client e server WSUS e tra WSUS in replica.
Consenti al server WSUS uscita verso i domini Microsoft elencati sopra: la sincronizzazione dei cataloghi e il download dei contenuti seguono la stessa logica del client.
Valuta SSL su WSUS se l’ambiente lo richiede (certificato attendibile dal dominio e dai client).
In ambienti ibridi (Intune/WUfB + WSUS) assicurati che i criteri di origine aggiornamenti non si sovrappongano; la priorità delle policy può dirottare i client verso WSUS o verso i servizi cloud.

Proxy autenticato e servizi di sistema

Windows Update e i servizi correlati (BITS, Orchestrator) effettuano le chiamate tramite account di sistema e WinHTTP. Per questo:

Configura il proxy a livello di sistema con netsh o contenitori GPO dedicati.
Evita regole che richiedono prompt interattivi di autenticazione.
Prevedi eccezioni per gli aggiornamenti se il proxy applica quota o shaping eccessivi.

# Visualizzare la configurazione proxy di sistema
netsh winhttp show proxy

Importare la configurazione proxy da Internet Options (WinINET)
netsh winhttp import proxy source=ie

Impostare proxy esplicito con bypass per domini locali
netsh winhttp set proxy proxy-server="http=myproxy:8080;https=myproxy:8080" bypass-list=".dominio.local;10.;192.168.*"

Reimpostare (nessun proxy)
netsh winhttp reset proxy

No a ispezione SSL e problemi correlati

L’ispezione HTTPS può alterare il certificato presentato dai server Microsoft. Anche quando non fallisce la stretta di mano, può rompere la validazione dei contenuti firmati o causare handshake intermittenti. Suggerimenti:

Inserisci i domini Windows Update nella lista di esclusione dell’ispezione.
Assicurati che il firewall supporti SNI e non tronchi l’estensione TLS necessaria al bilanciamento lato Microsoft.
Permetti l’accesso alle CRL/OCSP per la validazione dei certificati se usi un proxy TLS‑terminating interno.

Convalida e test di connettività

Dopo aver applicato le regole, effettua questi controlli dal server:

Risoluzione DNS dei domini in tabella.
Connessione TCP alle porte 80/443 tramite il proxy o direttamente, in base alla tua architettura.
Download di un file di test dal CDN per verificare BITS e richieste range.
Verifica dei log del client Windows Update.

# Test DNS e porta con PowerShell (esempi)
Test-NetConnection download.windowsupdate.com -Port 80
Test-NetConnection download.windowsupdate.com -Port 443
Test-NetConnection windowsupdate.microsoft.com -Port 443

Scarico di prova (senza salvare a disco)
Invoke-WebRequest -UseBasicParsing -Uri "http://download.windowsupdate.com" -Method Head

Log Windows Update (Server 2012 R2+)
Get-WindowsUpdateLog

Controlla anche i registri evento:

Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational
Applications and Services Logs → Microsoft → Windows → BITS‑Client → Operational

Troubleshooting mirato

Sintomi tipici di blocchi lato rete

Ricerca aggiornamenti che resta su “in corso” o termina con errori generici.
Download che si avvia ma si ferma a percentuali fisse (es. 0%, 5%, 99%).
Errori di certificato o handshake TLS nel Visualizzatore eventi.
Client WSUS che compaiono ma non scaricano contenuti approvati.

Verifiche da fare rapidamente

Proxy di sistema configurato correttamente? Vedi comandi netsh winhttp sopra.
Wildcard consentite? Molti proxy bloccano *.download.windowsupdate.com se non è configurata la regola ends-with.
Ispezione SSL disattivata per i domini Microsoft? In caso contrario, crea una bypass list.
DNS interno risolve esterni senza filtri? Eventuali filtri DNS possono troncare i CNAME della CDN.
Regole e policy del firewall applicate a tutti i segmenti (server, jump host, WSUS)?

Ripristino componenti Windows Update

Se la connettività è corretta ma il client continua a fallire, valuta un ripristino “soft” dei componenti:

net stop bits
net stop wuauserv
net stop cryptsvc

ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.old

net start cryptsvc
net start wuauserv
net start bits

Questa procedura forza la ricostruzione della cache locale (metadati e code BITS) senza rimuovere aggiornamenti già installati.

Checklist di rete pronta all’uso

DNS: risoluzione pubblica funzionante per tutti i domini in tabella.
Firewall: uscita TCP 80/443 verso .windowsupdate.microsoft.com, .update.microsoft.com, .windowsupdate.com, .download.windowsupdate.com, download.microsoft.com, wustat.windows.com, ntservicepack.microsoft.com (legacy).
Proxy: regole di allowlist con wildcard; supporto HTTP range; no captive portal; autenticazione compatibile con servizi.
SSL inspection: esclusioni per i domini di Windows Update.
WSUS: porte 8530/8531 aperte; sincronizzazione al cloud abilitata; certificati attendibili se usi HTTPS.
Monitoraggio: alert su errori Windows Update nei log Operativi; controllo periodico dei tempi di download.

Domande frequenti

È possibile consentire solo HTTPS e bloccare HTTP?

In molti ambienti moderni i metadati viaggiano interamente su HTTPS; tuttavia il CDN dei pacchetti usa ancora HTTP 80 per alcune tipologie di file firmati. Bloccare l’uscita su 80 causa spesso download interrotti o update incompleti. Se devi limitare, valuta un pilot con allowlist ristretta e monitora gli errori.

Posso usare regole basate su indirizzi IP?

Fortemente sconsigliato. Gli IP dei servizi Microsoft e delle CDN cambiano di continuo e variano per area geografica. Le wildcard per dominio sono l’unica soluzione robusta.

Serve davvero il bypass dell’ispezione SSL?

Sì, perché i client si aspettano certificati Microsoft e le catene fiduciarie originali. L’ispezione può introdurre certificati “proxy” che alterano la validazione o generano errori sporadici.

Con WSUS devo comunque aprire l’uscita ai domini Microsoft?

Sì, per il server WSUS (sincronizzazione cataloghi e download dei contenuti). I client invece parleranno solo con WSUS (8530/8531) se lo hai configurato come origine unica degli aggiornamenti.

Che differenza c’è tra WinINET e WinHTTP?

WinINET è lo stack usato dalle app “utente” (browser, Office). I servizi di sistema, incluso Windows Update, usano WinHTTP. Per questo occorre impostare il proxy a livello di sistema con netsh winhttp o GPO specifiche, indipendentemente dal proxy configurato nel browser.

Esempi di regole su firewall/proxy

Ogni prodotto ha la propria sintassi. Di seguito esempi concettuali (adattali al tuo dispositivo):

Firewall di nuova generazione

# Regola 1: consentire metadati Windows Update
Action: Allow
Match: FQDN ends-with
Domains: .windowsupdate.microsoft.com, .update.microsoft.com, *.windowsupdate.com
Apps: Web-browsing
Services: tcp/443

Regola 2: consentire download contenuti

Action: Allow
Match: FQDN ends-with
Domains: download.windowsupdate.com, \*.download.windowsupdate.com, download.microsoft.com
Services: tcp/80,tcp/443

Regola 3: telemetry minima

Action: Allow
Domains: wustat.windows.com
Services: tcp/80

Proxy con autenticazione

# Categoria "WindowsUpdateAllow"
Pattern: *.windowsupdate.microsoft.com
Pattern: *.update.microsoft.com
Pattern: *.windowsupdate.com
Pattern: download.windowsupdate.com
Pattern: *.download.windowsupdate.com
Pattern: download.microsoft.com
Pattern: wustat.windows.com
Auth: No-Auth (bypass) o Machine-Account
SSL Inspection: Bypass

Considerazioni di sicurezza

Integrità end‑to‑end: i pacchetti sono firmati da Microsoft; il client verifica le firme. Consentire HTTP 80 non degrada l’integrità, purché la firma sia valida.
Principio del minimo privilegio: applica le regole solo verso i domini necessari e limita l’uscita da server che non devono aggiornarsi.
Segmentazione: in DMZ o reti isolate valuta un WSUS intermedio che riduca la superficie di uscita verso Internet.
Monitoraggio: crea dashboard sui log WU/BITS e sul proxy per individuare pattern anomali (download troppo lenti, errori ripetuti, blocchi DNS).

Procedura consigliata passo‑passo

Mappatura dell’architettura: con o senza proxy? con o senza WSUS? segmenti e VLAN interessate?
Creazione allowlist con i domini e le porte indicati nella tabella; predisponi eccezioni a SSL inspection.
Configurazione proxy di sistema sui server (WinHTTP), idealmente via GPO.
Test con Test-NetConnection e Invoke-WebRequest; verifica DNS, porte e tempi di risposta.
Monitoraggio con Event Viewer e report del proxy/firewall; raccogli metriche di latenza e throughput.
Raffinamento delle regole in base ai log: elimina eccezioni non usate e aggiungi wildcard mancanti.

Note finali e best practice

Non usare IP statici per consentire i servizi Microsoft: la manutenzione sarebbe continua e fragile.
Documenta nel CMDB le regole applicate e i motivi; collega i change ai ticket di sicurezza.
Pianifica una revisione periodica: patch day mensile, ma verifica le regole di rete almeno trimestralmente.
Automatizza la convalida con script PowerShell che testano risoluzione DNS, apertura porte e download di prova.

Riepilogo operativo

Per abilitare correttamente Windows Update su Windows Server:

Consenti verso Internet TCP 80/443 ai domini con wildcard indicati (.windowsupdate.microsoft.com, .update.microsoft.com, *.windowsupdate.com) e al CDN (download.windowsupdate.com e wildcard correlate).
Se usi WSUS, apri 8530/8531 e lascia al server WSUS l’uscita verso i domini Microsoft.
Configura il proxy di sistema con WinHTTP e disattiva l’ispezione SSL per i domini Microsoft.
Esegui test di connettività e monitora i log per intercettare anomalie.

Seguendo queste indicazioni ottieni una configurazione robusta, manutenibile e conforme ai principi di sicurezza, riducendo gli incidenti di aggiornamento e i tempi di inattività.

Avvertenza: gli endpoint cloud possono evolvere. Mantieni una politica di allowlist basata su domini wildcard Microsoft e prevedi revisioni periodiche delle regole. In contesti altamente regolamentati, testa in laboratorio ogni modifica prima di applicarla in produzione.