Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 1/3

Implementar la configuración híbrida de Exchange en el entorno Office 365 puede considerarse una tarea sencilla o un proceso agotador. La experiencia que tendremos dependerá del "nivel de preparación" de la infraestructura local de Exchange y otros componentes relacionados.

En palabras simples: en caso de que comprenda cuáles son los requisitos previos que deben configurarse e implementarse, antes de iniciar el Asistente de configuración híbrida de Exchange, la mayoría de las posibilidades de que ejecutar HCW (Asistente de configuración híbrida) sea una tarea fácil y , el proceso se completará exitosamente.

En el artículo actual, revisaremos:

• Los requisitos previos del entorno híbrido de Exchange
• Mejores prácticas y recomendaciones para los preparativos requeridos.
• Herramientas y métodos que nos ayudarán a comprobar y verificar si el entorno on-Premises se configuró correctamente.

Implementación híbrida Office 365: la serie de artículos

La serie de artículos incluye los siguientes artículos:

• Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 1/3
• Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 2/3
• Implementación híbrida en Office 365 | Lista de verificación y requisitos previos | Parte 3/3

Configuración del entorno híbrido de Exchange en pocas palabras

El término configuración híbrida o entorno híbrido describe un escenario en el que dos organizaciones de Exchange separadas que pertenecen a diferentes bosques de Active Directory están trabajando como una "una unidad".
El término configuración híbrida se creó para describir este tipo de relación. entre la infraestructura local de Exchange y la infraestructura en la nube (Exchange Online).

Por ejemplo, en el siguiente diagrama vemos el concepto lógico de entorno híbrido.
El nombre de dominio público: o365info.com, configurado como un “dominio compartido”. El significado es que dos infraestructuras de Exchange separadas “representan” este nombre de dominio o comparten entre ellas el mismo nombre de dominio.

Al mirar el diagrama, podemos ver dos destinatarios: Bob@o365info.com y Alice@o365info.com

Técnicamente, los buzones de correo de los destinatarios deben configurarse en el servidor local de Exchange o en el servidor de Exchange Online, pero lógicamente, Bob y Alice no saben dónde están alojados sus buzones de correo. .

En caso de que el buzón de Bob esté alojado en el servidor local de Exchange y el buzón de Alice esté alojado en un servidor de Exchange Online, Bob y Alice tenga todos los servicios estándar de Exchange, como: tiempo libre/ocupado, sugerencias por correo y más, como si estuvieran alojados en la misma organización de Exchange. La razón es que el entorno híbrido "conecta" los dos entornos distintos de Exchange y los hace aparecer como una sola entidad.

Relaciones de configuración híbrida y concepto de confianza.

Como se mencionó anteriormente, la configuración híbrida fue diseñada para "conectar" dos entornos de Exchange diferentes y hacerlos operar como una sola entidad. Un concepto de confianza implementa el "brillo" entre los dos entornos distintos.

1. Confianza de federación: cada uno de los entornos de Exchange (local + nube) necesita o debe confiar en un "tercer elemento" llamado: MFG, la puerta de enlace de federación de Microsoft (número 1 en el diagrama).
2. Relaciones de organizaciones de Exchange: un modelo de confianza entre dos organizaciones de Exchange independientes. En el entorno híbrido, la relación de organización de Exchange se implementa entre el bosque local de Exchange y el “bosque de Office 365” (Exchange Online) (número 2 en el diagrama).

La configuración híbrida y el "modelo de confianza" permiten que cada uno de los "puntos finales" (Exchange local y Exchange Online) realice lo siguiente:

• Autenticarse mutuamente
• Verificar la identidad de cada uno
• Cree un canal de comunicación seguro: cifre la información e implemente la integridad de los datos mediante un certificado público y un protocolo de comunicación seguro como SMTP\TLS y HTTPS.

Entorno local de Exchange simple versus entorno complicado.

El término "configuración híbrida" podría usarse para describir un escenario muy simple en el que la organización tiene un solo servidor Exchange local, que actúa como servidor híbrido y es responsable de crear el "canal de comunicación" entre el entorno local y la “nube” (Exchange Online).

Otro escenario de configuración híbrida podría ser una situación más complicada, que es más común en entornos empresariales que tienen una infraestructura local de Exchange complicada.

