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. 

 

Big Data y la inteligencia de negocio es lo que está generando valor a la empresa

Big Data es el término que se emplea hoy en día para describir el conjunto de procesos, tecnologías y modelos de negocio que están basados en datos y en capturar el valor que los propios datos encierran. Esto se puede lograr a través de una mejora en la eficiencia gracias al análisis de los datos (una visión más tradicional), y además, mediante la aparición de nuevos modelos de negocio que supongan un motor de crecimiento.

Esta tecnología ha tenido un impacto considerable a nivel mundial, aumentando su interés de forma explosiva en los últimos años. El siguiente gráfico muestra el interés de búsqueda en Google que ha tenido el término “Big Data”.

1

Al mismo, tiempo podemos ver la cobertura a nivel mundial que ha alcanzado esta solución, en países como India, Singapur, Hong Kong, Coreo del sur y Taiwan, éstos son los mas interesados sobre esta nueva metodología de obtención, análisis y gestión de datos, es que Big Data más allá de ser una “potente base de datos” es una herramienta que fortalece el núcleo de cualquier negocio generando valor y entregando información real respecto a cuáles son mis productos con mayor preferencia en el mercado, o proyecciones en área de ventas en base al análisis del comportamiento en sus clientes.

2

Es importante entender que, Big Data ya no es una promesa ni una tendencia. Big Data está aquí y está provocando cambios profundos en diversas industrias. Desde el punto de vista tecnológico ya existen sectores empresariales que han adoptado de forma masiva proyectos y productos. El análisis de todos los datos e información en grandes volúmenes, de diversas fuentes, a gran velocidad y con una flexibilidad sin precedentes, puede suponer un factor diferencial para aquellos que decidan adoptarlo.

Ha sido tan disruptiva esta nueva metodología para la obtención y análisis de datos, que desde el año 2012 se han generado modelos de negocio que utilizan la información como base para generar sus estrategias ya sea, competitivas de relacionamiento y marketing.

Dentro de los procesos para el análisis y obtención de información, se destaca el Marketing impulsado por los clientes, mostrando y ofreciendo promociones personalizadas basándose en las pautas de compras individuales, al mismo tiempo, se aplica un análisis de marketing para la optimización de precios, evaluando la sensibilidad de la demanda a los precios mejorando el ciclo de vida del producto.

Ya está claro que las empresas están cambiando su forma de pensar con respecto al uso, recolección y análisis de datos. Se están aplicando procesos de conversión para crear datos estructurados a partir tweets y mensajes en las redes sociales, transformándolos en información pertinente a las áreas de negocio y otorgándole protagonismo en la toma de decisiones.

3

Poco a poco, las empresas se están familiarizando con los datos de gran volumen, sin embargo, pocos están tomando ventaja de las oportunidades que se generan. Una de las principales razones para esto, es el hecho de que la mayoría de las organizaciones no tienen mucha experiencia en el análisis de datos para ayudar en la toma de decisiones estratégicas. Por otra parte, las empresas tienden a invertir en proyectos de grandes volúmenes de datos diseñadas para resolver un problema de negocio específico, pero no incorporan el análisis de datos como parte de una estrategia más amplia y generalizada internamente.

Como consejo a los proveedores de TI, se les recomienda centrar en el estudio de casos que demuestran claramente los beneficios de grandes volúmenes de datos y análisis a sus potenciales clientes. Las empresas deben ser conscientes de que los grandes datos y análisis serán útiles para identificar quiénes son sus clientes y cuáles son sus hábitos de compra, lo que permite segmentar de acuerdo con sus perfiles y establecer las mejores formas de interactuar con ellos, con el objetivo de mejorar la personalización de las ofertas de acuerdo sus preferencias.

En conclusión, el análisis de datos y el procesamiento de dato no estructurado está permitiendo tener mayor cercanía con nuestros clientes, permitiendo entender mejor sus gustos y necesidades. Es un hecho que la correcta obtención y el debido análisis de datos generará un valor único a las empresas que les permitirá desarrollar estrategias dinámicas y evolutivas. Es importante entender que Big Data no sólo debe mirarse desde su envergadura tecnológica, la cual no deja de ser impresionante, sino que en realidad se debe explotar por el área administración en las empresas para definir planes de acción y estrategias frente al mercado, clientes y competidores.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

Recomendaciones para base de datos para SCCM

La implementación de System Center Configuration Manager requiere de un servidor de base de
datos SQL Server y existen recomendaciones para esta implementación, que presentaré las más relevantes.

Servidor dedicado

