Office 365 | Planificación de ancho de banda de internet

Hay muchos factores que intervienen en la migración hacia Office 365. Cada organización tiene experiencia y su diferencia se basa en la configuración de su correo actual. El entorno de Exchange existente tiene que estar en algún estándar o cumplir con algunos criterios antes de empezar a moverse a Office 365.  A continuación, se detallan algunos pasos previos antes de realizar cualquier tipo de implementación de Office 365.

Estimando uso de ancho de banda

Hay varias variables que debemos considerar cuando estimamos el tráfico de la red. Algunas de éstas son:

  • Ofertas de Servicio que la organización está suscrito al Servicio de Office 365.
  • Cantidad de estaciones de trabajo conectadas al mismo tiempo.
  • El tipo de tarea de cada equipo cliente se está
  • El rendimiento del software del navegador de Internet.
  • La capacidad de las conexiones de red y segmentos de red asociados a cada equipo cliente.
  • Topología de red de la organización y la capacidad de los distintos elementos de hardware de red.

Calculadoras de ancho de banda que debe utilizar para Office 365

Hay calculadoras disponibles que ayudan con la estimación de los requerimientos de ancho de banda de la red. Estas calculadoras trabajan en las instalaciones, así como despliegues de Office 365. Se puede utilizar la calculadora de ancho de banda de red de cliente de Exchange para estimar el ancho de banda requerido para un conjunto específico de Outlook, Outlook Web App, y los usuarios de dispositivos móviles para la implementación de Office 365. Con la calculadora de 2010 y 2013 de ancho de banda de Skype for Business Server, se introduce la información sobre los usuarios y el Skype for Business Online las prestaciones que desea implementar, dicha calculadora le ayuda a determinar los requisitos de ancho de banda.

  • Exchange Client Network Bandwidth Calculator
  • Lync 2010 and 2013 Bandwidth Calculator
  • OneDrive for Business Synchronization Calculator

Prueba de velocidad de migración

Las pruebas y la validación del ancho de banda de Internet (descarga, carga, y las limitaciones de latencia) son vitales para la comprensión de cómo lograr la migración de alta velocidad de contenido de buzones de correos locales a Office 365 y ambientes de Exchange Online. La conectividad lenta o latente, reduce el número de migraciones de buzones que se pueden realizar durante una ventana de la migración. Asegúrese de realizar los siguientes pasos:

  • Prueba y confirmación que el ancho de banda de Internet de la organización puede gestionar el impacto de red         en migraciones de Office 365
  • Evaluar la disponibilidad de ancho de banda de red interna para eventos de migración de Office 365.
  • Hacer uso de herramientas de red disponibles, tales como:

– Microsoft Network Monitor – Permite capturar el tráfico de red, verlo y analizarlo. Buscar HTTPS/ SSL, tiempos de espera ajustados, muy bajo en Proxy / Firewall / Router y transmisiones excesivas.

– Microsoft Remote Connectivity Analyzer – Chequea la conectividad del ambiente de Exchange Online.

– Office 365 Network Analysis Tool – Ayuda a analizar los problemas relacionados con la red antes de la implementación de servicios de Office 365: Norteamérica: http://na1-fasttrack.cloudapp.net / EMEA: http://em1-fasttrack.cloudapp.net / APAC: http://ap1-fasttrack.cloudapp.net

– Determinar su carga, descarga y latencia entre su control local y el centro de datos de servicios cloud Microsoft más cercano. Las siguientes actividades pueden ayudar en esta tarea: Ping a outlook.com para determinar la dirección IP del centro más cercano a Microsoft datos de los servicios en la nube desde su ubicación. / Consulte a un sitio web de mapas IP de terceros (por ejemplo, iplocation.net) para determinar la ubicación de ese centro de datos. / Use un sitio web prueba de velocidad (por ejemplo speedtest.net) para determinar la carga, descarga y las estadísticas de la latencia entre su entorno local y la ubicación más cercana al centro de datos de servicios cloud Microsoft. / Determinar los períodos en los que el sistema local de Exchange se utiliza en gran medida (por ejemplo, durante las copias de seguridad).