En este escenario, la "relación" entre Exchange Online y la "infraestructura de Exchange local" podría dividirse en muchos "canales de comunicación" con servidores Exchange locales diferentes o separados.

Por ejemplo, el flujo de correo entre Exchange local y Exchange Online podría implementarse mediante el uso de un servidor Exchange local "dedicado" que se configurará para enviar correo a Exchange Online y otro servidor Exchange local que se configurará. para "aceptar" correo de Exchange Online.

Otro servidor Exchange local podría asignar diferentes roles/servicios, como un servidor Exchange local dedicado que proporcionará servicios de detección automática, un servidor Exchange local dedicado que proporcionará servicios EWS, etc.

Requisitos previos para la implementación híbrida en Office 365

En las siguientes secciones, revisaremos cada uno de los componentes que se incluyen en la lista de “Requisitos previos para el entorno híbrido”. "

1. Versión del servidor híbrido de Exchange

El término "servidor híbrido de Exchange" es solo un término lógico que describe el servidor Microsoft Exchange que puede ser parte de un entorno híbrido.

El “servidor híbrido” del servidor local de Exchange podría implementarse mediante:

• Intercambio 2010 SP3
• Intercambio 2013

Exchange 2010 SP3 como servidor híbrido

En caso de que queramos utilizar un Exchange 2010 como servidor híbrido, el requisito mínimo es el service pack 3. Además del requisito del Service Pack 3, la mejor práctica es: instalar las versiones Exchange Rollup más actualizadas porque cada uno de los software Las actualizaciones (Exchange Rollup) incluyen una solución a los problemas que se descubrieron y la solución se incluye en los Rollups.

Muchas veces el cliente o la organización TI se “resistirá” a la recomendación de “instalar el paquete acumulativo de Exchange más actualizado”, pero es importante enfatizar que instalar los paquetes acumulativos más actualizados puede prevenir muchos de los problemas futuros y considerarlos como un factor importante en el proceso de construcción del entorno híbrido.

La siguiente cita se relaciona con los paquetes acumulativos 4 para Exchange 2010 SP3, pero ya se hace una idea.

Además, recomendamos instalar futuros paquetes acumulativos de actualizaciones 4 para Exchange 2010 SP3 en todos sus servidores híbridos. Microsoft lanza paquetes acumulativos de actualizaciones aproximadamente cada seis a ocho semanas. Los paquetes acumulativos están disponibles a través de Microsoft Update y el Centro de descarga de Microsoft. En el cuadro de búsqueda del Centro de descarga de Microsoft, escriba "Paquete acumulativo de actualizaciones de Exchange 2010 SP3" para buscar enlaces a los paquetes acumulativos de Exchange 2010 SP3.

Enlace de descarga para las actualizaciones de software del servidor local Exchange requeridas

Intercambio 2010 | ¿Cómo puedo saber cuál es el Exchange Rollup actual?

En caso de que desee obtener información sobre el estado actual del servidor local de Exchange 2010, puede ver la versión actual utilizando el menú Ayuda y hacer clic en el Acerca del servidor Exchange 2010.

En la siguiente captura de pantalla, podemos ver que la versión del servidor Exchange on-Premises es: 14.03.0.195.001

Entonces, la siguiente pregunta podría ser: ¿cómo puedo saber cuál es el paquete de servicio o la versión acumulada del servidor local de Exchange en función de este número? Para poder “traducir” el valor a una información más clara, podemos utilizar el artículo: Números de compilación y fechas de lanzamiento de Exchange Server.

En la siguiente captura de pantalla, podemos ver que el número de versión: 14.3.195.1 nos “dice” que el servidor Exchange 2010 on-Premises incluye una instalación de Service Pack 3 + Paquete acumulativo 6 para Exchange 2010 SP3.

En este caso, necesitaremos descargar e instalar el paquete acumulativo más actualizado (por ejemplo, el paquete acumulativo 9).

Tampoco se deben pasar por alto la actualización acumulativa (CU), el paquete acumulativo y los paquetes de servicio que se ejecutan en el servidor local. En circunstancias normales, le recomendamos que no tenga más de dos actualizaciones por detrás de la actualización publicada actualmente para Exchange; sin embargo, para entornos híbridos, somos más estrictos y no debe tener más de una compilación por detrás.
Si la última actualización es Exchange 2013 CU9, entonces debe tener Exchange 2013 CU9 o CU8 para que se le considere en un estado compatible. . Somos más estrictos con nuestros requisitos híbridos debido a lo estrechamente que se acoplarán los entornos locales y Exchange Online. Para obtener más información sobre nuestras actualizaciones disponibles, vaya aquí.