SCCM es una plataforma que almacena absolutamente todo en base de datos e incluso realiza transacciones sin darnos cuenta. Hay que pensar, que en todo momento se están recibiendo inventarios e información de distribución de paquetes. Aparte, hay que tener que es una herramienta asíncrona y mantiene su propia cola de procesos y transacciones con la base de datos.
Es por eso que siempre tiene muchas conexiones abiertas hacia la base de datos.

Particiones de disco

Como todo servidor de base de datos, la configuración de los discos es vital. Es muy importante que sistema operativo, datos, logs, tempdb y respaldo queden en discos distintos. Incluso, si son máquinas virtuales, los discos virtuales deberían estar en discos físicos distintos. Si se crean los discos duros virtuales en el mismo disco o LUN, las operaciones de las bases de datos harán uso de los recursos de un único disco, impactando el rendimiento.

Collation

El collation de una base de datos SQL Server es cómo el sistema interpreta cada uno de los caracteres que se almacena en la base de datos. SCCM requiere del collationSQL_Latin1_General_CP1_CI_AS. No funciona con otro más.

Cuentas

Al momento de instalar el servidor de base de datos, es altamente recomendado configurar una contraseña para la cuenta SA. Esto facilitará la resolución en caso de problemas. Es recomendado, también, configurar las cuentas de servicio como cuentas de dominio.

Puertos

SCCM no soporta puertos dinámicos de SQL Server. Así que cuando instales una instancia para SCCM, asegúrate que el servicio esté escuchando por el puerto 1433.
Mucho cuidado con las instancias nombradas, ya que tienden a configurarse como puertos dinámicos.

64 bits siempre

La arquitectura de 32 bits no está soportada por la plataforma. Siempre se debe usar SQL Server x64 para que SCCM pueda reconocerlo como un servidor de base de datos compatible. En el caso que no sea así, el programa de instalación dará un mensaje de error de incompatibilidad, aun cuando la versión de SQL Server sea soportada.

Uso de memoria

Siempre establece un mínimo y un máximo de memoria para la instancia. Recuerda que un servidor de base de datos es como un sistema operativo, por lo tanto, el uso de memoria es crítico. Como recomendación, siempre dejar un 10% para procesos propios del sistema operativos. Con esto evitas que la instancia utilice el 100% de la memoria y el servidor se quede sin recursos.

Respaldos

La misma plataforma de SCCM incluye una tarea de mantenimiento del sitio completo, inclusive de la base de datos. Para que en el caso de recuperación ante un desastre, desde el programa de restauración del sitio, se restaure la base de datos. No está recomendado restaurar la base de datos de forma manual. La tarea de respaldo de SCCM debe ser habilitada.

1

Monitoreo

Como todo servidor de base de datos, está altamente recomendado contar con una solución de monitoreo de servicios para tener conocimiento del estado real de salud del servicio y del servidor y prevenir cuellos de botella e indisponibilidad del servicio.

CPU

Recomendación obvia, pero de todas maneras hay que mencionarla. Para una implementación de este estilo, mínimo 4 CPU si es una máquina virtual. Con esto se evita cuello de botella en el servidor.

Con estas recomendaciones, tendrás un servidor cercano a las mejores prácticas de funcionamiento e implementación y esto se traduce en un mejor rendimiento de la plataforma de SCCM.

Maximiliano Marín, Consultor Infraestructura, Blue Solutions.

Activar Instancia de Administración Central de SharePoint 2013 con PowerShell

En las instalaciones de SharePoint de tres niveles o Roles separados es necesario determinar cuáles y cuantos de los servidores de Aplicación tendrán iniciada la instancia para la administración central. Para esto es necesario ejecutar la siguiente línea de comandos para

