¿La instalación de Microsoft 365 (Office 365) en tu Windows Server falla porque el firewall solo permite microsoft.com y office.com? Aquí tienes una guía práctica para abrir exactamente lo necesario (FQDN y puertos), verificar conectividad y, si hace falta, desplegar sin conexión.

Resumen del problema

En entornos con salida a Internet muy restringida, limitar el acceso únicamente a microsoft.com y office.com no es suficiente para instalar o activar Microsoft 365. El instalador Click-to-Run, los servicios de identidad (Azure AD), las CDN y los orígenes de actualización usan dominios y subdominios adicionales entregados por redes de distribución de contenido cuyos destinos cambian de forma dinámica. Por eso la instalación suele fallar con errores de descarga, autenticación o activación.

Por qué no basta con “microsoft.com” y “office.com”

• La autenticación moderna se realiza en Azure AD y servicios asociados (login, msauth, aadcdn), no directamente bajo office.com.
• La descarga del producto y de actualizaciones se sirve desde CDN dedicadas (por ejemplo officecdn.microsoft.com) y sus dominios de borde.
• El contenido está detrás de redes de entrega globales: el nombre público (FQDN) resuelve a IP distintas según región, disponibilidad y capacidad.
• Muchas inspecciones TLS/SSL o proxys transparentes interfieren con la negociación segura y rompen la autenticación o la descarga si no se excluyen adecuadamente.

Requisitos mínimos de conectividad

Para instalar, activar y funcionar con normalidad, permite salida a estos FQDN/grupos (preferentemente por FQDN, no por IP):

Portal y servicios

• .office.com, .office365.com
• login.microsoftonline.com, login.windows.net
• graph.microsoft.com, *.onmicrosoft.com

Identidad y autenticación

• .msauth.net, .msauthimages.net
• secure.aadcdn.microsoftonline-p.com, aadcdn.msauth.net

Distribución del software y actualizaciones

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

CDN y entrega de contenido

• .microsoftonline.com, .microsoftonline-p.com
• .microsoft.com, .msocdn.com

Otros servicios usados con frecuencia

• .msedge.net, .msft.net, *.msecnd.net

Puertos, DNS y alcance

• Puertos: HTTPS 443 obligatorio; en algunos escenarios se requiere también HTTP 80 (p. ej., redirecciones iniciales de CDN o validaciones no críticas).
• Resolución DNS: habilita resolución para todos los FQDN anteriores. Sin DNS funcional (interno o público), la instalación no podrá localizar los orígenes correctos.
• Dirección: reglas de salida (egress) desde el servidor hacia Internet.

Tabla de referencia rápida

Grupo	FQDN / Patrón	Puerto	Uso principal	Imprescindible para
Portal/Servicios	.office.com, .office365.com	443	Portal, recursos web, experiencia de usuario	Navegación inicial y acceso a apps
Identidad	login.microsoftonline.com, login.windows.net	443	Autenticación, tokens	Instalación y activación
APIs	graph.microsoft.com, *.onmicrosoft.com	443	APIs y servicios de la organización	Funcionalidad extendida
Identidad/Recursos estáticos	.msauth.net, .msauthimages.net	443	Recursos de autenticación	Sign-in fluido
AAD CDN	secure.aadcdn.microsoftonline-p.com, aadcdn.msauth.net	443	Contenido de inicio de sesión	Autenticación y MFA
Distribución/Updates	officecdn.microsoft.com	443	Paquetes Click-to-Run	Instalación y parches
CDN de Office	officecdn.microsoft.com.edgesuite.net, *.office.net	443	Entrega de binarios	Instalación y parches
Contenido Microsoft	.microsoftonline.com, .microsoftonline-p.com, .microsoft.com, .msocdn.com	443	Recursos estáticos/telemetría no crítica	Experiencia y compatibilidad
Infraestructura CDN	.msedge.net, .msft.net, *.msecnd.net	443	Nodos de distribución	Entrega estable

Comprobaciones rápidas antes de reintentar

Desde el servidor, valida conectividad:

Test-NetConnection officecdn.microsoft.com -Port 443
Test-NetConnection login.microsoftonline.com -Port 443
Resolve-DnsName officecdn.microsoft.com

Si usas proxy:

# Ver configuración WinHTTP (servicios)
netsh winhttp show proxy

Importar desde la configuración del explorador (WinINET) si aplica

netsh winhttp import proxy source=ie 

¿Y si mi firewall solo permite por IP?

Evítalo si puedes. Los servicios de Microsoft 365 se publican en infraestructuras con IPs variables y cambian a menudo. Si no hay alternativa:

• Permite los rangos públicos de Microsoft/Azure pertinentes y establece un proceso de actualización periódica.
• Considera usar un proxy que sí acepte reglas por FQDN o patrones de host.
• Documenta “quién” y “con qué frecuencia” actualiza la lista (automatización recomendada).