Nuevo servidor híbrido versus Exchange local existente

En caso de que la infraestructura de Exchange de la organización se base en versiones anteriores de Exchange como Exchange 2003, 2007, necesitaremos “agregar” o instalar un nuevo servidor Exchange local (2010 SP3 o 2013) que servirá como “servidor híbrido”. . "

El “nuevo” servidor híbrido local de Exchange se puede implementar como Exchange 2010 o Exchange 2013, pero la mejor práctica es instalar el servidor Exchange 2013 en lugar de Exchange 2010 porque Exchange 2013 incluye funciones mejoradas relacionadas con el entorno híbrido.

2. Servidor híbrido local de Exchange | Dirección IP pública y nombre público (FQDN)

La configuración híbrida consiste en habilitar el servidor Exchange On-Premise que está configurado como "servidor híbrido" para crear un canal de comunicación con la infraestructura de Exchange Online que existe en una red pública.
Para poder comunicar hosts o "puntos finales" en En una red pública, el servidor Exchange Hybrid debe tener:

1. Nombre público: el nombre público del servidor híbrido de Exchange debe publicarse en el DNS público y debe resolverse en la IP pública del servidor híbrido de Exchange.
2. Dirección IP pública: se debe asignar una dirección IP pública que "apunte" al servidor híbrido de Exchange. La mayoría de las veces, la dirección IP pública no se conectará directamente al servidor local de Exchange, sino que se asignará a un servidor Firewall. El eFirewall aceptará las solicitudes de comunicación al servidor local de Exchange y reenviará la solicitud a la dirección IP interna del servidor local de Exchange.

Por ejemplo, en caso de que el flujo de correo saliente se base en dos servidores Exchange locales que puedan enviar correo al servidor Exchange Online, cada uno de estos servidores deberá tener una dirección IP pública dedicada.

¿Cómo puedo saber cuál es el nombre público del Exchange On-Premise?

La respuesta simple es que si usted es el administrador local de Exchange, se supone que debe saber cuál es el nombre público local de Exchange pero, en algunos escenarios, tendremos que configurar una implementación híbrida en un entorno con el que no estamos familiarizados. con.

Una opción para obtener información sobre el “Nombre público” del servidor Exchange On-Premise es mirar la “URL externa” que aparece en la sección “acceso de cliente” en la configuración del servidor en la MMC de Exchange (cuando usamos Exchange 2010 MMC). ).

En el siguiente ejemplo, buscaremos en “Configuración del servidor\Acceso del cliente\EX01“

El servidor Exchange "publica un" par de servicios. En nuestro ejemplo, observamos la pestaña ECP (la pestaña ECP incluye la URL interna + externa del servidor Exchange mediante la interfaz de administración web).

Podemos ver que el “nombre público” (URL Externa) del Exchange On-Premise es: mail.o365info.com

Verifique que el nombre público (FQDN) del servidor híbrido de Exchange esté asignado a su IP pública

El proceso de verificación de la IP pública local de Exchange es muy sencillo. Abra el símbolo del sistema y haga ping al nombre público del servidor local de Exchange. En nuestro ejemplo, el nombre público local de Exchange es: mail.o365info.com

En la siguiente captura de pantalla podemos ver que obtuvimos como “respuesta” la IP pública del servidor Exchange On-Premise.

Uno de los conceptos erróneos más comunes es que hay un problema porque recibimos una "Solicitud agotada".

Esta respuesta no es una señal de un problema porque se suponía que el host al que le hicimos "ping" (Exchange On-Premise en nuestro escenario) no debía responder a la solicitud de ping. Este es un resultado previsible porque la mayoría de las veces el Firewall de la organización bloquea el protocolo ICMP (el que se utiliza para la respuesta Ping).

En resumen: el hecho de que obtuvimos una respuesta de IP pública son los resultados requeridos, lo que significa que el servidor local de Exchange tiene un nombre público + dirección IP pública.

3. Servidor híbrido local de Exchange | Número de puerto y protocolos

Configuración híbrida basada en compartir datos y servicios entre Exchange Online y el servidor Exchange on-Premises. El canal de comunicación implementado mediante el uso de dos protocolos de comunicación:

