Firewall Microsoft 365: endpoint da sbloccare su Windows Server (guida completa)

Se l’installazione di Microsoft 365 (ex Office 365) su un server Windows dietro firewall fallisce, la causa tipica è un’uscita Internet troppo restrittiva. Questa guida spiega quali endpoint sbloccare, come testarli e come procedere anche in reti isolate con ODT.

Indice

Panoramica del problema

Limitare l’accesso a Internet ai soli domini di primo livello come microsoft.com e office.com non è sufficiente per installare Microsoft 365. Il programma di setup e i servizi di attivazione si appoggiano a una catena di componenti: autenticazione su Azure AD, token STS, API Graph, Content Delivery Network per i pacchetti Click‑to‑Run, endpoint di configurazione, e infrastrutture di rete come Front Door ed Edge. Ciascuno di questi elementi vive su domini e sottodomini differenti, spesso distribuiti su reti globali e Anycast. Se il firewall blocca uno solo dei passaggi, l’installazione si interrompe con errori generici (ad esempio 0‑1007, 0‑1011, 0‑2039) o con tempi di attesa infiniti.

Per evitare colli di bottiglia e falsi positivi, è consigliabile autorizzare esplicitamente i principali endpoint Microsoft 365 mediante regole basate su FQDN (wildcard), o — qualora il firewall non supporti i wildcard — mediante una combinazione di liste IP ufficiali e risoluzione DNS controllata.

Principi di rete da rispettare

Regole per FQDN e wildcard: ove possibile autorizzare https://*.dominio per coprire i sottodomini attuali e futuri. Gli endpoint Microsoft 365 evolvono nel tempo; un wildcard ben scelto riduce la necessità di interventi continui.
DNS affidabile: il server deve interrogare resolver DNS che risolvano correttamente i domini Microsoft. Il DNS è parte integrante del flusso: un failure DNS equivale a connettività assente.
No ispezione TLS sugli endpoint M365: l’SSL/TLS inspection può rompere handshake, pinning, o mutual‑auth e generare errori in fase di login o download. Meglio bypassare l’ispezione sui domini elencati in questa guida.
Proxy coerente: se usate un proxy autenticato, allineate la configurazione di sistema/servizi con quella prevista dall’ambiente Office (WinHTTP/WinINET, GPO o registro).
Stabilità degli IP: gli IP cambiano. Per scenari IP‑based è essenziale consumare i range pubblici Azure aggiornati (file JSON “AzurePublicIPAddresses” / Service Tags) e rigenerare periodicamente le ACL.

Soluzione sintetica

Autorizzate in uscita (HTTP/HTTPS) i seguenti endpoint. Il simbolo * indica “qualsiasi sottodominio”.

Categoria	Endpoint principali da permettere
Portale e servizi M365	`https://.office.com`, `https://.office365.com`, `https://login.microsoftonline.com`, `https://login.windows.net`, `https://graph.microsoft.com`, `https://*.onmicrosoft.com`
Identità e autenticazione	`https://.msauth.net`, `https://.msauthimages.net`, `https://secure.aadcdn.microsoftonline-p.com`, `https://aadcdn.msauth.net`
Download software/aggiornamenti	`https://officecdn.microsoft.com`, `https://officecdn.microsoft.com.edgesuite.net`, `https://*.office.net`
Content Delivery Network (CDN)	`https://.microsoftonline.com`, `https://.microsoftonline-p.com`, `https://.microsoft.com`, `https://.msocdn.com`
Endpoint aggiuntivi	`https://.microsoftonline-p.net`, `https://.msedge.net`, `https://.msft.net`, `https://.msecnd.net`
Range IP Azure	Consentire i range pubblicati periodicamente da Microsoft (file JSON “AzurePublicIPAddresses” / Service Tags).

Porte da aprire: TCP 80 (HTTP) e TCP 443 (HTTPS) verso tutti gli endpoint sopra elencati.

Matrice di dipendenze tipiche

Questa mappa pratica aiuta a verificare quali categorie di endpoint sono usate nelle diverse fasi.