Estrategias para mejorar la velocidad de migración

Para mejorar la velocidad de migración, así como reducir las limitaciones de ancho de banda de su organización, se debe considerar lo siguiente:

  • Reducir el tamaño de los buzones. Mientras más pequeño sea el tamaño del buzón, aumenta la mejora de la               velocidad de migración.
  • Limpieza de carpetas públicas – asegúrese de la limpieza de su público para cumplir con el buzón de                          carpetas públicas en Office 365.
  • Utilice la capacidad de movimiento de buzones con una implementación híbrida de Exchange. Con una                      implementación híbrida de Exchange, el correo sin conexión (.ost) no requiere volver a descargar al migrar a              Exchange Online. Esto reduce significativamente los requisitos de ancho de banda de descarga.
  • Horario del buzón, se mueve al ocurrir períodos de tráfico de Internet y una baja utilización de Exchange                    local. Al programar movimientos, entender que las solicitudes de migración son enviadas al proxy de                          replicación de buzón y pueden no tener lugar inmediatamente.

Para más detalles respecto a la migración, revisar el siguiente link http://go.microsoft.com/fwlink/?LinkId=393510

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Microsoft Advance Threat Analytics

Microsoft Advance Threat Analytics (ATA) es una herramienta enfocada a la seguridad de la plataforma de Active Directory para detectar en tiempo real amenazas, y acciones sospechosas sobre el dominio.

¿Qué es ATA?

Microsoft ATA es una plataforma de seguridad para Active Directory con el fin de detectar amenazas. ATA toma información de los eventos y registros de la red con el fin de aprender comportamiento de los usuarios u otras entidades creando un perfil de comportamiento.

ATA aprovecha un motor de análisis sobre la red para capturar y analizar el tráfico de red de diversos protocolos (Kerberos, DNS, NTLM entre otros), ATA obtiene información de las siguientes maneras:

  • Creación de reflejos de puertos en los DC y servidores de DNS directos hacia la puerta de enlace de ATA.
  • Implementación de ATA Light Gateway (LGW) en los DC.

ATA nos permite detectar actividades sospechosas centrándose en:

  • Reconocimiento
  • Desplazamiento lateral
  • Dominio del dominio (persistencia)

Ademas de actividades sospechosas, ATA permite detectar ataques malintencionados como cuales:

  • Pass-the-Ticket (PtT)
  • Pass-the-Hash (PtH)
  • Overpass-the-Hash
  • PAC falsificado (MS14-068)
  • Golden ticket
  • Replicaciones malintencionadas
  • Reconocimiento
  • Fuerza bruta
  • Ejecución remota

Arquitectura de ATA

ATA analiza el tráfico de red de los controladores de dominio mediante el uso de la creación de reflejo de puerto a una puerta de enlace de ATA con conmutadores físicos o virtuales, o implementando la puerta de enlace ligera de ATA directamente en los controladores de dominio. ATA puede sacar provecho de los eventos de Windows (reenviados directamente desde los controladores de dominio o desde un servidor SIEM) y analizar los datos en busca de amenazas y ataques.

1

Arquitectura de ATA

El siguiente diagrama muestra el flujo de red, captura de eventos y explorar en profundidad para la funcionalidad de los componentes de ATA.

2

Componentes de ATA

  • El ATA Center recibe datos de cualquier puerta de enlace de ATA o puerta de enlace ligera de ATA que implemente.
  • El ATA Gateway se instala en un servidor dedicado que supervisa el tráfico de los controladores de dominio mediante la creación de reflejo del puerto o un TAP de red.
  • La ATA Light Gateway se instala directamente en los controladores de dominio y supervisa el tráfico directamente, sin necesidad de un servidor dedicado ni de una configuración de creación de reflejo del puerto. Es una alternativa a la puerta de enlace de ATA.