• HTTPS: acceso a los servicios de Exchange (desde el servidor local de Exchange a Exchange Online y viceversa) implementado mediante el protocolo HTTPS.
• SMTP: el protocolo SMTP utilizado para implementar el flujo de correo y los datos se cifran mediante TLS (TLS sobre SMTP).

La suposición subyacente es que el servidor local de Exchange está protegido por un firewall. Para poder implementar el canal de comunicación entre el servidor Exchange on-Premises y Exchange Online con éxito, necesitaremos verificar que el Firewall incluya las siguientes reglas de entrada y salida:

1. La regla de entrada que permite acceder al servidor local de Exchange mediante el puerto 25 (SMTP) y 443 (HTTPS).
2. La regla de salida que permite que el servidor local de Exchange acceda a Exchange Online mediante el puerto 25 (SMTP) y 443 (HTTPS).

La siguiente captura de pantalla está tomada de un artículo de Microsoft e incluye una tabla que describe el número de puerto y los servicios que deben habilitarse para la configuración híbrida.

Verificar el acceso desde la red pública al servidor Exchange Hybrid

Para comprobar que se puede acceder a la regla requerida configurada en el Firewall de la organización y al servidor local de Exchange desde la red pública, podemos utilizar la opción de “escaneo en línea”. "

En el siguiente paso, usamos MxToolbox para verificar cuáles son los puertos disponibles en el servidor local de Exchange.

En nuestro escenario, el nombre del servidor local de Exchange es: mail.o365info.com

Para obtener todas las opciones disponibles, elegiremos el menú más y luego la opción escanear .

Proporcionaremos el nombre de host (o la dirección IP) del host que queremos escanear.

En la siguiente captura de pantalla, podemos ver que el resultado del escaneo muestra que el host mail.o365info.com está "escuchando" en el puerto: 25 y 443.

Verifique que el servidor Exchange Hybrid pueda acceder a la red externa utilizando los puertos requeridos.

Para poder verificar que el servidor local de Exchange tiene acceso a hosts públicos mediante el protocolo SMTP (Puerto 25) y puede inicializar una sesión TLS, podemos usar el comando Telnet desde el símbolo del sistema del servidor local de Exchange.

En el siguiente ejemplo, hacemos Telnet a un servidor de correo externo usando el puerto 25 (Telnet o365info2.mail.protection.outlook.com 25)

Podemos ver que el servidor de destino "responde" y obtenemos una respuesta de que el servidor de destino está listo.

Para iniciar la sesión SMTP\TLS, escribiremos el comando: helo, y después de obtener la "respuesta" del servidor de destino, podemos escribir el comando: <starttls

En la siguiente captura podemos ver que el servidor de correo de destino responde con el mensaje: “220 2.0.0 Servidor SMTP listo. "

Disponibilidad: publicar correctamente los servidores de acceso de cliente locales en Internet es vital para que las funciones funcionen correctamente en su implementación híbrida.

Para que las funciones híbridas funcionen correctamente, debe configurar su firewall local u otros dispositivos de seguridad para permitir el acceso entrante desde Internet a los puntos finales de Autodiscover y Exchange Web Services (EWS) en los servidores de acceso de cliente locales. Además, los servidores de acceso de cliente también deben configurarse para aceptar correo SMTP entrante.

Si el servicio Microsoft Exchange Online Protection (EOP) incluido en su organización de inquilinos de Office 365 no puede llegar a los servidores de acceso de cliente locales, el transporte seguro de correo desde la organización de Exchange Online a la organización local no funcionará correctamente

Leer más: Solucionar problemas de una implementación híbrida.

4. Servidor híbrido local de Exchange| Dirección IP pública y NAT estática

Un factor importante que debemos verificar es que el servidor local de Exchange esté utilizando la dirección IP pública que se le asignó cuando responde a una solicitud de comunicación de hosts externos o cuando inicializa una conexión a un host externo.

El término técnico para este escenario podría ser “NAT estática bidireccional”.

Por ejemplo: cuando utilizamos el asistente de configuración híbrida de Exchange 2010, debemos proporcionar la IP pública del servidor local de Exchange que está "permitido" para enviar un correo electrónico al servidor de Exchange Online.