Fase	Funzione	Endpoint coinvolti	Sintomi se bloccati
Avvio setup	Risoluzione configurazioni e bootstrap	`.office.com`, `.office.net`	Setup non parte o resta in attesa; errori generici.
Autenticazione	Login utente/servizio su Azure AD	`login.microsoftonline.com`, `login.windows.net`, `*.msauth.net`, `secure.aadcdn.microsoftonline-p.com`	Schermata di login non carica; MFA non disponibile; errori di token.
Download pacchetti	Click‑to‑Run, binari e lingue	`officecdn.microsoft.com`, `officecdn.microsoft.com.edgesuite.net`, `*.msocdn.com`	Download lentissimo o interrotto; codici 0‑1011/0‑2039.
Attivazione	Licenza / SCA	`*.office.com`, `graph.microsoft.com`	Office non si attiva; richiesta login ripetuta.
Aggiornamenti	Patching e nuove build	Stessi endpoint del download + CDN	Client non aggiornati; drift di sicurezza.

Architettura consigliata per reti protette

Un’architettura pulita riduce incidenti e tempo speso in troubleshooting. Ecco un modello di riferimento:

 [Server Windows] --&gt; [Proxy/NGFW con FQDN allowlist] --&gt; [Internet]
            |                               |
            +-- DNS interno affidabile -----+

Proxy/NGFW: preferite policy FQDN‑aware con oggetti wildcard, bypass TLS inspection per i domini Microsoft 365 e caching abilitato.
DNS: usate resolver che rispettino EDNS e non riscrivano le risposte. Evitate proxy DNS “creativi” che alterano i CNAME delle CDN.
Log: abilitate il logging outbound del firewall e del proxy (dominio, SNI, categoria) per individuare rapidamente blocchi residui.

Passaggi operativi

Aggiornare le regole firewall

Inserite gli FQDN wildcard elencati nella tabella di soluzione. Se il prodotto supporta gli URL categories Microsoft 365, usatele come safety net.
Se il firewall non supporta wildcard:
- Importate e mantenete aggiornati i range IP Azure (Service Tags) per le regioni rilevanti.
- Affiancate una lista di host risolti via DNS (script pianificato che risolve i FQDN e aggiorna oggetti IP).
Escludete dall’ispezione TLS i domini di identità (login.microsoftonline.com, *.msauth.net), i CDN e officecdn.microsoft.com.

Verificare la risoluzione DNS

Dal server o da una macchina di test nella stessa subnet, eseguite:

nslookup login.microsoftonline.com
nslookup officecdn.microsoft.com
nslookup graph.microsoft.com

Verificate che i nomi si risolvano rapidamente e che non ritornino NXDOMAIN o risposte private non instradabili.

Testare la connettività

Un test rapido per la porta 443:

Test-NetConnection -ComputerName officecdn.microsoft.com -Port 443

Ripetete per alcuni endpoint chiave come login.microsoftonline.com e graph.microsoft.com. Per un check più approfondito (HEAD HTTP e reporting):

$hosts = @(
  "login.microsoftonline.com",
  "login.windows.net",
  "graph.microsoft.com",
  "officecdn.microsoft.com",
  "officecdn.microsoft.com.edgesuite.net",
  "www.office.net",
  "aadcdn.msauth.net",
  "secure.aadcdn.microsoftonline-p.com"
)

$results = foreach ($h in $hosts) {
$tcp = Test-NetConnection -ComputerName $h -Port 443 -WarningAction SilentlyContinue
try {
$head = Invoke-WebRequest -Uri ("https://{0}" -f $h) -Method Head -TimeoutSec 10 -MaximumRedirection 0 -ErrorAction Stop
[pscustomobject]@{
Host=$h; Tcp=$tcp.TcpTestSucceeded; HttpStatus=$head.StatusCode; Server=$head.Headers["server"]
}
} catch {
[pscustomobject]@{
Host=$h; Tcp=$tcp.TcpTestSucceeded; HttpStatus=$.Exception.Response.StatusCode.Value_
Server=$null
}
}
}
$results | Format-Table -Auto

Eseguire l’installazione

Con portale o setup online: una volta autorizzati gli endpoint, rilanciate il setup di Microsoft 365 o accedete al portale per il bootstrap.
Con Office Deployment Tool (ODT): in reti restrittive conviene scaricare i pacchetti su un PC con accesso completo e distribuirli in LAN (“setup.exe /download” e “setup.exe /configure”).
Ambienti altamente isolati: valutate Microsoft 365 Apps for enterprise in canale semi‑annuale con contenuti offline pre‑scaricati e aggiornamenti periodici via file share.

Gestire gli aggiornamenti futuri

Gli stessi endpoint sono usati per patch e nuove build. Lasciate le regole in modo permanente.
Monitorate periodicamente cambi e nuove dipendenze. Gli endpoint e i Service Tags possono aggiornarsi nel tempo.
Automatizzate un job che testa i domini chiave e invia alert in caso di failure ripetuti.