Primero use el siguiente comando para obtener la lista de instancias de administración central.

  • Get-SPServiceInstance | Where-Object {$_.TypeName -eq ´Administración central

Luego seleccione la instancia que desea dejar Online con el siguiente comando

  • Get-SPServiceInstance | Where-Object {$_.Id -eq ´[GUID]´} | Stop-SPServiceInstance

Finalmente configure la instancia en modo Online para

  • Get-SPServiceInstance | Where-Object {$_.Id -eq ´[GUID]´} | Start-SPServiceInstance

Para aplicar los cambios ejecute “iisreset” después del último comando.

1

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

Crear cuentas de usuario con PowerShell de Office 365

Al crear cuentas de usuario en PowerShell con Office 365, se requieren determinadas propiedades de la cuenta. Hay propiedades no son necesarias para crear la cuenta, pero aun así son importantes. Éstas se describen en la tabla siguiente:

Nombre de la propiedad del usuario

¿Obligatorio?

Descripción

DisplayName

Este es el nombre para mostrar que se usa en servicios de Office 365. Por ejemplo, Jhon Ruiz.
UserPrincipalName

Este es el nombre de cuenta que se usa para iniciar sesión en servicios de Office 365. Por ejemplo, JRuiz@demola.onmicrosoft.com.
FirstName

No

LastName

No

LicenseAssignment

No

Este es el plan de licencias (también conocido como plan de Office 365 o SKU) desde el que se asigna una licencia disponible a la cuenta de usuario. La licencia define los servicios de Office 365 que están disponibles para la cuenta. No tiene que asignar una licencia a un usuario al crear la cuenta, pero la cuenta requiere una licencia para tener acceso a los servicios de Office 365. Dispone de 30 días para conceder una licencia a la cuenta de usuario después de crearla.

Use el cmdlet Get-MsolAccountSku para ver los planes de licencias (AccountSkuId) y las licencias disponibles en la organización.

Password No Si no especifica una contraseña, se asignará una contraseña aleatoria a la cuenta de usuario y la contraseña será visible en los resultados del comando. Si especifica una contraseña, debe cumplir los siguientes requisitos de complejidad:

•         De 8 a 16 caracteres de texto ASCII.

•         Caracteres de tres de los tipos siguientes: letras minúsculas, letras mayúsculas, números y símbolos.

UsageLocation No Se trata de un código de país válido ISO 3166-1 alpha-2. Por ejemplo, US para Estados Unidos y FR para Francia. Es importante proporcionar este valor, ya que algunos servicios de Office 365 no están disponibles en determinados países, por lo que no se puede asignar una licencia a una cuenta de usuario a menos que la cuenta tenga este valor configurado.

Creación de una sola cuenta

Para crear una cuenta individual, debemos utilizar el siguiente comando y ejecutarlo en el WAAD Powershell:

[PS>]New-MsolUser -DisplayName <DisplayName> -FirstName <FirstName> -LastName <LastName> -UserPrincipalName <Account> -UsageLocation <CountryCode> -LicenseAssignment <AccountSkuID> [-Password <Password>]

Creación de varias cuentas de usuario

Para crear varias cuentas, debemos utilizar el siguiente comando y ejecutarlo en el WAAD Powershell:

  1. Cree un archivo de valores separados por comas (CSV) que contenga la información necesaria de la cuenta de usuario:
    1. UserPrincipalName
    2. FirstName
    3. LastName
    4. DisplayName
    5. UsageLocation
    6. AccountSkuId
  2. Utilizar luego el siguiente comando:  [PS>]Import-Csv -Path <InputCSVFile> | foreach {New-MsolUser -DisplayName $_.DisplayName -FirstName $_.FirstName -LastName $_.LastName -UserPrincipalName $_.UserPrincipalName -UsageLocation $_.UsageLocation -LicenseAssignment $_.AccountSkuId [-Password $_.Password]} | Export-Csv -Path <OutputCSVFile>
  3. Revise el archivo de salida para ver los resultados. No se han especificado las contraseñas, por lo que las contraseñas aleatorias que se generaron son visibles en el archivo de salida.

 

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Introducción a Planner

Office 365 Planner ofrece a la gente una manera sencilla y muy visual para organizar el trabajo en equipo. Planner hace que sea fácil para su equipo crear nuevos planes, organizar y asignar tareas, compartir archivos, chat acerca de lo que está trabajando, y obtener actualizaciones sobre el progreso. Planner puede utilizarse para gestionar un evento de marketing, nuevas ideas de productos, seguimiento de un proyecto del colegio, prepararse para una visita al cliente, o simplemente organizar su equipo de manera más eficaz.

Equipo de trabajo organizado

Uno de los aspectos más valiosos de Planner, es que ayuda a los equipos a organizar su trabajo visual. Cada plan tiene su propia tabla, y dentro de cada tabla, cada elemento de trabajo o tarea está representada por una tarjeta que puede tener fechas de vencimiento, los accesorios, las categorías y las conversaciones asociadas con ella. Los miembros del equipo reciben una notificación por correo electrónico cada vez que se les asigna una nueva tarjeta o añadirse a una conversación.

Cada tarjeta puede tener documentos (o imágenes) adjuntos que llegan de forma automática, vistas previas de imágenes, por lo que es fácil de entender la tarjeta de un solo vistazo. Además, éstas se pueden organizar en la Junta en columnas personalizadas llamadas Cubos, que pueden ser priorizadas y etiquetadas de colores.

Trabaja muy bien con todos los productos de Office 365

Como parte de Office 365, Planner está integrado con otros servicios de Office 365, grupos de Office 365, todas las conversaciones en Planner están disponibles en Outlook 2016, Outlook en la Web y las aplicaciones móviles de Outlook.

Planner es también una forma ideal para organizar sus archivos de Office (ofimática). Adjuntar los documentos de Word, Excel y PowerPoint en una tarjeta y comenzar la edición de forma inmediata. Cuando un documento se adjunta a una tarjeta, se almacena en una biblioteca de documentos de SharePoint en línea, que le permite trabajar en ellos de forma Off Line.

¡Ya se encuentra disponible!

Oficina 365 Planner estará disponible en la vista previa de Office 365 (portal nuevo). EL primer lanzamiento será a partir del próximo trimestre, por lo que deben mantener de forma constante una revision en el nuevo portal de Office 365 chequeando que ya este cargado en sus Tenants.

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Exchange 2013 Rol de Client Access Server

Vamos a partir hablando del Rol de Exchange. Si bien éste comparte el mismo nombre que en las dos últimas versiones de Exchange, es totalmente diferente. En Exchange 2007, el rol de Client Access Server proporciona autenticación, proxy/redirección y llevar a cabo la presentación de datos para los protocolos de internet hacia los clientes (Outlook Web App, EAS, EWS, IMAP y POP). En el caso de Exchange 2010, la presentación del protocolo MAPI fue movida hacia el rol de Client Access Server.

En Exchange 2013, el rol de Client Access Server (CAS) no realiza presentación de funcionalidad de datos. El rol de CAS ahora solo realiza la autenticación y Proxy, dando apoyo a los protocolos de internet hacia los clientes, transporte y mensajería unificada. Como resultado del cambio en la arquitectura, el rol de CAS no tiene estado (desde la perspectiva de sesión de protocolo, los datos que se pueden utilizar en la solución de problemas o se genera un análisis de tendencias de registro, de forma natural).

Afinidad de sesión

Exchange 2013 ya no requiere la afinidad de sesiones en el equilibrador de carga. Para entender mejor esto, tenemos que ver cómo funciona el rol de CAS en Exchange 2013. Desde la perspectiva de los protocolos ocurre lo siguiente:

  1. Un cliente resuelve mediante el nombre asignado para la IP virtual del balanceador.
  2. El balanceador de carga asigna la sesión a un miembro de CAS en el pool del balanceador.
  3. CAS realiza la autenticación y realiza una consulta hacia Active Directory para obtener la siguiente información:  a) Versión del buzón          b)Ubicación del buzón
  4. CAS realiza una decisión sobre si debe redirigir la solicitud a otra infraestructura de CAS dentro del bosque o realizar un proxy con la conexión hacia el Mailbox.
  5. CAS realiza una consulta a una instancia de administración de activos para determinar en qué servidor de mailbox se encuentra la copia activa de la base de datos para el buzón solicitado.
  6. CAS realiza un proxy de la solicitud al servidor que hospeda la copia activa del buzón.