Cuando el servidor local de Exchange se comunica con Exchange Online, es importante que el servidor local de Exchange utilice la IP pública configurada en el asistente híbrido de Exchange.

Otros ejemplos podrían ser cuando Exchange Online inicia un proceso de comunicación con la IP pública del servidor local de Exchange. En este caso, el servidor de Exchange Online está "esperando" una respuesta de la dirección IP que se utilizó para iniciar el canal de comunicación.

Un ejemplo de regla NAT estática podría ser:

En el siguiente diagrama podemos ver un ejemplo de regla NAT estática. Cuando los hosts externos, como Exchange Online, intentan comunicarse con la IP pública del servidor local de Exchange, la "respuesta" del servidor local de Exchange se implementa utilizando la misma dirección IP pública que utilizamos para "publicar" Exchange. Servidor local.

Verifique cuál es la dirección IP pública que utiliza el servidor local de Exchange

En caso de que queramos estar seguros de que el servidor Exchange on-Premises “responda” o acceda a la red externa usando la dirección IP pública que le fue asignada (para verificar que la regla NAT estática esté configurada correctamente), podemos usar un Servicio gratuito que ofrecen muchos sitios web, que nos permitirá obtener la IP pública que utilizan hosts internos específicos.

Todo lo que necesitamos es abrir una página de búsqueda del navegador desde el servidor local de Exchange y escribir: “cuál es mi IP”.

En la siguiente captura de pantalla, podemos ver “cuál es la IP pública” del servidor local de Exchange.

5. Servidor ISA-TMG y servidor Firewall

Cuando se utiliza el servidor ISA\TMG para publicar un servidor Exchange On-Premise, las configuraciones son un poco diferentes en comparación con un "Firewall estándar" porque ISA\TMG es un servidor Proxy y, además, un servidor Firewall.

Cuando utilizamos un "Firewall estándar", redirigimos la comunicación al servidor interno de Exchange On-Premise mediante una simple "regla de acceso".

Cuando se utiliza ISA\TMG Firewall, la redirección al servidor interno de Exchange On-Premise se implementa mediante una: regla de publicación web.

La regla de publicación web ISA\TMG se relaciona con una “ruta” local de Exchange preconfigurada o particular, como -OWA, EWS, un componente adicional que se utiliza en el entorno ISA\TMG es la configuración de autenticación.
Porque ISA\TMG TMG es un servidor proxy, muchas veces la configuración del proceso de autenticación se implementa de la siguiente manera: el host externo se autentica (proporciona su credencial) al ISA\TMG, el servidor ISA\TMG aprueba o desaprueba las credenciales y si el ISA se completa exitosamente \TMG “reenviará” la solicitud de comunicación de los hosts externos.

En el entorno híbrido, esta configuración causará problemas y errores. En palabras simples: cuando publicamos un servidor Exchange On-Premise usando el servidor ISA\TMG, necesitamos cancelar o deshabilitar la opción en la que el servidor ISA\TMG es la autenticación de la solicitud de comunicación del host externo.

1. ISA\TMG y configuración de autenticación

La comunicación entre Exchange Online y el servidor local de Exchange (y viceversa) se implementa mediante la creación de un canal de comunicación cifrado y permitiendo que cada una de las partes se autentique e identifique entre sí.

Necesitamos permitir que este “canal” exista sin ninguna interrupción o intervención.

El servidor ISA\TMG es un servidor proxy que a veces se configura para aplicar el proceso de autenticación para el punto final o el host que desea comunicarse con el "host interno". Cuando nos relacionamos con un entorno híbrido y con un escenario en el que ISA\TMG publica el servidor local de Exchange, debemos cancelar la configuración que obliga al punto final externo a "autenticarse en el servidor ISA\TMG".

Cuando utilizamos la regla ISA\TMG para publicar los servicios EWS y AutoDiscover del servidor local de Exchange, debemos verificar que la regla de publicación web TMG esté configurada con la configuración: Sin delegación, pero el cliente puede autenticarse directamente .

2. ISA\TMG | Intercambio en las instalaciones | Regla y ruta de publicación web

Cuando se utiliza ISA\TMG Firewall para publicar hosts internos como Exchange On-Premise, la “regla de acceso” se implementa mediante una regla de publicación web.
La regla de publicación web ISA\TMG incluye parámetros como: el nombre\IP de el host interno (Servidor Web) que queremos publicar y adicionalmente, una ruta particular del servidor web.