Configurazione del proxy

Se usate un proxy autenticato, allineate il sistema:

WinHTTP (servizi e processi di sistema):

netsh winhttp set proxy proxy-server="http=myproxy.contoso.local:8080;https=myproxy.contoso.local:8080" bypass-list="&lt;local&gt;"

Import da WinINET (impostazioni utente/IE/Edge) verso WinHTTP:

netsh winhttp import proxy source=ie

GPO: preferite criteri centralizzati per impostare proxy e bypass (PAC/WPAD). Aggiungete ai bypass i domini locali e, se possibile, i CDN Microsoft 365 in caso di problemi con l’autenticazione.

Ricordate di concedere al proxy l’accesso senza ispezione TLS per le categorie Identity e Office CDN. In caso di transparent proxy applicate eccezioni basate su SNI/FQDN.

Office Deployment Tool passo‑passo

Scenario: la rete produzione è chiusa; usate un PC “ponte” con Internet per preparare i pacchetti e un file share per distribuirli.

Download contenuti

Scaricate l’ODT su un PC con Internet e scompattatelo (contiene setup.exe e file di esempio).
Creare un file XML, ad esempio configuration-Download.xml:

&lt;Configuration&gt;
  &lt;Add OfficeClientEdition="64" Channel="Current" DownloadPath="C:\ODT\Source"&gt;
    &lt;Product ID="O365ProPlusRetail"&gt;
      &lt;Language ID="it-it"/&gt;
      &lt;ExcludeApp ID="Access"/&gt;
    &lt;/Product&gt;
  &lt;/Add&gt;
  &lt;Updates Enabled="FALSE"/&gt;
  &lt;Display Level="None" AcceptEULA="TRUE"/&gt;
&lt;/Configuration&gt;

Quindi eseguite:

setup.exe /download configuration-Download.xml

Alla fine troverete i binari nella cartella C:\ODT\Source.

Distribuzione offline

Copiate setup.exe e la cartella Source su una share raggiungibile dal server (es. \\filesrv\Office\).
Su ogni server, preparate un secondo XML (es. configuration-Install.xml) che punta alla share:

&lt;Configuration&gt;
  &lt;Add OfficeClientEdition="64" SourcePath="\\filesrv\Office\Source" Channel="Current"&gt;
    &lt;Product ID="O365ProPlusRetail"&gt;
      &lt;Language ID="it-it"/&gt;
    &lt;/Product&gt;
  &lt;/Add&gt;
  &lt;Updates Enabled="TRUE" UpdatePath="\\filesrv\Office\Source"/&gt;
  &lt;Display Level="None" AcceptEULA="TRUE"/&gt;
&lt;/Configuration&gt;

Eseguite l’installazione:

setup.exe /configure configuration-Install.xml

Questo approccio riduce al minimo la dipendenza dalla connettività Internet del server e rende ripetibile la distribuzione.

Bypass dell’ispezione TLS

Se il proxy/NGFW effettua SSL inspection, predisponete eccezioni per le categorie:

Identità: login.microsoftonline.com, login.windows.net, *.msauth.net, secure.aadcdn.microsoftonline-p.com
CDN e download: officecdn.microsoft.com, officecdn.microsoft.com.edgesuite.net, *.msocdn.com
Backbone Microsoft: .microsoftonline.com, .microsoft.com, *.msedge.net

Motivo: i flussi di autenticazione e distribuzione usano meccanismi sensibili a man‑in‑the‑middle e header specifici; l’ispezione può alterare certificati, cipher o SNI, causando errori difficili da diagnosticare.

Automazione dei test

Programmate un controllo quotidiano degli endpoint chiave per avere visibilità proattiva. Esempio di script PowerShell “quick health check” con output su CSV:

$targets = @(
  "login.microsoftonline.com","graph.microsoft.com",
  "officecdn.microsoft.com","officecdn.microsoft.com.edgesuite.net",
  "www.office.net","aadcdn.msauth.net","secure.aadcdn.microsoftonline-p.com"
)

