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.

Advertisements

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. 

 

Migración de una entidad certificadora desde Windows Server 2003 hacia Windows Server 2012

La migración de una CA de Microsoft es una actividad sencilla, pero debe llevarse a cabo de forma meticulosa, los tiempos de migración y la complejidad de ésta van a ir variado según el entorno al que nos enfrentemos. El primer paso es hacer el backup de la base de datos de la CA y de las configuraciones almacenadas en al registry.

Iniciar sesión en el servidor de origen, luego iniciar la consola de administración de la CA. Hacer click derecho sobre el nodo con el nombre de la CA, luego dirigirse a la opción All Tasks, luego hacer clic sobre Back Up CA.

1

En la sección Welcome to the Certification Authority Backup Wizard, presionar el Next.

2

En la sección Items to Back Up seleccionar Private Key and CA Certificates y Certificate database and certificate database log, luego seleccionar la ubicación en el campo Back up to this location y presionar Next.

3

En la sección Select a Password ingresar la contraseña para proteger la clave privada, presionar Next.

4

En la sección Completing the certification Authority Backup Wizard presionar Finish.

5

NOTA: Verificar que en la ruta seleccionada, existan los siguientes archivos: certbkxp.dat, edb#####.log, and CAName.edb

Desde la consola de comandos ejecutar “net stop certsvc.

6

NOTA: El servicio debe ser detenido para evitar la emisión de certificados adicionales.

El siguiente paso es exportar las claves de registro, para realizar esto desde el menú Run… ejecutar el comando regedit. Navegar hacia la clave HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvc hacer click derecho sobre Configuration y hacer click en la opción Export. Seleccionar como destino la misma carpeta donde se realizó el backup de la CA, ingresar el nombre del archivo y presionar Save.

7

NOTA: Si la CA de origen usa un archivo CAPolicy.inf personalizado, se debe copiar el archivo en la misma ubicación que los archivos de copia de seguridad fuente de CA.

El archivo CAPolicy.inf se encuentra en el directorio %SystemRoot%, que suele estar en C:Windows.

Copiar la carpeta donde se realizaron los backups al nuevo servidor. Luego desinstalar la CA desde Add/Remove Windows Components Wizard, unir el servidor a un workgroup.

El siguiente paso es la instalación y configuración del rol AD-CS. Una vez instalado el rol AD-CS resta realizar la configuración del rol, para esto desde la consola Server Manager hacer click sobre el icono de notificaciones luego en el enlace Configure Active Directory Certificate Services on the destination server.

8

En la sección Specify credentials to configure roles services presionar Next.

9

En la sección Select Role Services to configure, seleccionar el rol Certification Authority luego presionar Next.

10

En la sección Specify the setup type of the CA seleccionar el mismo tipo de CA que la de origen, presionar Next.

11

En la sección Specify the type of the private key seleccionar la opción Use existing private key luego seleccionar la opción Select a certificate and use its associated private key, presionar Next.

12

En la sección Select an existing certificate for this CA, presionar el botón Import luego presionar el botón Browse… y navegar hasta la ruta donde se encuentra el certificado exportado. En el campo Password ingresar la contraseña para poder acceder a la clave privada por último presionar Next.

13

14

En la sección Specify the database locations verificar la ubicación de la base de datos y del log, presionar Next.

15

En la sección confirmation presionar el botón Configure.

16

En la sección Results presionar Close.

El siguiente paso es restaurar la base de datos de la CA de origen en el servidor de destino. Para llevar adelante esta tarea, ejecutar los siguientes pasos.

Iniciar sesión en el servidor de destino, iniciar la consola de administración de AD-CS hacer click derecho sobre el nodo con el nombre de la CA, dirigirse a la opción All tasks luego a la opción Restore CA…

17

Presionar el botón OK en la ventana que alerta sobre la detención del servicio AD-CS.

18

En la sección Welcome to the Certification Authority Restore Wizard presionar Next.

19

En la sección Items to restore seleccionar la opción Certificate database and certificate database log, luego presionar el botón Browse… y navegar hasta donde se encuentra la carpeta con el backup de la CA de origen, por último presionar Next.

20

En la sección Completing the Certification Authority Restore Wizard presionar Finish.

21

En la ventana Certification Authority Restore Wizard presionar el botón Yes para iniciar el servicio AD-CS.

22

El último paso en esta migración, es importar las claves de registro, antes de hacer esta tarea es importante revisar los siguientes valores, los cuales deben coincidir con los valores de la nueva instalación.

Estos valores de la ubicación del almacenamiento son elegidos durante la configuración de la CA. Estos existen en la clave del Registro de configuración:

  • DBDirectory
  • DBLogDirectory
  • DBSystemDirectory
  • DBTempDirectory

Los siguientes valores en la clave del Registro de configuración{nombre}CA contienen, en sus valores por defecto una ruta local. (Como alternativa, se puede actualizar estos valores después de importarlos mediante el uso de la consola de administración de CA. Los valores se encuentran en la solapa CA properties Extensions).

  • CACertPublicationURLs
  • CRLPublicationURLs

Iniciar la consola de comandos con privilegios de administrador, ejecutar el comando net stop certsvc.

23

Luego ubicados en la carpeta donde se encuentra el archivo .reg que queremos importar ejecutar el comando reg import < nombredearchivo.reg >

24

Por último ejecutar el comando net start certsvc para iniciar el servicio.

25

Con esto podemos finalizar la migración de la CA, finalmente pueden validar el funcionamiento de esta entidad certificadora, integrándolo con algún servicio web o similares para la distribución de certificados.