ATA Center

El ATA Center cumple la función de administras la configuración de los Gateway de ATA, recibir datos desde los ATA Gateway, detectar actividades sospechosas, ejecutar algoritmos de aprendizajes de comportamiento. El ATA Center recibe el tráfico analizado por el ATA Gateway y la ATA Light Gateway, genera perfiles, lleva a cabo una detección determinista y ejecuta el aprendizaje automático.

ATA Gateway y ATA Light Gateway

El ATA Gateway cumple la función de captura y análisis del tráfico de red en los controladores de dominio, recibir eventos de servidores de Syslog o SIEM, recuperar datos sobre usuarios y dispositivos del dominio, realizar tareas de resolución de objetos y transferir los análisis hacia el ATA Center.

ATA es una herramienta la cual llegó para dar fin a la problemática de seguridad especial para Active Directory, considerando la importancia de esta solución (AD) y que es esencial para el resto de las soluciones Microsoft mantener un control sobre AD era una tarea difícil, con la implementación de ATA en su plataforma, podrá mantener control sobre cualquier tipo de ataque, actividades sospechosas e incluso comunicación entre servidores y AD.

Ernesto León, Consultor Infraestructura, Blue Solutions.

 

Arquitectura Ideal de Exchange 2013 (PA)

Simplicidad

Las fallas ocurren. No hay tecnología que pueda cambiar eso. Discos, servidores, racks, redes, generadores, sistemas operáticos, aplicaciones (como Exchange), drivers, y otros servicios, simplemente no existe un servicio entregado por IT que no esté sujeto a fallos.

Una manera de mitigar las fallas es con una infraestructura redundante. Donde una entidad que falla, siempre tendrá una o más entidades para utilizar en su lugar. Esto se puede observar en los Web Server Array, disk array, y similares. Pero la redundancia puede ser costosa, por ejemplo, el costo y la complejidad del sistema de almacenamiento basado en SAN que estaba en el corazón de Exchange hasta la versión 2007, condujeron al equipo de Exchange en aumentar la inversión en almacenamiento para su arquitectura. Nos dimos cuenta de que cada sistema de SAN en última instancia, falla, y que la implementación de un sistema altamente redundante utilizando la tecnología SAN sería un costo muy alto. En respuesta a esto, Exchange a evolucionado de una exigencia costosa de alto rendimiento en almacenamiento SAN y periféricos relacionados, para ahora ser capaz de correr en servidores más baratos con los productos básicos SAS/SATA. Esta arquitectura permite a Exchange ser resistente a fallos relacionados con el almacenamiento permitiendo almacenar buzones de gran tamaño a un costo razonable. Con la construcción de la arquitectura de replicación y optimización de Exchange en almacenamiento, los fallos en temas de almacenamiento son prescindibles. Esta arquitectura no se detiene en la capa de almacenamiento, NIC redundantes, fuentes de poder, etc. Si se trata de un disco, controlador o placa base que falla, el resultado final debe ser el mismo, otra copia de base de datos se activa y se hace cargo. Cuanto más complejo sea el hardware o software de la arquitectura, los errores de hardware ya no se vuelven una prioridad. Ejemplos de redundancia complejos son pares activos/pasivos de red, puntos de agregación de la red con configuraciones complejas de enrutamiento, la colaboración de red, RAID, múltiples vías de fibra, etc. La eliminación de redundancia compleja no parece algo creíble, pero puede lograrse a través de una redundancia basada en Software. La Arquitectura preferida (PA) elimina la complejidad y redundancia cuando sea necesario para impulsar la arquitectura a un modelo de recuperación predecible: cuando se produce un fallo, se activa otra copia de la base de datos afectada.El PA se divide en cuatro áreas de interés:

  • Diseño de espacios de nombres
  • Diseño de datacenter
  • Diseño del servidor
  • Diseño del DAG

