Pré‑requisitos de rede para instalar o Microsoft 365 atrás de firewall restritivo (Office 365)

Instalar o Microsoft 365 atrás de um firewall/proxy “bloqueia‑tudo, libera‑o‑mínimo” costuma falhar por depender de serviços de identidade, CDNs e distribuição que vão muito além de microsoft.com e office.com. Este guia mostra exatamente o que permitir, como testar e como instalar mesmo em redes ultra‑restritas.

Índice

Visão geral do cenário

Em servidores Windows (incluindo Windows Server com funções de Remote Desktop Services, VDI ou Citrix), a instalação do Microsoft 365 Apps pode interromper com erros genéricos (“não foi possível baixar os arquivos”, “verifique sua conexão”, “código 30088‑13”, etc.) quando há allowlist insuficiente. A raiz do problema é que o instalador, a ativação e as atualizações dependem de diferentes serviços e domínios distribuídos globalmente.

Por que liberar apenas dois domínios não funciona

Os aplicativos do Microsoft 365 precisam autenticar o usuário e/ou o dispositivo (Azure AD/MSA), obter metadados de catálogo e baixar grandes pacotes via CDNs. Esses fluxos usam endpoints distintos do portal principal. Além disso, muitos domínios resolvem para redes de entrega de conteúdo com nomes e CNAMEs dinâmicos. Por isso, liberar somente microsoft.com e office.com não cobre:

Login federado e tokens de identidade (Azure AD, endpoints de OAuth e OpenID Connect).
CDNs de imagens, scripts, manifestos e pacotes do instalador/atualizações.
Serviços auxiliares (.msedge.net, .msecnd.net, etc.).
Redirecionamentos HTTP/HTTPS comuns durante a instalação e ativação.

O que liberar no firewall/proxy

Abaixo, os grupos essenciais com exemplos práticos para allowlist por FQDN (preferível em relação a IP). Use curingas (*.) sempre que indicado.

Portal e serviços do Microsoft 365

*.office.com
*.office365.com
graph.microsoft.com
*.onmicrosoft.com

Identidade e autenticação (Azure AD / MSA)

login.microsoftonline.com
login.windows.net
*.msauth.net
*.msauthimages.net
secure.aadcdn.microsoftonline-p.com
aadcdn.msauth.net

Distribuição do Office (instalação e atualizações)

officecdn.microsoft.com
officecdn.microsoft.com.edgesuite.net
*.office.net

CDNs e infraestrutura de suporte

*.microsoftonline.com
*.microsoftonline-p.com
*.microsoft.com
*.msocdn.com
*.msedge.net
*.msft.net
*.msecnd.net
*.microsoftonline-p.net

Faixas de IP dos datacenters (opcional)

Se sua política exigir regras por IP, avalie os intervalos oficiais de nuvem. Porém, IPs mudam com frequência. Sempre que possível, prefira regras por hostnames/FQDN com SNI e proxy ciente de domínios.

Mapa rápido de permissões

Categoria	Exemplos de FQDNs	Protocolos	Observações
Portal/Serviços	`.office.com`, `.office365.com`, `graph.microsoft.com`	HTTPS 443 (HTTP 80 para redirecionamentos)	Essenciais para inicialização do cliente e telemetria.
Identidade	`login.microsoftonline.com`, `*.msauth.net`	HTTPS 443	Criar bypass da inspeção TLS; tokens falham com man-in-the-middle.
Distribuição	`officecdn.microsoft.com`, `*.office.net`	HTTPS 443	Pacotes grandes; verifique limiares de tamanho e timeout.
CDNs	`.msedge.net`, `.msecnd.net`, `*.msocdn.com`	HTTPS 443 (HTTP 80 para redirecionamentos)	Conteúdo estático e downloads; não inspecionar quando possível.

Portas, protocolos e DNS

Libere HTTPS 443 e HTTP 80 para os destinos citados (HTTP é comum para redirecionamentos a HTTPS).
Garanta resolução DNS funcional para todos os FQDNs (incluindo CNAMEs que apontam para CDNs).
Evite split‑DNS que quebre resoluções públicas esperadas.
Se houver bloqueios de HTTP methods ou header stripping, valide que GET/HEAD estão permitidos e que o header Host e o Server Name Indication (SNI) são preservados.