El protocolo utilizado en el paso 6 depende del protocolo usado para conectar los servidores de CAS. Si el cliente utiliza el protocolo HTTP, entonces el protocolo utilizado entre el CAS y el servidor de Mailbox será HTTP (protegido vía SSL utilizando un certificado autofirmado).

Si el protocolo utilizado por el cliente es IMAP o POP, entonces el protocolo utilizado entre el servidor de CAS y Mailbox será IMAP o POP. Las solicitudes telefónicas, sin embargo, son únicas. En lugar de enviar la solicitud en el paso 6, CAS volverá a dirigir la petición al servidor de buzones que hospeda la copia activa de la base de datos del usuario, como el dispositivo telefónico utilizado necesita establecer sus sesiones por SIP y RTP, se establece la comunicación directamente con los componentes de mensajería unificada en el servidor de Mailbox.

1

Figura 1: Arquitectura de protocolos para CAS Exchange 2013

Además de no presentar datos, el paso 5 es el cambio fundamental que permite la eliminación de sesiones en el balanceador de carga. Para una sesión de protocolo, el CAS sostiene una relación 1:1 con el servidor de Mailbox que mantiene la información del usuario. En el caso de que la copia de la base de datos activa se mueva a un servidor de buzón diferente, CAS cierra las sesiones con el servidor anterior y establece sesiones al nuevo servidor. Esto significa que todas las sesiones, independientemente de su punto de origen (es decir, los miembros del CAS en la matriz de equilibrio de carga), terminan en el mismo lugar, el servidor de buzones que hospeda la copia de base de datos activa.