Nicolás Herrera, Consultor Infraestructura, 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.

 

Migrar el perfil de usuarios (cuentas de dominio o perfiles locales)

Las empresas que no poseen Active Directory y desean implementarlo, es común que presenten el problema para la migración de sus perfiles. Esto puede verse como un problema menor, pero en realidad significa un gran cambio para el usuario, ya que no solo tendrá una nueva cuenta, sino que además todas sus configuraciones se pierden y debe copiar los archivos a nuevo perfil.

En este artículo explicaremos cómo hacer la migración de perfiles en menos de 15 minutos, igualando todas las configuraciones y archivos del usuario.

Para el proceso de migración de perfiles se utilizará la herramienta User Profile Wizard 3.9, esta herramienta es gratuita y permite migrar un perfil local al nuevo perfil creado con las cuentas de dominio.

Antes de hacer la migración se debe subir el equipo al dominio e ingresar con el perfil del usuario para crear la carpeta del perfil, luego se debe cerrar la sesión del dominio e ingresar la cuenta local del usuario para realizar el proceso de migración.

Descarga y uso User Profile Wizard 3.9

Para descargar la herramienta de migración desde la página del fabricante debe acceder al siguiente enlace https://www.forensit.com/downloads.html.

Esto descargará un archivo .Zip el cual debe ser extraído para acceder al contenido. Luego de extraer, se identifica el instalador de la herramienta, además de un archivo .txt que informa sobre la licencia legal del software.

1

Esta herramienta no requiere instalación, por lo que para usarla solo debe hacer doble clic en el archivo Profwiz.exe y se abrirá el asistente de migración.

  1. Siguiente

2

2. Se debe seleccionar la cuenta a migrar

3

3. Seleccionar el dominio y especificar la cuenta

4

4. Se inicia el proceso de migración y se espera que finalice

5

Luego se debe cerrar sesión y se ingresa con la cuenta de dominio, donde ésta estará configurada igual que la antigua cuenta local del usuario.

El proceso de migración puede demorar dependiendo de la cantidad de información que se deba migrar, a pesar de esto, los procesos de migración son muy ágiles y no deben tomar más de 10 a 15 minutos. Si el tiempo de migración supera los estándares indicados anteriormente se recomienda revisa los archivos de log del proceso.

Nunca debe detener el proceso de migración, esto puede dañar los archivos o corromper el perfil que está siendo migrado. Si la aplicación tiene un cierre brusco e inesperado se debe verificar el acceso al perfil y revisar los documentos y archivos contenidos.

Es recomendable, como medida de seguridad, hacer un respaldo de los archivos para los usuarios VIP (Gerencias, jefatura, área de contabilidad, entre otros…) o todos aquellos que manejen información delicada esto con el objetivo de prevenir una pérdida de información en el caso de que la migración se vea interrumpida.

 

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

 

Backup mailbox PST Exchange 2010/2013

En muchas organizaciones suelen tener distintos tipos de respaldos dependiendo de la importancia del negocio en donde estos estén enfocados. Al mismo tiempo, existen distintos tipos de herramientas que nos sirven para respaldar, los cuales hasta el día de hoy son líderes en el mercado del Backup Veeam, Symantec Backup exec, Azure Backup Vault, System Center Data Protection Manager, entre otros. En este caso también podemos acceder a la misma herramienta para realizar nuestro respaldo que en este caso les explicaré cómo realizarlo desde Exchange mediante Powershell.

Básicamente, la única opción disponible para respaldar nuestros correos es de forma granular a una exportación a archivos PST. Esto se puede hacer a través de Outlook (siempre), PowerShell y, en algunos casos, también a través de Exchange Management Console / Panel de control.

Exportación de un solo mailbox a PST mediante PowerShell

Lo primero que debemos realizar es asignar permisos para importar y exportar a un usuario específico.

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User “<usuario>”

Luego de este script podemos comenzar con el respaldo del mailbox que deseamos respaldar.

New-MailboxExportRequest -Mailbox <user> -FilePath \\<server FQDN>\<nombre carpeta compartida>\<nombre PST>.pst

Mailbox: Cuenta de usuario a respaldar.

FilePath: Ruta de carpeta compartida donde almacenaremos el PST.

Exportación de mailbox de toda la organización mediante PowerShell.

Al igual que en el procedimiento anterior, si no está aplicado, debemos asignar permisos para importar y exportar a un usuario específico.

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User “<usuario>”

Forma 1

Declaramos la siguiente variable en donde seleccionamos a todos los mailbox

$AllMailboxes = Get-Mailbox

después ejecutamos el siguiente script

$AllMailboxes|%{$_|New-MailboxExportRequest -FilePath \\<server FQDN>\<nombre carpeta compartida>\$($_.Alias).pst}

FilePath: Ruta de carpeta compartida donde almacenaremos el PST.

$._Alias: Nombre con el que se guarda el PST (en este caso aplica  a los alias de los usuarios).

Forma 2

En el caso de ser un listado de usuarios específico, debemos generar un CSV con el parámetro Identity y Alias de cada usuario.

$csv = Import-Csv “C:\Migracion365\Data\Password\$Domain.csv”

Luego ejecutamos el siguiente script

foreach ($line in $csv) { New-MailboxExportRequest -Mailbox $Line.Identity -FilePath “\\<server FQDN>\<shared folder name>\$($Line.Alias).pst” }

 

Bueno, espero que les haya servido de ayuda, ya que esta opción es muy buena si no disponen de herramientas de respaldo en donde puedan ocupar la técnica de Backup 3,2,1.

Luis Arancibia, Consultor Cloud, Blue Solutions.