En un entorno híbrido, es importante verificar que la regla de publicación ISA incluya la siguiente ruta:
/ews/*

/detección automática/*

La regla de publicación web ISA\TMG debe configurarse para permitir el acceso a servicios web locales de Exchange adicionales, como OWA, Active Sync, etc.

Cuando se relaciona con el escenario de configuración híbrida, las carpetas virtuales relevantes que deben configurarse en las reglas ISA\TMG son las carpetas EWS y AutoDiscover.

En la siguiente captura de pantalla, podemos ver un ejemplo de la regla de publicación web ISA\TMG que incluye la "Ruta" requerida a los servicios locales de Exchange.

La siguiente captura de pantalla fue tomada de un artículo de Microsoft.

En la siguiente tabla podemos ver referencia de:

• Nombre de ruta que debe agregarse a la regla de publicación ISA\TMG
• Autenticación: la necesidad de deshabilitar o cancelar la función ISA\TMG que requiere
  Autenticación (y en su lugar, permitir que el cliente se autentique directamente ante el servidor local de Exchange)

6. Política de acceso entrante y saliente del firewall | Rango de IP públicas de Office 365 y Exchange Online

En muchas organizaciones, debido a una regulación u otros requisitos de seguridad, existe una implementación de políticas de entrada y salida que restringen el acceso solo a un rango de IP dedicado o predefinido.

Por ejemplo: cuando decimos: "El servidor local de Exchange está creando un canal de comunicación con Exchange Online", ¿qué significa desde el punto de vista del "rango de IP"?
¿La infraestructura de Exchange Online está representada por un ¿Rango de IP pública predefinido?
La respuesta a esta pregunta es: “Sí”.

Todo el entorno de Office 365, como Windows Azure Active Directory, Exchange Online, SharePoint Online, etc., basado en una "publicación" o un rango de IP público conocido.

La implementación de reglas de firewall entrantes y salientes que restrinjan el acceso solo a un rango de IP específico o predefinido se considera una “buena práctica” desde el punto de vista de la seguridad. Pero, al mismo tiempo, puede complicar e interrumpir el proceso de “configuración inicial” que utilizamos para construir el “canal de comunicación híbrido” entre Exchange On-Premise y el servidor Exchange Online.

Antes de comenzar a implementar un requisito organizacional específico para implementar políticas salientes/entrantes con un rango de IP restringido, mis recomendaciones son las siguientes:

1. PRUEBA\Fase Piloto

En caso de que solo esté en la fase de Prueba\Piloto, el objetivo principal es verificar que podemos utilizar exitosamente el HCW (Asistente de configuración híbrida) para establecer el canal de comunicación entre Exchange On-Premise y Exchange Online (y viceversa). ).

En esta fase, mi recomendación es no implementar la política saliente\entrante con un rango de IP restringido porque, en caso de que este rango no esté configurado correctamente, el asistente de configuración híbrida fallará y no es tan fácil encontrar la causa del fallo. .

Después de crear con éxito todas las configuraciones híbridas requeridas (mediante el HCW o el comando PowerShell) y verificar que la ruta de comunicación entre el servidor local de Exchange y Exchange Online esté "funcionando", puede implementar cualquier configuración saliente. \política entrante con un rango de IP restringido.

2. Conozca y familiarícese con la gama de IP públicas de Office 365.

No entraremos en muchos detalles sobre el tema de: “Rango de IP pública de Office 365”, pero es crucial comprender que el término “Office 365” es solo un término lógico que define un conjunto muy complicado de infraestructuras, servicios, Rangos de IP públicos, etc.

Mi recomendación es leer detenidamente la información sobre las diferentes infraestructuras de Office 365 y el rango de IP Pública dedicada que asigna Microsoft para cada una de las diferentes infraestructuras de Office 365 antes de comenzar con la creación de reglas de Firewall, rango de Red, etc.

3. La naturaleza dinámica de la gama de IP públicas

Office 365 es un entorno dinámico. La suposición básica es que, de vez en cuando, habrá actualizaciones relacionadas con el rango de IP pública de Office 365. Para poder mantenerse actualizado y recibir notificaciones sobre características o actualizaciones actuales relacionadas con los rangos de IP públicas de Office 365, puede leer las URL y los rangos de direcciones IP de Office 365.