Inspeção TLS/SSL e SNI

Inspeção TLS em proxies corporativos é causa recorrente de falhas de login, ativação e download. Recomenda-se bypass (não inspecionar) para:

login.microsoftonline.com
login.windows.net
*.msauth.net
*.msauthimages.net
secure.aadcdn.microsoftonline-p.com
aadcdn.msauth.net
officecdn.microsoft.com
*.office.net

Motivos:

A identidade depende de certificados de emissão específica e de certificate pinning em alguns fluxos.
CDNs do Office usam otimizações que podem ser quebradas por recriptação.
Interferências em TLS 1.2/1.3 ou ciphers podem interromper a sessão.

Proxy, contexto SYSTEM e WinHTTP

Instalações automatizadas (SCCM/MECM, GPO, Intune, serviços) frequentemente executam no contexto SYSTEM, que não usa as configurações de proxy do usuário (WinINET). Configure o proxy do WinHTTP para o sistema:

# Ver o proxy atual do WinHTTP
netsh winhttp show proxy

Importar do IE do usuário (execute em sessão com proxy funcional)

netsh winhttp import proxy source=ie

Ou definir explicitamente

netsh winhttp set proxy proxy-server="proxy.suaempresa:8080" bypass-list=".local;10.;192.168.\*"

Se seu proxy requer autenticação, assegure que o método permita machine auth (por exemplo, NTLM/Kerberos) ou crie exceções de autenticação para os FQDNs listados.

Como validar conectividade

Antes de reinstalar, teste os endpoints críticos diretamente do servidor. Exemplos:

# Teste de porta TCP
Test-NetConnection -ComputerName officecdn.microsoft.com -Port 443

Resolução DNS

Resolve-DnsName officecdn.microsoft.com

Download de teste (Arquivo pequeno)