Ahora muchos de ustedes pueden estar pensando, espera ¿Cómo funciona la autenticación? Bueno para las solicitudes HTTP, POP, IMAP o que utilizan autenticación básica, NTLM o autenticación Kerberos, la solicitud de autenticación se pasa como parte de la carga útil de HTTP, por lo que cada CAS autenticará el requerimiento de manera natural. La autenticación basada en formularios (FBA) es diferente. FBA fue una de las razones por las cuales se requiere la afinidad de sesión para OWA en versiones anteriores de Exchange – la razón es que las cookies utilizan una clave para el cifrado por servidor, por lo que, si otro CAS recibe una solicitud, este no podía descifrar la sesión. En Exchange 2013, ya no nos aprovechamos de una clave de sesión por servidor, en vez de eso, aprovechamos la clave privada del certificado que está instalado en el CAS. Siempre que todos los miembros de la matriz de CAS compartan exactamente el mismo certificado, podrán descifrar las cookies.

Proxy vs Redirección

Anteriormente se habló acerca de cómo el CAS realiza un proxy de las solicitudes hacia el servidor de Mailbox que mantiene la copia activa de la base de datos. Antes de eso CAS tiene que tomar la decisión de re direccionar hacia otro CAS, o realizar el proxy. CAS solo realizará una redirección bajo las siguientes circunstancias:

  1. La solicitud es telefónica
  2. Para solicitudes Outlook Web App, si el buzón de mailbox se encuentra ubicado en otro sitio de Active Directory y hay un servidor de CAS en ese sitio que tiene la ExternalURL poblada, entonces el servidor de CAS de origen re direccionará la solicitud, a menos que la ExternalURL sea la misma que el servidor de origen, en cuyo caso, CAS realizará el proxy (este es un escenario con múltiples sitios y un solo espacio de nombres).

2

Figura 2: Ejemplo de Proxy y redirección de Client Access Server Exchange 2013

3. Para solicitudes OWA, si la versión del buzón de mailbox es Exchange 2007, entonces CAS Exchange 2013 re direccionará hacia el CAS Exchange 2007.

Conexión vía Outlook

Se habrán dado cuenta que hasta el momento solo se ha hablado de HTTP, POP e IMAP. No se ha mencionado en ningún momento RCP/TCP como solución de conectividad que soporta el CAS, y esto es por una razón muy específica, CAS de Exchange 2013 no es compatible con RCP/TCP, solo es compatible con RCP/HTTP (también conocida como Outlook Anywhere). Este cambio de arquitectura se realiza para conducir un modelo de conectividad más estable y fiable.

Para entender el por qué, es necesario tener en mente los siguientes principios:

  1. Recuerde, el CAS de Exchange 2013 es un servidor de Proxy/redirección y de autenticación. CAS Exchange 2013 no realiza procesamiento de datos (ni muestra ni transformación). Solamente realiza el proxy de las solicitudes hacia el Mailbox utilizando el protocolo de cliente (en este caso HTTP).
  2. CAS y Mailbox de Exchange 2013 no se encuentran unidos por una afinidad de usuarios o de manera geográfica. Es posible tener el CAS en un datacenter autenticando y realizando las solicitudes mediante proxy hacia un servidor Mailbox en otro datacenter. Para poder habilitar eso fue necesario realizar un cambio en los protocolos de comunicación utilizado entre los roles. Alejándose del protocolo RPC, hacia los protocolos de clientes los cuales son más tolerantes ante la latencia de conexiones WAN/Internet.
  3. Para un buzón dado, el protocolo que da servicio a la solicitud siempre va a ser la instancia del protocolo del servidor de buzones que hospeda la copia activa de la base de datos para el buzón del usuario. Esto se hizo para acabar con los problemas de versiones y funcionalidad que hemos visto en las últimas dos generaciones.

El último elemento está relacionado al por que ya no se utiliza el protocolo RCP/TCP como solución de conectividad. En todas las versiones anteriores del RCP endpoint era un FQDN. De hecho, el cambio hacia el nivel medio para el procesamiento de RCP en CAS de Exchange 2010 introdujo un nuevo espacio de nombres compartidos, el RCP Client Access Namespace. Moviendo el acceso de cliente de vuelta al rol de Mailbox en Exchange 2013. Esto nos obligado a utilizar el Mailbox FQDN para el RCP Endpoint o nombres compartidos para el DAG.Ninguna de las opciones es adecuada y añade complejidad al soporte de la infraestructura. En cambio, ahora utilizamos un GUID. El GUID del buzón es único dentro de la organización, por lo que independientemente de donde se activa la base de datos y se monta, CAS puede descubrir la ubicación y realizar el proxy de la solicitud hacia el servidor de Mailbox correcto.

3

Figura 3: Cambios en el RCP endpoint

Este cambio en la arquitectura significa un modelo de conexión más fiable, para un determinado número de sesiones que se dirigen al CAS, CAS de Exchange 2013 siempre tendrá una relación de 1:1 con el servidor de Mailbox que hospeda el buzón del usuario. Esto significa que en un entorno de Exchange 2013, el cliente Outlook no requerirá un reinicio cuando se muevan los buzones.