Buenas prácticas de firewall/proxy e inspección TLS

• Bypass de inspección TLS para los FQDN de identidad y distribución listados. Muchas pasarelas rompen el flujo si sustituyen certificados.
• SNI requerido: si tu dispositivo filtra por SNI, asegúrate de que los nombres de servidor de los FQDN anteriores no se vean alterados por el proxy.
• DNS coherente: no mezcles resoluciones internas y externas sin reglas claras; evita “DNS split-horizon” no documentado.
• Registro (logging): habilita logs de denegación de salida por FQDN y por SNI; te ayudarán a identificar el dominio exacto que falta.

Instalación sin conexión con Office Deployment Tool (ODT)

Si necesitas minimizar el acceso a Internet:

1. Desde un equipo con Internet, descarga el contenido: setup.exe /download configuration.xml
2. Copia la carpeta descargada a un recurso compartido interno y en el servidor ejecuta: setup.exe /configure configuration.xml
3. Configura una origen de actualizaciones local para reducir tráfico a Internet.

Plantilla de configuration.xml para instalar desde red interna

<Configuration>
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="\\FILESRV\Office\Source">
    <Product ID="O365ProPlusRetail">
      <Language ID="es-es" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" UpdatePath="\\FILESRV\Office\Updates" />
  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="SharedComputerLicensing" Value="1" /> <!-- si usas SCA en RDS/VDI -->
</Configuration>

Checklist de apertura controlada

1. Definir alcance: solo salida 443 (y 80 si es imprescindible) hacia los FQDN listados.
2. DNS: confirmar que los FQDN resuelven en el servidor.
3. Proxy: configurar WinHTTP/WinINET, y excepciones de inspección TLS.
4. Pruebas: ejecutar las comprobaciones de red y un piloto de instalación.
5. Monitoreo: revisar logs y actualizar reglas si aparecen nuevos FQDN de la misma familia (CDN).
6. Operación continua: programar revisión periódica de endpoints; documentar.

Script de diagnóstico: validación de conectividad

El siguiente script prueba resolución y conectividad por 443/80 a un conjunto representativo. Puedes ampliarlo según tus necesidades.

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

\$results = foreach (\$t in \$targets) {
\$ips = @()
try { \$ips = (Resolve-DnsName -Name \$t -ErrorAction Stop | Where-Object {$\_.IPAddress} | Select-Object -ExpandProperty IPAddress) } catch {}
foreach (\$p in @(443,80)) {
\$tnc = Test-NetConnection -ComputerName \$t -Port \$p -WarningAction SilentlyContinue
\[PSCustomObject]@{
Host = \$t
Port = \$p
DnsResolved = \$ips -ne \$null -and \$ips.Count -gt 0
Reachable = \$tnc.TcpTestSucceeded
RemoteAddress = \$tnc.RemoteAddress
}
}
}

\$results | Format-Table -AutoSize

Exporta a CSV si lo prefieres:

\$results | Export-Csv -NoTypeInformation -Path "\$env\:TEMP\m365\_connectivity.csv"

Errores frecuentes y cómo interpretarlos

• Fallo al descargar archivos de instalación/actualización: suelen faltar officecdn.microsoft.com o su CDN de borde.
• Inicio de sesión en bucle o MFA que no aparece: faltan login.microsoftonline.com, aadcdn.msauth.net o se intercepta el TLS.
• Activación o licenciamiento intermitente: problemas con endpoints de identidad y .office.com; revisa cachés y exclusiones de proxy.
• Con proxy autenticado: servicios que corren como servicio pueden usar WinHTTP, no las credenciales del usuario; configura credenciales del proxy a nivel de máquina si aplica.

Recomendaciones de operación continua

• Proceso de mantenimiento: designa un responsable y cadencia (mensual/trimestral) para revisar cambios en endpoints de Microsoft 365.
• Entornos regulados: si estás en nubes especiales (GCC, GCC High, DoD, China), los dominios pueden variar; valida las variantes de tu región.
• Telemetría y diagnósticos: si bloqueas completamente la telemetría, prueba en preproducción ya que algunas funciones degradan su experiencia.

Plantilla breve para solicitar apertura al equipo de seguridad

Asunto: Apertura controlada para instalación y operación de Microsoft 365

Necesitamos permitir salida TCP 443 (y 80 en escenarios puntuales) desde el servidor \ hacia los FQDN de Microsoft 365:

- .office.com, .office365.com
- login.microsoftonline.com, login.windows.net
- graph.microsoft.com, \*.onmicrosoft.com
- .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

Justificación: instalación, autenticación moderna, activación y actualizaciones de Microsoft 365.
Solicitamos además bypass de inspección TLS para estos FQDN y resolución DNS funcional.

Preguntas frecuentes

¿Debo permitir HTTP 80? No siempre, pero algunos flujos iniciales o redirecciones de CDN pueden usarlo. Prioriza 443; habilita 80 si detectas fallos en la negociación inicial.