Namespace

Desde una perspectiva de espacio de nombres las opciones son, o bien implementar un espacio de nombres con destino preferido (que tiene una preferencia por los usuarios para operar fuera de un centro de datos específico) o un espacio de nombres no unida (que tienen los usuarios se conectan a cualquier centro de datos sin preferencia). El método recomendado es utilizar el modelo no unido, el despliegue de un único espacio de nombres según el protocolo de cliente para el par de estaciones tolerantes del datacenter (donde se supone que cada datacenter  para representar su propio sitio de Active Directory). Por ejemplo:

  • Autodiscover.dominio.com
  • Para clientes http: mail.dominio.com
  • Para clientes IMAP: imap.dominio.com
  • Para clientes SMTP: smtp.dominio.com

Cada espacio de nombre debe estar balanceado entre todos los datacenter en una configuración que no aprovecha la afinidad de sesión, lo que resulta en un cincuenta por ciento del tráfico se distribuye entre los datacenter. El tráfico se distribuye por igual entre los datacenter via DN round-robin, geo-DNS, o soluciones similares. Aunque desde nuestro punto de vista, la solución más simple es la menos complejo y más fácil de manejar, por lo que nuestra recomendación es aprovechar el DNS round-robin. En el caso de que usted tiene sitios múltiples de datacenter flexibles en su entorno, tendrá que decidir si quiere tener un único espacio de nombres en todo el mundo, o si desea controlar el tráfico a cada datacenter específico mediante el uso de espacios de nombres regionales. En última instancia su decisión depende de la topología de red y el costo asociado con el uso de un modelo no unido; por ejemplo, si usted tiene un datacenter ubicados en América del Sur y Europa, el enlace de red entre estas regiones podría no sólo ser costoso, si no también podría tener una alta latencia, que puede presentar dolor de cabeza para el usuario y las cuestiones operativas. En ese caso, tiene sentido para implementar un modelo enlazado con un espacio de nombres separado para cada región.

Diseño de Servidores

En la PA, todos los servidores son multi-rol y físicos. Se prefiere hardware físico por dos razones:

  • Los servidores se escalan para utilizar el 80% de los recursos en el peor de los casos.
  • La virtualización añade una capa adicional de administración y recuperación que no añaden valor a Exchange.

Mediante el despliegue de servidores multi-rol, la arquitectura se simplifica ya que todos los servidores tienen el mismo hardware, proceso de instalación y las opciones de configuración. Consistencia a través de servidores también simplifica la administración. servidores multi-rol proporcionan un uso más eficiente de los recursos del servidor mediante la distribución del CAS y los recursos del Mailbox a través de un mayor número de servidores. CAS y DAG son más resistente a fallas, ya que hay más servidores disponibles para el equilibrio de carga del CAS y para el DAG.

1

Figura 1: Diseño de servidores

Diseño DAG

Para cada sitio será necesario tener como mínimo un DAG.

Configuración del DAG

Al igual que con el namespace design, cada DAG dentro del sitio del datacenter opera en un modelo no unido con copias activas distribuidas por igual entre todos los servidores en el DAG. Este modelo ofrece dos ventajas:

  • Se asegura de que cada servicio de la base de datos se encuentre valida (conectividad con cliente, replicación, transporte, etc).
  • distribuye la carga a través de tantos servidores como sea posible durante un escenario de error, lo que aumenta de forma incremental solamente la utilización de recursos a través de los miembros restantes dentro del DAG.

Cada datacenter es simétrico, con igual número de servidores miembro dentro de un DAG que reside en cada datacenter. Esto significa que cada DAG contiene un número par de servidores y utiliza un servidor testigo de arbitraje quórum.

El DAG es el bloque de construcción fundamental en Exchange 2013. Con respecto al tamaño de DAG, un DAG más grande proporciona más redundancia y recursos. Dentro de la PA, el objetivo es el despliegue de los DAG con alta capacidad.