Simplificación de nombres

Otro de los beneficios de la arquitectura de Exchange 2013 es que el modelo de espacios de nombres puede ser simplificados (especialmente para las migraciones desde Exchange 2010). En Exchange 2010, un cliente que quiere implementar una solución de site-resilent para dos Datacenter requería los siguientes nombres:

  1. Nombre de protocolo de internet para primer DataCenter
  2. Nombre de protocolo de internet para segundo Datacenter
  3. Nombre de recuperación para OWA de primer Datacenter
  4. Nombre de recuperación para OWA de segundo Datacenter
  5. Nombre para RCP Client Access de primer Datacenter
  6. Nombre para RCP Client Access de segundo Datacenter
  7. Autodiscover
  8. Legacy Namespace
  9. Transport Namespace

Como se mencionó anteriormente, esto se simplificó eliminando el RCP Client Access namespace.

Recordemos que el servidor de CAS envía las solicitudes de proxy hacia el servidor que mantiene la copia activa de las bases de datos. Esta lógica de proxy no se limita a los límites del sitio de Active Directory. Un CAS de Exchange 2013 en un sitio de Active Directory puede realizar la solicitud de proxy a un servidor de Mailbox que se encuentre en otro sitio de Active Directory. Si la utilización de la red, la latencia y rendimiento no son una preocupación, esto significa que no necesitamos los espacios de nombres adicionales para escenarios de resistencia de sitio, eliminando de este modo otros tres espacios de nombres (protocolo de Internet secundaria y los dos espacios de nombres de recuperación de OWA).

 Por ejemplo, digamos que tengo una infraestructura en dos datacenter en Norte América, que tienen una configuración de red de tal manera que la latencia, el rendimiento y la utilización entre los dos datacenter no es una preocupación. También quería simplificar la arquitectura de mi namespace con la implementación de Exchange 2013 para que mis usuarios utilicen un único nombre para el acceso desde internet, independientemente de donde se encontrará su buzón. Si despliego una arquitectura como la mostrada a continuación, entonces la infraestructura CAS de ambos datacenter podrían utilizarse para enrutar el tráfico y el proxy para los servidores de Mailbox que alojan las copias activas. Como no estamos preocupados por el tráfico de red, puedo configurar DNS round robin entre las VIP de los balanceadores de carga en cada datacenter. El resultado en un sitio con resistencia a perdida mientras acepta que la mitad del trafico proxy estará fuera del sitio.

4

Figura 4: Único espacio de nombre en Exchange 2013.

Transporte

El servidor de Client Access puede realizar de proxy para las sesiones de SMTP. Esto es manejado por un nuevo componente, el servicio de transporte Front-End, El servicio de transporte front-end maneja todo el tráfico SMTP externo de entrada y salida de la organización de Exchange, así como, puede ser un cliente endpoint para el tráfico SMTP. Las funciones del servicio de transporte front-end funciona como proxy de capa 7 y tiene acceso completo al protocolo de conversación, el servicio de transporte front-end no tiene una cola de mensajes. Además, el servicio de transporte front-end no realiza bifurcación del mensaje.

El servicio de transporte front-end utiliza los puertos TCP25, TCP587, y TCP717 como se ve en el siguiente diagrama:

5

Figura 5: Arquitectura del servico de transporte front-end.

El servicio de transporte front-end proporciona protección a la red, un sistema centralizado, balanceador de carga para la salida/entrada hacia la organización de Exchange, ya sea por clientes POP/IMAP, Sharepoint, o aplicaciones de terceros.

Para los mensajes de salida, el servicio de transporte front-end se utiliza como proxi cuando los conectores de envió (que se encuentran ubicados en los servidores de Mailbox) tienen el conjunto de propiedades de FrontEndProxyEnabled. En esa situación, aparecerá que el mensaje se originó a partir del CAS.

Para los mensajes entrantes, el servicio de transporte front-end debe encontrar rápidamente un servicio de transporte saludable en un servidor de Mailbox que reciba una transición del mensaje, independientemente de la cantidad o el tipo de destinatarios:

  • Para mensajes con un único destinatario, se seleccionará el servidor de Mailbox en el grupo de entrega de destino, y se dará preferencia en el servidor que se encuentre más cercano basado en las configuraciones de los sitios de Active Directory
  • Para los mensajes con múltiples destinatarios, los primeros 20 destinatarios utilizaran el servidor de Mailbox más cercano basado en las configuraciones de los sitios de Active Directory.
  • Si el mensaje no tiene destinatarios, se seleccionará un servidor de Mailbox al azar en el sitio local de Active Directory.