¿Puedo reducir la lista? Técnicamente sí, pero perderás resiliencia y te expones a fallos cuando cambie la topología de la CDN. Es preferible permitir los grupos completos de host indicados.

¿Qué hay de Teams/OneDrive/Skype? Cada app tiene endpoints adicionales. Este artículo cubre la instalación/activación de Microsoft 365 Apps. Para apps específicas, revisa sus requisitos de red correspondientes.

¿Windows Server es compatible? Verifica la compatibilidad de tu versión de Windows Server y, si usas RDS/VDI, habilita Shared Computer Activation en la configuración.

Guía paso a paso recomendada

1. Abrir FQDN y puertos listados arriba (salida 443; 80 si fuese necesario) y configurar bypass de inspección TLS.
2. Validar DNS y proxy (WinHTTP/WinINET) con los comandos de comprobación.
3. Probar instalación con ODT desde CDN. Si el entorno lo requiere, preparar origen local con ODT.
4. Activar y validar inicio de sesión y licenciamiento; revisar el Visor de eventos y los registros de proxy/firewall.
5. Estabilizar operación definiendo una fuente de actualizaciones (CDN o compartida) y monitoreo de errores de Click-to-Run.
6. Mantener actualizado el inventario de endpoints con un proceso formal en tu organización.

Resumen accionable

• Abre salida a los FQDN de portal/identidad/CDN/distribución descritos.
• Garantiza DNS funcional y exclusión de inspección TLS.
• Valida conectividad con Test-NetConnection y Resolve-DnsName.
• Si necesitas minimizar Internet, usa ODT con origen local para instalar y actualizar.
• Si tu firewall solo trabaja por IP, adopta un mecanismo de actualización continua de rangos.

Apéndice: ejemplos útiles

Reglas ilustrativas de salida (genéricas)

# Nota: cada firewall tiene su sintaxis. Ilustrativo:
- Permite TCP 443/80 hacia dominios listados
- Aplica bypass de inspección TLS para dichos dominios
- Habilita logging de denegaciones

En Windows Defender Firewall (ejemplo genérico por proceso/puertos)

netsh advfirewall firewall add rule name="Office C2R Outbound 443" dir=out action=allow protocol=TCP localport=any remoteport=443 program="%ProgramFiles%\Common Files\microsoft shared\ClickToRun\OfficeClickToRun.exe" enable=yes 

ODT con canal y origen local de actualizaciones

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise" />
  <Updates Enabled="TRUE" UpdatePath="\\FILESRV\Office\Updates" />
  <Display Level="None" AcceptEULA="True" />
  <Property Name="AUTOACTIVATE" Value="1" />
</Configuration>

---

Conclusión

Para instalar y operar Microsoft 365 en un servidor con firewall restrictivo debes permitir más que microsoft.com y office.com. Habilita salida 443 (y, si aplica, 80) hacia los FQDN de identidad, portal, CDN y distribución indicados; verifica la resolución DNS; excluye de inspección TLS los dominios críticos; y, si el entorno lo exige, despliega con ODT y una fuente de actualizaciones local. Con estas medidas, la instalación y el mantenimiento de Microsoft 365 serán estables y repetibles incluso en redes altamente controladas.

Referencia rápida (copiar/pegar)

- Portal/Servicios:
  .office.com, .office365.com
  login.microsoftonline.com, login.windows.net
  graph.microsoft.com, *.onmicrosoft.com

- Identidad y autenticación:
  .msauth.net, .msauthimages.net
  secure.aadcdn.microsoftonline-p.com, aadcdn.msauth.net

- Distribución/Actualizaciones:
  officecdn.microsoft.com
  officecdn.microsoft.com.edgesuite.net
  \*.office.net

- CDN/Contenido:
  .microsoftonline.com, .microsoftonline-p.com
  .microsoft.com, .msocdn.com

- Otros:
  .msedge.net, .msft.net, \*.msecnd.net

Puertos: 443 (obligatorio) y 80 (si aplica)
DNS: resolución funcional para todos los FQDN 

---

Notas finales importantes

• Inspección TLS/SSL: crea excepciones (bypass) para los FQDN de Microsoft 365; la inspección puede romper autenticación y descarga.
• ODT e instalación offline: ideal para minimizar exposición a Internet; combina con un origen de actualizaciones local.
• Mantenimiento continuo: los endpoints de Microsoft 365 evolucionan; mantén un proceso de actualización de reglas y listas.

Comandos rápidos de verificación

Test-NetConnection officecdn.microsoft.com -Port 443
Test-NetConnection login.microsoftonline.com -Port 443

---

Sobre rangos de IP: si tu dispositivo no admite FQDN y solo IP, recuerda que las IP cambian con frecuencia. Permite los rangos públicos pertinentes y automatiza su actualización. Evalúa migrar a un proxy que soporte FQDN para un control más fino.