DAG Network

Desde la introducción de la replicación continua en Exchange 2007, Exchange ha recomendado tener múltiples redes de replicación, para separar el tráfico del cliente de tráfico de replicación. La implementación de dos redes le permite aislar ciertos niveles de tráfico a lo largo de las diferentes vías de la red y asegurarse de que, en determinados eventos la interfaz de red no este saturada. Sin embargo, para la mayoría de los clientes, que tiene dos redes que funcionan de esta manera era sólo una separación lógica, ya que el mismo tejido de cobre fue utilizado por ambas redes en la arquitectura de red subyacente.

Witness Server (Servidor de Testigo)

La utilización de un servidor de testigo determina si la arquitectura puede proporcionar capacidades de activación automática por datacenter en caso de fallas, o si se requerirá activación manual para subir el servicio. Si su organización tiene una tercera ubicación con una infraestructura de red que está aislado de los fallos de red que afectan el sitio del centro de datos par resistente en el que se despliega el DAG, entonces la recomendación es implementar servidor testigo del DAG en ese tercer lugar. Esta configuración ofrece la DAG la capacidad de resistencia a fallas y activación de copia pasiva en otro datacenter.

2

Figura 2: DAG (Esquema de 3 datacenter)

El PA se aprovecha de los cambios realizados en Exchange 2013 para simplificar la implementación de Exchange, sin disminuir la disponibilidad o la elasticidad del despliegue. Y en algunos casos, en comparación con las generaciones anteriores, la PA aumenta la disponibilidad y capacidad de recuperación de su implementación.

Ernesto León, Consultor Infraestructura, Blue Solutions.

¿Podemos manejar archivos con doble espacio, ñ y/o caracteres especiales?

La buena noticia es que sí!, es posible, y no representa un gran problema si hablamos únicamente de Sharepoint, la documentación no detalla nada que hiciera sospechar que pueda ser un inconveniente. Sin embargo, les presento un incidente que se nos presentó en un cliente en el cual este punto fue justamente el centro del problema.

Posterior a la migración desde Sharepoint 2010 a 2013, toda la instalación y migración fue hecha siguiendo las mejores prácticas y sin problemas significativos. El proyecto fue considerado un éxito.

Sin embargo, en la etapa de QA, poco tiempo antes de la puesta en producción y finalizando las últimas pruebas, se hizo presente un problema que afectaba a los usuarios de forma aleatoria. En la librería documental, los archivos con símbolos especiales, ñ o dobles espacios generaban el siguiente error:

  1

Después de un poco de troubleshooting llegamos a la conclusión de que el problema no se presentaba de manera aleatoria, el problema se presenta únicamente cuando los archivos son accedidos desde afuera de la red corporativa.

Dado lo anterior, el primer elemento a examinar, fue el dispositivo encargado de la publicación hacia la red externa, en este caso un Microsoft TMG. Después de la revisión se determinó que efectivamente el filtrado HTTP estaba bloqueando el acceso a URL con ciertas características.

Solución

Para dar solución a nuestro problema accedimos a las propiedades de las directivas de Firewall, después a la ficha de tráfico e hicimos click en Filtering > Configurar HTTP.

2

En la configuración HTTP deshabilitamos la opción “Block high bit characters”. Al aplicar este cambio inmediatamente se permitió acceso a los archivos que anteriormente presentaban problemas.

3

Los filtros aplicados por el TMG en los protocolos HTTP por defecto deniegan el acceso a archivos con caracteres especiales. Si bien este tipo de bloqueos es recomendable (por lo mismo es la configuración por defecto) en ciertas situaciones es necesario reconfigurar para cumplir las necesidades del negocio.

Es importante que la información presentada no es la solución definitiva para los problemas de publicación, sin embargo, recomendamos que los dispositivos utilizados para la publicación de herramientas complejas como Sharepoint sean considerados frente a posibles problemas en el funcionamiento.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.