En conclusión, el rol de Client Access Server simplifica la capa de red. La afinidad de sesiones en el balanceador de carga ya no se requiere en CAS de Exchange 2013. CAS introduce una mayor flexibilidad en la implementación, ya que permite simplificar la arquitectura de su namespace, lo que podría consolidar en un único nombre a nivel regional o mundial para los protocolos de internet. La nueva arquitectura también simplifica la historia de actualización e interoperabilidad, como CAS puede actuar como proxy o redirigir a multiples versiones de Exchange, lo que permite actualizar los servidores de Mailbox a su propio ritmo.

Ernesto León, Consultor Infraestructura, Blue Solutions.

Configurar la suscripción de reportes con SQL Server y SSRS

Todo lo que se conecta a SQL Server genera datos que pueden ser presentados en un lindo reporte a través de SQL Server Reporting Services. Puedes trabajar con herramientas intuitivas y orientadas a los usuarios no técnicos, como Report Builder.

En este artículo veremos cómo crear suscripciones a los reportes ya generados.

Las suscripciones son agendas que se crean para despachar, habitualmente, por correo electrónico algún reporte. Por ejemplo, envío de reporte de ventas de la semana anterior todos los días lunes a las 9:00 AM.

A nivel de base de datos, se requiere que el servicio SQL Agent esté corriendo. Este servicio es el encargado de administrar los job. Desde el punto de vista del reporte, es el servicio que se encarga de ejecutar la consulta en la base de datos al momento de generar y enviar el reporte.

Este servicio debe ser inicializado en la herramienta SQL Server Configuration Manager:

001

 

Para el envío de correos se necesita un servidor SMTP y una cuenta de correo para el envío (no es necesario que esta cuenta exista en el servidor). Los parámetros del servidor deben ser configurados en la herramienta Reporting Services Configuration Manager:

002

Sender Address es una dirección ficticia. Es para que muestre un origen válido. SMTP Server es la dirección del servidor SMTP.

En el sitio web de administración de los reportes de SQL Server Reporting Services, buscamos el reporte que se quiere enviar por correo y en el menú contextual, se selecciona la opción de  suscribir.

Primera acción a realizar, es configurar los parámetros de envío de correo y forma. Esto incluye: destinatario, asunto y comentario. También hay que configurar el formato de envío del reporte y agenda (programación). Importante: El portal funciona de forma óptima con Internet Explorer.

003

Luego hay que configurar los parámetros, si es que el reporte los requiere:

004

Una vez que está todo OK, la configuración queda guardada apretando el botón Aceptar.

 

Maximiliano Marín, Consultor Infraestructura, Blue Solutions.

 

Ejecución manual de DirSync

Dependiendo de la versión de la solución de sincronización que está utilizando para replicar los datos del directorio desde el Active Directory local a Office 365 hay diferentes comandos que tendrá que utilizar.

Podemos ver una lista de las versiones DirSync en la wiki de TechNet, y para AAD Sync, los listados de versión son en MSDN.  A pesar de esto, ahora ha sido reemplazado con otro artículo que tiene información de la versión de sincronización y AAD AAD Conectar.

Los términos completos de sincronización y sincronización delta no son exclusivos de las herramientas de Microsoft aquí expuestas. Una sincronización completa hará exactamente eso, sincronizar todos los objetos sin tener en cuenta si ya está sincronizado. Esto tomará una cantidad significativa de tiempo en un gran residente. Una sincronización completa se producirá cuando la herramienta de sincronización de directorios se instala por primera vez, ya que esto es necesario para obtener todos los objetos que están en el ámbito de la sincronización en Azure Active Directory. Una vez que los objetos están allí, solo se encripta la información del objeto (por seguridad) y aquí es donde la sincronización delta entra en acción. Una sincronización delta sólo se replican los cambios desde la sincronización anterior por lo que es más rápido y más eficiente en general.

Azure AD Connect (Conectar AAD) Febrero el año 2016 Build (1.1.105.0) en adelante

En febrero el año 2016, build 1.1.105.0 de Azure AD Connect fue liberado, introdujo varias nuevas características. El planificador está ahora integrado en el motor de sincronización, esto significa que ya no es una herramienta DirectorySyncClientCmd separada.

Para iniciar una sincronización delta, abra Windows PowerShell y ejecutar:

Start-ADSyncSyncCycle -PolicyType Delta

Para iniciar una sincronización completa, abra Windows PowerShell y ejecutar:

Start-ADSyncSyncCycle -PolicyType Initial 

Pierre añadió un comentario que indica que si los comandos no son visibles, trate de cargar el módulo de PowerShell:

Import-Module “C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1”

Azure AD Connect (Conectar AAD) Diciembre el año 2015 Build (1.0.9131.0) y es mayor