Invoke-WebRequest -Uri [https://officecdn.microsoft.com](https://officecdn.microsoft.com) -UseBasicParsing -MaximumRedirection 5

Varredura por lista (substitua pelos domínios que você liberou)

\$hosts = @(
"login.microsoftonline.com",
"officecdn.microsoft.com",
"graph.microsoft.com",
"aadcdn.msauth.net",
"secure.aadcdn.microsoftonline-p.com",
"officecdn.microsoft.com.edgesuite.net"
)
\$hosts | ForEach-Object {
Write-Host "Testando $\_ ..."
try {
\$r = Test-NetConnection -ComputerName $\_ -Port 443 -WarningAction SilentlyContinue
"{0,-45} {1}" -f \$*, (\$r.TcpTestSucceeded ? "OK" : "FALHOU")
} catch { "{0,-45} ERRO: {1}" -f \$*, $\_.Exception.Message }
}

Erros comuns e o que significam:

Falha TCP 443: bloqueio no firewall/proxy ou DNS incorreto.
407 Proxy Authentication Required: conta SYSTEM sem permissão no proxy.
401/403 nos endpoints de identidade: inspeção TLS, certificados substituídos ou SSO quebrado.
Timeout/0 bytes ao baixar do CDN: inspeção TLS, limitação de tamanho, QoS, ou bloqueio de range requests.

Passo a passo recomendado

Atualize a allowlist do firewall/proxy com os FQDNs por categoria (identidade, portal, CDN e distribuição). Use curingas conforme listados.
Implemente bypass de inspeção TLS para os domínios de identidade e CDN do Office.
Confirme o proxy WinHTTP para o contexto SYSTEM e políticas de autenticação compatíveis.
Valide portas 80/443 e resolução DNS com os comandos acima.
Execute a instalação/ativação novamente e monitore os logs do proxy para ajustes finos.

Instalação sem internet ampla usando o Office Deployment Tool (ODT)

Quando a saída é extremamente restrita, baixe os pacotes em um computador com internet e instale a partir de uma origem interna. Fluxo recomendado:

Em uma máquina com internet, obtenha o ODT e gere um configuration.xml adequado.
Baixe os arquivos de origem para um diretório local.
Publique o conteúdo em um compartilhamento interno de somente leitura (DFS/SMB) ou em um ponto de distribuição.
Nos servidores de destino, aponte a instalação para essa origem interna e defina as atualizações para o mesmo caminho.

Comandos de exemplo

# Baixar os pacotes a partir do ODT (na máquina com internet)
setup.exe /download configuration.xml

Instalar a partir da origem local (no servidor atrás do firewall)

setup.exe /configure configuration.xml

Exemplo de configuration.xml

Ajuste idioma, edição e caminhos conforme seu ambiente. O SourcePath e o UpdatePath devem apontar para a origem interna (UNC recomendado):

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise" SourcePath="\\fileserver\softwares\Office">
    <Product ID="O365ProPlusRetail">
      <Language ID="pt-BR" />
      <Language ID="pt-PT" />
    </Product>
  </Add>

\
\
\
\ \
\
\

Dicas:

Em RDS/VDI, SharedComputerLicensing deve estar em 1 para licenciamento por usuário.
Se você usa múltiplas línguas, inclua todas no XML para evitar downloads externos posteriores.
Versione o conteúdo baixado e congele o canal conforme sua política de mudanças.

Checklist de diagnóstico rápido

Verificação	Como checar	Resultado esperado
DNS resolve FQDNs	`Resolve-DnsName officecdn.microsoft.com`	Resposta com A/AAAA e/ou CNAME válido
Porta 443 aberta	`Test-NetConnection -Port 443`	`TcpTestSucceeded = True`
Proxy WinHTTP configurado	`netsh winhttp show proxy`	Proxy listado corretamente (ou Direct access)
Inspeção TLS desativada para identidade/CDN	Política do proxy	Domínios em bypass
Download de teste	`Invoke-WebRequest`	HTTP 200 com conteúdo

Matriz de sintomas e correções

Sintoma	Causa provável	Correção
Instalação trava em “Baixando…”	CDN bloqueada ou inspeção TLS	Liberar `officecdn.microsoft.com` e `*.office.net`, desativar inspeção para esses domínios
Login abre e fecha sem ativar	Endpoints de identidade bloqueados	Liberar `login.microsoftonline.com`, `*.msauth.net`, `aadcdn` e desinspecionar TLS
Erro 407 no proxy	Contexto SYSTEM sem autenticação no proxy	Configurar WinHTTP e exceções de autenticação por FQDN
Download inicia e falha perto de 100%	Timeout/limite de tamanho no proxy	Aumentar timeouts e limites; validar range requests
Ativação demora e expira	Inspeção TLS alterando certificados	Bypass de inspeção para domínios de identidade

Exemplos práticos de regras

Firewall de saída com FQDN

# Conceito (pseudoconfiguração)
ALLOW tcp/443 TO *.office.com
ALLOW tcp/443 TO *.office365.com
ALLOW tcp/443 TO login.microsoftonline.com
ALLOW tcp/443 TO *.msauth.net
ALLOW tcp/443 TO officecdn.microsoft.com
ALLOW tcp/443 TO *.office.net
ALLOW tcp/443 TO *.msedge.net
ALLOW tcp/443 TO *.msecnd.net
ALLOW tcp/80  TO .office.com, .office.net (apenas redirecionamento)

Exceção de inspeção TLS no proxy

# Conceito (lista de exclusões)
login.microsoftonline.com
login.windows.net
*.msauth.net
*.msauthimages.net
secure.aadcdn.microsoftonline-p.com
aadcdn.msauth.net
officecdn.microsoft.com
*.office.net

Exemplo de PAC com bypass seletivo

function FindProxyForURL(url, host) {
  var directHosts = [
    "login.microsoftonline.com",
    "login.windows.net",
    "officecdn.microsoft.com"
  ];
  for (var i = 0; i &lt; directHosts.length; i++) {
    if (dnsDomainIs(host, directHosts[i]) || shExpMatch(host, "*." + directHosts[i])) {
      return "DIRECT";
    }
  }
  if (dnsDomainIs(host, "office.net") || shExpMatch(host, "*.office.net")) {
    return "DIRECT";
  }
  return "PROXY proxy.suaempresa:8080";
}

Boas práticas adicionais

Padronize canais e versões: escolha um canal de atualização (ex.: Monthly Enterprise) e mantenha coerência entre máquinas para evitar múltiplos downloads.
Cache interno: considere um cache HTTP autenticado só para os domínios do Office, reduzindo tráfego externo.
Monitoramento: colete métricas de hit ratio no cache, tamanho médio de downloads e tempos de resposta por domínio.
Change management: os domínios podem crescer; estabeleça um processo leve de revisão mensal da allowlist.
TLS 1.2+: garanta que o SO tenha TLS 1.2 (ou 1.3 quando suportado) habilitado por padrão.

Quando optar pela instalação offline

Se a política impedir abertura de saída para CDNs, a abordagem com ODT e origem interna é a mais segura. Ela elimina dependências de rede durante a instalação e permite que você “aprove” previamente os binários que serão distribuídos aos servidores.

Exemplo de automação end‑to‑end

# 1) Baixe com ODT (em máquina com internet)
setup.exe /download configuration.xml

2) Publique no compartilhamento interno