$rows = foreach ($t in $targets) {
$okTcp = (Test-NetConnection $t -Port 443 -WarningAction SilentlyContinue).TcpTestSucceeded
try {
$resp = Invoke-WebRequest -Uri ("https://{0}" -f $t) -Method Head -TimeoutSec 10 -ErrorAction Stop
[pscustomobject]@{ Timestamp=(Get-Date); Host=$t; Tcp=$okTcp; Http=$resp.StatusCode; LatMs=$resp.RawContentLength }
} catch {
[pscustomobject]@{ Timestamp=(Get-Date); Host=$t; Tcp=$okTcp; Http=$null; LatMs=$null }
}
}
$csv = "C:\Temp\M365EgressHealth.csv"
$rows | Export-Csv -NoTypeInformation -Path $csv
Write-Host "Report scritto in $csv"

Monitoraggio e log utili

Firewall/Proxy: log di deny con SNI/FQDN, categoria URL, nome utente (se autenticato), certificato presentato. Attivate almeno 7–14 giorni di retention.
Windows: Event Viewer → Applications and Services Logs → Microsoft → Office → C2RClient/Telemetry per errori di Click‑to‑Run.
Performance: se i download sono lenti, abilitate caching sul proxy per officecdn.microsoft.com e verificate la latenza verso i nodi *.edgesuite.net.

Troubleshooting approfondito

Login non carica: controllate blocchi su login.microsoftonline.com e secure.aadcdn.microsoftonline-p.com. Verificate anche il bypass TLS inspection.
Errore 0‑1011/0‑2039 durante download: quasi sempre officecdn.microsoft.com o il relativo CDN (Akamai *.edgesuite.net) bloccato. Provate un curl -I https://officecdn.microsoft.com.
Loop di attivazione: aprite graph.microsoft.com e i domini portale. Se usate Shared Computer Activation, verificate che il server raggiunga gli endpoint identity.
Windows Firewall locale: non è ideale per allowlist FQDN wildcard; meglio demandare a proxy/NGFW.
DNS “particolari”: filtri su CNAME o riscritture possono rompere la catena CDN. Usate resolver standard o gli stessi dei client che già funzionano.
Proxy autenticato: alcune fasi di setup girano come servizio di sistema; assicuratevi che WinHTTP sia configurato e che le credenziali siano valide.

Consigli per reti completamente chiuse

Golden image: preparate VM o template con Microsoft 365 già installato e attivazione deferred (dove consentito dalla policy), poi aggiornate tramite share locale.
Ciclo mensile: almeno una volta al mese aggiornate il repository ODT dalla rete “ponte”, poi ripubblicate i pacchetti interni.
Lingue: i language pack richiedono download extra dagli stessi endpoint CDN; includeteli nella fase download ODT.
Backout plan: mantenete due versioni sullo share (corrente e precedente) per un rapido rollback in caso di regressioni.

Checklist finale

DNS risolve correttamente login.microsoftonline.com, graph.microsoft.com, officecdn.microsoft.com.
Uscita TCP 80/443 consentita verso tutti gli endpoint della tabella (meglio con wildcard FQDN).
Ispezione TLS disattivata per Identity e CDN Microsoft 365.
Proxy configurato sia per WinINET sia per WinHTTP (se presente).
Script di health‑check pianificato e logging attivo su firewall/proxy.
Per reti chiuse: repository ODT aggiornato e share accessibile dai server.

Domande frequenti

Serve davvero aprire così tanti domini?
Sì. Microsoft 365 è un ecosistema di servizi: identità, API, CDN e portali. Limitarsi ai domini “generici” non copre CNAME e host dedicati al download o alla federazione.

Posso autorizzare solo IP?
Possibile ma oneroso: i CDN e i front‑end cambiano dinamicamente. Se il vostro NGFW non gestisce i wildcard, integrate Service Tags Azure e uno script che aggiorni gli IP dei FQDN critici.

Quali porte devo aprire?
Bastano TCP 80 e TCP 443 verso gli endpoint Microsoft 365. Il DNS resta necessario verso il vostro resolver.

L’ispezione TLS è compatibile?
In genere no con identità e alcuni CDN. Applicate un bypass mirato per i domini indicati.

ODT supporta aggiornamenti interni?
Sì: impostate UpdatePath verso lo share locale e pianificate l’aggiornamento dei contenuti su base mensile.

Conclusioni

Consentendo gli endpoint riportati e seguendo i passaggi operativi, l’installazione — e i successivi aggiornamenti — di Microsoft 365 su server Windows dietro firewall restrittivo diventa ripetibile e stabile. Affidatevi a regole FQDN con wildcard, a un DNS corretto e a test automatici: così ridurrete al minimo i fermi e i falsi allarmi.