De junio del año 2015 vio el lanzamiento de Azure AD Conectar el cual es el sucesor de Azure AD Sync. A partir del momento de la escritura, la última versión del AAD Connect es 1.0.8667.0. Eso va a cambiar con el tiempo, así que por favor echa un vistazo a la información de versión sobre AAD AAD Sync y Conectar

Al igual que con la herramienta de sincronización de AAD se encuentra en:

C:\Program Files\Microsoft Azure AD Sync\Bin

Para realizar una actualización manual, utilice la herramienta DirectorySyncClientCmd.exe. El Delta y parámetros Initial especifican la tarea correspondiente.

1

La pantalla de abajo fue tomada de acumulación 1.0.9131.0 de Azure AD Conectar.

2

Azure Active Directory Sync Services (AAD Sync)

Para septiembre de 2014 se publicó la herramienta Microsoft Azure AD Sync, esto cambió cómo se emiten solicitudes de sincronización manual.

Para realizar una actualización manual, ahora utilizamos la herramienta DirectorySyncClientCmd.exe. El Delta y parámetros iniciales se añaden al comando para especificar la tarea correspondiente.

Esta herramienta se encuentra en:

C:\Program Files\Microsoft Azure AD Sync\Bin

Windows Azure Active Directory Sincronización – Junio 2014 Build 6862 Adelante

Con construir 6862 el módulo de PowerShell se ha movido. La ubicación de este módulo es ahora:

C:\program Files\Windows Azure Active Directory Sync\DirSync\ImportModules.ps1

Que nos permita ejecutar el cmdlet Start-OnlineCoexistenceSync que puede:

Abra Windows PowerShell y Import-Module DirSync

Abrir Windows PowerShell y ejecute el archivo de Import-Modules.ps1

Windows Azure Active Directory Sincronización – Abril 2014 Construye viejo que 6765

En la anterior obra de sincronización de directorios, usaríamos los DirSyncConfigShell.psc1 que se encuentran en:

C:\Program Files\Windows Azure Directory Sync

o

C:\Program Files\Microsoft Online Directory Sync

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Ventanas de mantenimiento con SCCM

Es tarea del departamento de TI y soporte hacer mantenimiento en las estaciones de trabajo. El mantenimiento implica la ejecución de las revisiones de los antivirus, limpieza de los equipos, distribución de configuración, distribución de aplicaciones, y la más temida, distribución de actualizaciones.

Es muy habitual que se implemente una mala política de distribución de actualizaciones a nivel corporativo. Esta política es sencillamente no distribuir actualizaciones.

Los motivos para no distribuir actualizaciones he visto que principalmente son 3:

  • Porque no son necesarias
  • Porque son una molestia para los administradores y para los usuarios
  • Porque no cuentan con una herramienta que permita optimizar el proceso

No entraremos en discusión sobre las buenas prácticas al respecto, pero sí me quiero centrar en el punto 2.

El punto 2 está condicionado a que no se dan las ventanas de trabajo para que se realice esta importante tarea y es ahí donde quiero llegar.

Las ventanas de mantenimiento son espacios de tiempo en los que los usuarios no se encuentran trabajando. Es un espacio donde el horario hábil ya acabó y se pueden ejecutar las tareas automatizadas, como la de distribución de actualizaciones.

Con System Center Configuration Manager se puede configurar las ventanas de mantenimiento a nivel de colección y configurar la distribución de paquetes para que se realice la instalación dentro de esa ventana.

Generando una ventana de mantenimiento por colección, puede darse el caso que a una máquina tenga asignada dos o más ventanas de mantenimiento.

Si las ventanas de mantenimiento no tienen tiempo en común, serán tratadas como ventanas de mantenimiento aparte.

Si las ventanas de mantenimiento tienen tiempo en común, se considerará la extensión total de las ventanas. Por ejemplo: Si dos ventanas de mantenimiento de una hora de extensión cada una, sobre un equipo, tienen un tiempo en compartido de 30 minutos, la ventana será de 90 minutos.

La configuración de una ventana de mantenimiento para colección, se tiene que hacer en las propiedades:

11

Vista de las ventanas de mantenimiento creadas

12

Configuración de la agenda de la ventana de mantenimiento

Al momento de la distribución de una aplicación se puede configurar cual es la acción que se puede tomar una vez que la fecha límite de instalación ha sido alcanzada:

13

Configurando ventanas de mantenimiento se genera un ambiente saludable para que los usuarios puedan realizar sus actividades de forma cotidiana y TI pueda desarrollar las suyas correspondientes en el mantenimiento y soporte de las estaciones de trabajo de los clientes internos.

14

Maximiliano Marín, Consultor Infraestructura, Blue Solutions.