\fileserver\softwares\Office

3) Nos servidores, configure WinHTTP (se necessário)

netsh winhttp set proxy proxy-server="proxy.suaempresa:8080" bypass-list=".local;.office.net;officecdn.microsoft.com"

4) Instale do share

setup.exe /configure configuration.xml

5) Valide ativação e updates (no servidor)

\$apps = Get-Item "C:\Program Files\Microsoft Office\root\Office16\*"
Write-Host "Instalados:" \$apps.Count "arquivos"

Perguntas frequentes

Posso restringir por IP em vez de FQDN?
Tecnicamente sim, mas é frágil: CDNs mudam IPs com frequência, e você terá que atualizar regras constantemente. FQDN é o caminho recomendado.

Preciso liberar HTTP 80?
Muitos fluxos já migram para HTTPS direto, mas alguns redirecionamentos ainda usam 80. Se bloquear 80, assegure que não haja redirecionamentos dependentes em sua rota.

Meu proxy faz SSL offload. Isso é um problema?
Para identidade e alguns CDNs, sim. Faça bypass de inspeção nos domínios listados.

Como garantir que o instalador use o proxy?
Defina o proxy no WinHTTP (contexto SYSTEM) e valide com os testes de rede antes de instalar. Em automações, execute um pré‑checador que confirme conectividade.

Resumo prático

Abra os domínios de identidade, portal e CDNs do Microsoft 365 (conforme as listas acima), garanta portas 80/443 e DNS funcionando, e valide com PowerShell. Se a política impedir saída ampla, use o ODT com origem interna para instalar e atualizar.

Modelo de política para copiar e adaptar

# Política de saída - Microsoft 365 (Exemplo)
Objetivo: permitir instalação, ativação e atualização do Microsoft 365 Apps

\[GERAL]
ALLOW TCP 443 para:
\*.office.com
\*.office365.com
graph.microsoft.com
\*.onmicrosoft.com
login.microsoftonline.com
login.windows.net
\*.msauth.net
\*.msauthimages.net
secure.aadcdn.microsoftonline-p.com
aadcdn.msauth.net
officecdn.microsoft.com
officecdn.microsoft.com.edgesuite.net
\*.office.net
\*.microsoftonline.com
\*.microsoftonline-p.com
\*.microsoft.com
\*.msocdn.com
\*.msedge.net
\*.msft.net
\*.msecnd.net
\*.microsoftonline-p.net

ALLOW TCP 80 para:
\*.office.com
\*.office.net

\[INSPEÇÃO TLS - BYPASS]
login.microsoftonline.com
login.windows.net
\*.msauth.net
\*.msauthimages.net
secure.aadcdn.microsoftonline-p.com
aadcdn.msauth.net
officecdn.microsoft.com
\*.office.net

\[PROXY / AUTENTICAÇÃO]
WinHTTP configurado no contexto SYSTEM
Exceções de autenticação para os FQDNs acima

Conclusão

Com uma allowlist por categoria, exceções de inspeção TLS bem definidas e testes de conectividade simples, a instalação e ativação do Microsoft 365 atrás de firewalls restritivos deixam de ser um “jogo de tentativa e erro” e passam a ser um processo previsível e auditável. Quando a abertura controlada não é possível, o ODT com origem local garante governança total sobre os binários e sobre o tráfego gerado.

Em uma linha: abra os domínios de identidade, portal e CDN do Microsoft 365, garanta portas 80/443 e DNS funcional, teste com PowerShell; se a política não permitir, instale via ODT a partir de uma origem interna.