On the way to Virtualization

A partir de la versión 1610, (muy cuestionable) Cloud Management Gateway, algo así como, Puerta de Enlace de Administración en la Nube, proporciona una manera sencilla de administrar clientes de Configuration Manager en Internet.

Éste servicio en la nube, (en adelante CMG), se implementa en Microsoft Azure con su suscripción de Azure correspondiente y es el propio SCCM quien publica la configuración de CMG, incluida la información de conexión y la configuración de seguridad.

El propósito es conectar a la infraestructura de SC Configuration Manager local con un nuevo rol denominado, CMG, que viene a sustituir a un descontinuado IBCM.
Una vez implementado y configurado, los clientes podrán tener acceso a los roles de sistema de sitio locales de Configuration Manager independientemente de si están conectados a la red interna privada o a Internet.

CMG autentica y reenvía las solicitudes de cliente de Configuration Manager al punto de conexión de CMG. Estas solicitudes se reenvían a los roles en la red corporativa según las asignaciones de direcciones URL.

Se realiza con una VM en Azure, de tipo Medium
Ésta VM establece un tunel ssl q sirve de proxy desde Azure, lo cual elimina el tedio de configuración en nuestras comunicaciones que requería IBCM de nuestros proxy, firewall o balanceadores.

Junto con ésta funcionalidad, muy recomendable montar otro rol en Azure que se llama Cloud Distribution Point, en adelante CDP, que sirve para distribuir aplicaciones desde un site público en internet y se realiza con una VM de tipo Small.

Con toda ésta configuración hemos de entender que, las 2 VM en Azure generan un tráfico de red, el que sirven a los puestos clientes, que genera un coste de:

• 1 Suscripción en Azure de 2 VM. (1 Small y 1 Medium) Cada instancia de CMG admite 4.000 clientes, con dos instancias daremos mejor disponibilidad.
• 1.000 GB de tráfico. 7 €./mes aprox.

Dicho esto, contemos la realidad de mi experiencia al implementarlo:
Lo primero que tenemos que saber es que necesitamos subir de versión a Configuration Manager, obligatorio trabajar con la versión 1702.

Pero ya adelanto que os dará fallo en AZURE al implementar el rol de CMG Hay dos soluciones, subir a la versión 1706, disponible desde el 29 de agosto de 2017 o aplicar éste hotfix para CMG a la versión 1702:

https://support.microsoft.com/en-us/help/4033015/provisioning-not-completed-when-creating-a-cloud-management-gateway-in

Los requisitos

Equipos cliente y servidor de sistema de sitio que ejecuten CMG. Antes de poder usar las características de versión preliminar, hay que dar consentimiento para usarlas desde la consola de SCCM para poder seleccionarlas y permitir su uso.

Dar el consentimiento es una acción que se realiza una sola vez por jerarquía y que no se puede deshacer. Mientras no dé su consentimiento, no puede habilitar nuevas características de versión preliminar incluidas con las actualizaciones. Después de activar una característica de versión preliminar, no podremos desactivarla.

Para dar consentimiento en la consola de SCCM, vamos a Administración –> Configuración del Sitio –> Sitios y seleccionamos, Configuración de jerarquía. En la pestaña General, marcamos, Consent to use Pre-Release features.

Si ha dado su consentimiento ahora puede habilitar las características de versiones preliminares en el Asistente de actualizaciones y mantenimiento al instalar la actualización.

Previamente habremos generado 4 Certificados Web Server SSL personalizados en 2048 desde la CA interna y tener a mano el CA Root de nuestra PKI
Los certificados se usan para cifrar la comunicación de los equipos cliente y para autenticar la identidad del servicio de CMG:

Certificado Admin Azure

1. PFX (con clave privada): Para SCCM CB
2. CER (solo clave publica): Para Azure

Certificado CMG

1. PFX: Para Azure (a través de SCCM CB)

Certificado CDP

1. PFX: Para Azure (a través de SCCM CB)

La Implementación

Abrimos la consola de SCCM CB para implementar el servicio en Azure y agregamos el rol de CMG en Cloud Services:

Como se podrá observar en los próximos cinco pasos, la implementación de CMG y DP en SCCM y Azure se realiza obligatoriamente mediante el uso de certificados.

1.- Subir el Certificado de Admin Azure

Éste certificado es necesario para la suscripción en Azure, al cual he llamado, AzureAdmin.cer

2.- AzureAdmin.pfx (Para autenticar la conexión con SCCM y siempre con la terminación cloudapp.net)

El ID de suscripción lo obtenemos de AZURE y utilizaremos el Certificado de Administración al que hemos llamado, AzureAdmin.pfx al crear tanto el Cloud Management Point, como al crear Cloud Distribution Point

Desmarcar comprobación de revocación de certificados y especificamos como Certificado pfx, generado por nuestra PKI. el que hemos llamado CMGMiEmpresa.pfx especificando el servico FQDN con la terminación, cloudapp.net

Pinchar sobre Certicados de la CRL y añadir el CA Root de nuestra PKI

El resto, next, next…de tal forma que en la consola de SCCM nos quedará CMG algo así:

3.- CARoot.cer
(En la VM de Azure para CMG. Necesario para la revocación de certificados que previamente ya hemos desmarcado)

4.- CMG.pfx

Éste Certificado para Azure a traves de SCCM CB, lo hemos utilizado ya en el Punto 2

5.- DP.pfx

La misma idea, que en los Puntos 2 y 5.
El mismo ID de suscripción que obtenemos de AZURE con el Certificado de Administración, AzureAdmin.pfx

En ésta pantalla especificamos como Certificado pfx, el generado por nuestra PKI. el que hemos llamado DPMiEmpresa.pfx

En SCCM, todas las opciones del cliente se administran desde el nodo Configuración de cliente del área de trabajo Administración de su consola.
A continuación, vamos a configurar la opción Cloud Services para los dispositivos de alguna colección dentro de nuestra jerarquía y la implementaremos sobre las recopilaciones.

Sobre el Custom Device Settings de Cloud Services que recién hemos creado, botón derecho y seleccionamos Deploy para seleccionar una colección sobre la que implementarlo.

Finalmente decir que existe un bug en la versión 1706, en el componente de notificaciones online del cliente, el cual, aunque esté conectado y exista comunicación, aparece como apagado y no será hasta la reléase 1710 que Microsoft dará solución a ese bug.

La política del ciclo de vida de soporte Microsoft proporciona directrices coherentes y previsibles para la disponibilidad de soporte del producto en el momento del lanzamiento del producto y durante toda la vida del mismo. Al comprender el soporte de producto disponible, todos estaremos mejor capacitados para maximizar la administración de las inversiones en IT y planificar estratégicamente un futuro de IT exitoso.

Microsoft ofrecerá un mínimo de 10 años de soporte (5 años de soporte principal y 5 años de soporte extendido) para productos Business y Developer.

Ésta imagen enumera los sistemas operativos Windows y los paquetes de servicio de soporte del ciclo de vida.
Para obtener más información sobre la política del ciclo de vida del soporte técnico de Microsoft sobre cualquier producto o servicio, éste es el sitio web oficial:

https://support.microsoft.com/es-es/lifecycle

El 02 de mayo de 2017 Microsoft publicó la versión 4.7 de .Net Framework

Las características WPF de .NET Framework 4.7 toman una dependencia de D3DCompiler_47.dll.
El archivo D3DCompiler_47.dll no está presente de forma predeterminada en plataformas Windows 7 SP1, Windows 2008 R2 SP1 y Windows 2012. Por tanto, es necesario instalar D3DCompiler_47.dll en dichas plataformas para que las características WPF de .NET Framework 4.7 funcionen según lo esperado.

En éste enlace se explica bien por parte de Microsoft los problemas conocidos sobre la instalación de D3DCompiler_47.dll.

Esta versión por el momento no se encuentra soportada en Exchange.
La recomendación es no instalar el .Net Framework 4.7 en servidores con Exchange hasta que no se incluya el soporte, para esto tenemos dos opciones, ocultar la actualización en el sistema operativo donde esté instalado o bloquear la instalación mediante registro.

Si optamos por bloquear de forma tempral la instalación de .Net Framework 4.7 estos son los pasos

1. Abrir Regedit
2. Ir a HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP
3. Crear una nueva llave denominada “WU” (sin comillas)
4. Dentro de “WU” crear un nuevo valor DWORD “BlockNetFramework47”
5. Modificar el valor de BlockNetFramework47, establecer en 1 y cerrar el registro.

Ya tenemos disponibles desde junio de 2017 los últimos Cumulative Update para Exchange Server:

Exchange 2016 Cumulative Update 6 (*)
Exchange 2013 Cumulative Update 17

En el caso del CU6 para Exchange 2016 es requerida la extensión del esquema.
En cuanto al CU17 de Exchange 2013 si bien no sería necesaria la extensión del esquema se debe ejecutar el PrepareAD por si faltan definiciones a nivel de RBAC (Role Based Access Control).

La lista completa de actualizaciones para Exchange 2013 / 2016:

Exchange 2016 Cumulative Update 6
Exchange 2013 Cumulative Update 17

(*) Recordemos que .Net Framework 4.7 todavía está en proceso de validación para Exchange Server y por el momento oficialmente no estaría soportado.

Existen varias medidas específicas que se hacen necesarias para mitigar contra ransomware y otras amenazas:

1. Asegurarse de tener las últimas actualizaciones de seguridad instaladas.
2. Asegurarse de tener las últimas firmas de tu proveedor de Anti Virus.
3. No abrir correo electrónico y archivos adjuntos de personas desconocidas o de fuentes que no sean confiables.

Importante. Estas medidas de seguridad son recomendaciones que pueden evitar la contaminación por ransomware, pero estos pasos solos no previenen contra las infecciones.

Recursos adicionales

Muy recomendable revisar y acceder a los siguientes recursos adicionales:

• MMPC Blog: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities /
• Microsoft Security Tech Center: https://technet.microsoft.com/en-us/security/default
• Microsoft Security Update Guide: http://aka.ms/securityupdateguide

Ya pasó la resaca del famoso ransomware WannaCry, sin embargo siguen las amenazas de una nueva versión.
Cuando ya sabemos casi todo del malware, llega el momento de recapacitar y ver si de una vez somos capaces de aprender algo de estos casos.

En los últimos días hemos visto noticias sobre el ciberataque mundial que ha «colapsado el mundo”, con frases como que estamos ante «el mayor ciberataque de todos los tiempos» o que «estamos ante el inicio de una guerra»…

Es cierto que hacía tiempo que no se veía un ataque que fuera tan grave, global, problemático y recurrente. Sin embargo los que tenemos algo de memoria, podemos recordar más de un ataque similar hace ya muchos años. Podemos recordar casos como el LoveLetter, Slammer, Nimda, Conficker o muchos similares. Después de cada caso de estos tendemos a recapacitar, ver los errores, se corrige, se parchea y se olvida todo. Sin embargo vemos como después de cada caso de este tipo en vez de aprender algo tendemos a olvidar rápidamente lo ocurrido.

Se ha hablado de un ataque global de gran escala con muchos infectados. La prensa se ha hecho eco de la gravedad del problema y la propagación que ha tenido. Se ha hablado de cifras de infección de en torno a 100.000 equipos, como algunas de las más elevadas. Sin embargo podemos recordar los números de infectados por otros malware a lo largo de la historia:

• CIH (1998) 60 millones de equipos infectados.
• I Love You o Loveletter (2000) fueron 50 millones infectados.
• Slammer (2003) con más de 75.000 servidores infectados en los primeros 10 minutos.
• Sasser (2004) más de 1 millón de equipos infectados.
• Conficker (2009) unos 7 millones infectados.

Los datos hablan por sí solos y las comparaciones son odiosas. En cualquier caso, ¿se aprendió algo de estos otros malware con infecciones masivas? Todo indica que no.

Y si hablamos de ransomware aunque no hay cifras concretas, estamos seguros de que el famoso virus de la policía ha infectado a mucha más gente que WannaCry. En un periodo de tiempo más extenso, sí, pero esa muestra de malware dio grandes quebraderos de cabeza a miles de usuarios.

¿Podremos aprender algo de una vez?
«de nuevo un gusano que aprovecha una vulnerabilidad en un producto de Microsoft provoca el colapso en Internet.»
«Vulnerabilidades tienen todos los sistemas, no es un problema en exclusiva de Microsoft, pero este caso viene a poner el dedo en la llaga cuando Microsoft intenta disminuir el tiempo que transcurre desde que es descubierta la vulnerabilidad hasta que el sistema del cliente es actualizado.»
Parece que se trata de algo reciente, escrito justo después del ataque, sin embargo aunque parezca sorprendente estos comentarios tienen más de 14 años.
Las conclusiones y lecciones después de cada caso son muy similares. Nada nuevo.

Actualizaciones. En esto somos muy pesados, todos los días hablando de parches, hoy es Windows, mañana el navegador… mantener los equipos y servidores actualizados nos libra de más de un 90% de los problemas. De hecho los equipos actualizados no se verían afectados por este ataque.

Aunque es cierto que la disponibilidad de un parche no asegura la protección de los sistemas, es necesario que los administradores o usuarios lo apliquen y reinicien su sistema. Si bien es cierto que en algunos casos puede ser un problema por dejadez, falta de tiempo o simple desconocimiento, existe también ciertas reticencias a su instalación inmediata en ambientes en producción. No es que los administradores tengan manías, pero muchos hemos sufrido parches que se superponen, regresiones de vulnerabilidades, problemas de estabilidad o incompatibilidad con otros componentes. Rompiendo una lanza en favor de Microsoft, eso ya no sucede de forma frecuente, máxime si implementamos soluciones del tipo a SCCM (system center configuration manager) que permite administrar de forma centralizada la configuración de todos los sistemas físicos y virtuales de una organización o grupo de organizaciones.

El problema parece que ha sido el mismo, la falta de una actualización que llevaba un par de meses publicada… pero a éste respecto, hay que decir que, la actuación sobre los sistemas casi siempre centra el foco de atención en los administradores, a quienes no siempre (la falta de criterio, de confianza y de una miope visión global de la dirección IT o de compañía) nos dejan ser proactivos, sino reactivos, justo cuando el problema ya nos ha estallado en las narices.

Usuarios y empresas deben ser conscientes de que, cada vez que no instalan un parche crítico, están dejando una puerta abierta para que un intruso pueda controlar totalmente su sistema, sustraer su información más sensible, borrar sus discos duros, o espiar todo lo que hacen con su ordenador. Y esto ocurre con mucha más frecuencia de la que se cree.
Tras el gusano Sasser en 2004, 13 años después podemos comprobar que los problemas siguen siendo los mismos.

Pero si los casos anteriores se han cobrado muchas víctimas «civiles», destaca de esta campaña los nombres de las empresas afectadas. Ransomware se ha cobrado víctimas entre corporaciones y organismos de todo el mundo, afectando a servicios tan críticos como el Servicio Nacional de Salud de Reino Unido, u organismos estatales y servicios de transporte en Rusia. WannaCry ha demostrado que las infraestructuras siguen siendo tan frágiles como hace años y que, en cuanto a gestión de riesgo, en ocasiones la ganancia de flexibilidad en las operaciones sigue priorizándose sobre la seguridad del sistema, unida en algunos casos a la desidia en el mantenimiento.

Copias de seguridad. Posiblemente siga siendo el gran olvidado, pero la realización de copias de seguridad periódicas diarias, semanales… Con una adecuada política, manteniendo las copias en un entorno diferente, etc. puede salvar de un problema de este tipo. Si hay una copia de seguridad de todos los datos del día anterior ante un problema similar podemos estar seguros que la pérdida no será tan significativa.

Pagar o no pagar. Hay que recordar que en muchos casos de ransomware aunque se ha llegado a producir el pago no se ha podido recuperar la información. La recomendación siempre es no pagar. Por lo que se sabe la cantidad recaudada en los tres monederos que recaudaban los fondos de este malware apenas sobrepasa los 70.000 dólares. Cantidad que se puede considerar baja teniendo en cuenta el impacto que ha tenido.

Indicadores de compromiso. Está muy bien disponer de un firewall, detector de intrusos y un buen número de medidas de seguridad activas y proactivas, pero de nada sirven si no se mantienen al día. Los indicadores de compromiso es el medio empleado en la actualidad para alimentar sistemas de seguridad.

De todas formas no estamos libres de problemas, siempre puede surgir un 0day que cause estragos. Vulnerabilidad no conocida, sin parche, y si quieres redondearlo para sistemas Windows actualizados, con ejecución remota de código. Aunque actualmente este tipo de problemas suelen estar tan bien cotizados en el mercado negro que no se emplean en ataques a gran escala sino para ataques muy muy dirigidos.

Microsoft también saca sus propias conclusiones, incidiendo igualmente en la importancia de mantener los sistemas actualizados y de la coordinación entre todos los actores para luchar contra estos ataques.
«Debemos tomar de este reciente ataque una renovada determinación para una acción colectiva más urgente. Necesitamos que el sector tecnológico, los clientes y los gobiernos trabajen juntos para protegerse contra los ataques cibernéticos. Se necesita más acción, y se necesita ahora. En este sentido, el ataque WannaCrypt es una llamada de atención para todos nosotros. Reconocemos nuestra responsabilidad de ayudar a responder a esta llamada, y Microsoft se compromete a hacer su parte.»
Las lecciones que debemos aprender están expuestas desde hace mucho, esperemos que esta vez haya sido la definitiva.

Como ya hemos comentado en otras entradas, éste útil componente (RDG) se utiliza para proveer acceso desde internet a los servidores unidos a un dominio.
Su función es de “HTTP Proxy”, en realidad “HTTPS Proxy” ya que permite a las conexiones externas, conectarse por HTTPS encapsulando el tráfico RDP en forma segura en un túnel SSL.

Sin embargo, con el update a la versión 1607 de Windows 10, la conexión al túnel SSL, no funciona si la arquitectura de RDG está soportada por Windows Server 2012 o 2012R2

La solución pasa por un workaround en el registro de los puestos cliente con W10 Release 1607:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
Name: RDGClientTransport
Type: Dword
Data: 1

Ésta clave de registro siempre podemos distribuirla a través de una GPO de dominio.

No somos muchos los que tuvimos y mantenemos la visión de apostar por una arquitectura robusta, escalable, en constante evolución y muy competitiva en el plano económico.

Hablo de los servicios RDS de Microsoft:
Remote Desktop Session Host, Remote Desktop Connection Bróker, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop App, RD License Server y por supuesto Hyper-V.

¿Se admiten las actualizaciones de sistema operativo con los roles y las función de RDS instalado a Windows Server 2016?
Sí, pero con matices, veamos por qué:

Servidores de Remote Desktop Connection Bróker (En adelante RDCB)
Es obligatorio actualizar en primer lugar, los servidores de agente de conexión de RD o Bróker. Insisto, debe/n ser los primeros en actualizarse.
Primer matiz
Microsoft no soporta los servidores Windows Server 2012 R2 con el rol de RD Conexión Broker en una implementación mixta con servidores Windows Server 2016.
Sin embargo, al revés sí, una vez que los servidores de RDCB están ejecutando Windows Server 2016, el despliegue será funcional, aunque el resto de los servidores del despliegue todavía estén ejecutando Windows Server 2012 R2, como pueden ser tal vez los Host de Virtualización de RD, en definitiva, los Hyper-V.
Si hay una configuración activo/activo en el despliegue, se deben actualizar todos los servidores al mismo tiempo y durante el despliegue no estarán disponibles los servidores de RDCB.

Servidores de Remote Desktop License Server
Segundo matiz
Si vamos a actualizar los Host de sesión de escritorio remoto, normalmente las VMs, a Winsdows 2016, antes debemos actualizar el servidor de RD License Server
La CAL utilizada debe corresponder a la versión de Windows Server que se está conectando el dispositivo o usuario. Se puede utilizar CAL mayores para acceder a versiones más recientes de Windows Server, y podremos utilizar las CAL más nuevas para acceder a versiones anteriores de Windows Server.

La siguiente tabla muestra la compatibilidad de CAL en los RDSH y los Hosts de Virtualización de RD.

Los servidores Remote Desktop Session Host (En adelante RDSH) 
Tercer matiz
Las actualizaciones para Windows Server 2016 son compatibles solamente si los RDSH son Windows Server 2012R2 y Windows Server 2016 TP5.
Además todas las aplicaciones instaladas en los RDSH, deben desinstalarse antes y volverlas a instalar después para evitar cualquier problema de compatibilidad de aplicación.

Cómo actualizar una Colección de sesiones de RDSH

1. Identificar en la colección los servidores RDSH que vamos a actualizar.
2. Impedir o evitar nuevas conexiones a estos servidores estableciendo a false la opción, Allow New Connections
3. Desconectar todas las sesiones abiertas en los RDSH
4. Quitar los RDSH de la colección.
5. Actualizar los servidores a Windows Server 2016.
6. Añadir los RDSH actualizados a sus Colecciones correspondientes.
7. Modificar Allow New Connections en «true» para los RDSH actualizados de la colección.

Los servidores RD Web Access
Pueden actualizarse en cualquier momento. En el caso de RD Web con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016. Sin embargo hay que tener en cuenta que la actualización puede restablecer propiedades del IIS (como los ficheros de configuración). Para no perder los cambios, es muy recomendable sacar unas pantallas o unas notas de las personalizaciones hechas al sitio Web de RD en IIS.

Los servidores RD Gateway (En adelante RDG)
También pueden actualizarse en cualquier momento. En el caso de RDG con Windows Server 2012 y 2012 R2 trabajarán bien con implementaciones de Windows Server 2016.
Sin embargo, Windows Server 2016 no incluye las políticas de protección de acceso de red (NAP). Éstas tienen que eliminarse antes de actualizar. Para administrar las directivas de NAP, abra la herramienta de servidor de directivas de red. Después de eliminarlos, haga clic en Actualizar la herramienta de configuración para continuar con el proceso de actualización.

Los servidores Remote Desktop Virtualization Host
Está opción estará disponible en la próxima entrada: Upgrading Remote Desktop Services deployments to Windows Server 2016 (Parte II de II )

NUMA viene de “Non uniform Memory Access o Non Uniform Memory Architecture” y nació de la necesidad de incorporar funcionalidades en el hardware que permitieran un incremento mas lineal del rendimiento, a medida que los servidores cada vez tenían mas procesadores.

AVISO: Antes de seguir es necesario que te insista en que preocuparte por NUMA no es necesario salvo que quieras optimizar un sistema hasta las ultimas consecuencias y necesites hasta la ultima gota de rendimiento y aun en ese caso hay otras muchas cosas de las que preocuparse por optimizar antes que NUMA.

Una forma simple de entender NUMA es decir que en un servidor multiprocesador que pueda usar NUMA va a generar unos grupos llamados nodos, formados por uno o mas procesadores y una cantidad de memoria, normalmente los procesadores dentro de un nodo comparten físicamente un bus de sistema y un canal de entrada salida con el sistema.

Los diferentes nodos están conectados entre si por un bus de interconexión.

El sistema tratara de correr los hilos en los procesadores asociados a la memoria hasta donde el hilo trata de acceder.

Las APIs del sistema permiten además a las aplicaciones ser conscientes de NUMA lo que puede redundar en mejoras de rendimiento, la virtualización es una de las cargas que mas puede beneficiarse de NUMA por esta razón Microsoft invirtió en Hyper-V de cara a extraer lo máximo de NUMA.

Gracias a esta arquitectura los procesadores pueden usar la memoria dentro de su nodo NUMA de forma mucho mas rápida que la que esta en otros nodos, esto redunda en un mayor numero de ciclos de reloj disponibles para otras actividades lo que implica un mejor rendimiento del sistema, cuantas mas VMs tiene un servidor de Hyper-V mayores son los beneficios de NUMA.

En sistemas no NUMA todos los procesadores tienen el mismo derecho a acceder a los recursos de memoria e I/O cuantos mas procesadores tienen estos sistemas menos eficiente son en el uso rápido de los recursos.

Una maquina no NUMA funciona así:

Mientras que una NUMA organizara los recursos en nodos como he contado:

La inquietud por NUMA en la virtualización viene cuando una VM necesita recursos de mas de un nodo NUMA debido a que el uso de esos recursos será mas lento que si usa recursos locales a su nodo.

Preocuparse por NUMA no es algo común, muchos administradores no conocen de su existencia, no es algo que debamos hacer en el día a día en una instalación normal, sin embargo en ciertas situaciones entender NUMA puede ayudarnos a comprender por que un sistema no rinde como nos gustaría o como optimizar mejor un host de virtualización.

NUMA es lo suficientemente inteligente como para ser consciente de  por ejemplo agrupar los cores de un mismo procesador en vez de cores de diferentes procesadores.

En procesadores AMD crean un nodo por procesador mientras que en Intel puede variar.

Por ultimo decir, que los nodos NUMA puedes estar contenidos en grupos, cada grupo tiene un máximo de 64 procesadores lógicos (cores o hilos si usas hyperthreading) el numero máximo de grupos es 4 numerados del 0 al 3, en sistemas con menos de 64 procesadores lógicos veras un solo grupo NUMA con los nodos que sean necesarios.

Os voy a explicar NUMA para vuestro conocimiento de Hyper-V, ten en cuenta que en general la penalización de rendimiento por falta de afinamiento de NUMA es muy pequeña.

La optimización de NUMA es especialmente interesante y productiva cuando hablamos de hosts de Hyper-V muy estáticos que normalmente siempre tienen las mismas VMs. En sistemas mas dinámicos optimizar NUMA no es sencillo y en algunos casos no es posible.

Algunos servidores incluyen una alternativa a NUMA llamada SUMA si es tu caso no la actives, Hyper-V y Windows Server se benefician de NUMA, SUMA esta pensada para sistemas que no sean capaces de aprovechar estas capacidades.

Que vamos a ver

• Como saber si mi servidor esta usando NUMA y que nodos tengo
• ¿Por que me tiene que preocupar NUMA en un host de virtualización?
• NUMA y la memoria dinámica
• La afinidad de las VMs a nodos NUMA
• ¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

Como saber si mi servidor esta usando NUMA y que nodos tengo

Una forma de ver los nodos NUMA que tienes y con que recursos cuentan son los contadores de Hyper-V con respecto a NUMA:

 ¿Por que me tiene que preocupar NUMA en un host de virtualización?

Cuando un hilo corre sobre un procesador que esta en el mismo nodo que la memoria a la que quiere acceder entonces el rendimiento es fantástico, cuando por el contrario esta situación no se da, el rendimiento es algo peor, no es el fin del mundo y la mayoría de los sistemas se enfrentan a esta condición a diario sin conocimiento de sus administradores.

Cuantificar esta penalización en un % es muy difícil dado el numero de factores que entran en juego, la cifra depende mucho del tipo de carga, podemos decir que una VM con muchos procesadores y con mucha RAM es mas susceptible de este problema y que en caso de darse, si la VM ejecuta cargas que hacen uso intensivo de operaciones de memoria o de operaciones SMP entonces la VM se vera aun mas afectada.

Los host de virtualización gestionan unas cargas muy dinámicas en cuanto a recursos, una VM puede usar memoria dinámica o en cualquier momento una VM con mas de un procesador puede verse afectada por la imposibilidad de encontrar tiempo libre de tantos procesadores como necesite dentro del mismo nodo NUMA.

En un sistema NUMA, por defecto cada VM tiene un nodo preferido, Hyper-V siempre trata de asignar memoria del mismo nodo a la VM.

Hyper-V establece este nodo preferido cada vez que  la VM arranca, como Hyper-V no puede predecir la carga que la VM tendrá es posible que con el tiempo esta VM requiera recursos que estén en otros nodos y esto conducirá a lo que denominamos fragmentación NUMA.

Desde el performance monitor puedes ver también en que nodo NUMA esta corriendo cada VM y en el contador “Remote physical pages” os dais cuenta de si se esta usando memoria de otros nodos.

NUMA y la memoria dinámica

Aunque NUMA afecta a la red y a los procesadores también, os voy a contar el ejemplo de la memoria dinámica por que es el mas fácil de entender:

Hyper-V siempre tratara de ubicar toda la memoria de una VM en un único nodo NUMA.

Pero si no es posible tendrá que usar memoria de varios nodos NUMA, esto puede pasar en el arranque de una VM, pero la probabilidad aumenta de que pase en ejecución cuando usas memoria dinámica, tu VM seguirá funcionando igual de bien, pero el rendimiento bajara un poquito.

Usar memoria dinámica aumenta las probabilidades de que una VM tenga que repartirse entre varios nodos NUMA lo normal será, insisto que esto no nos preocupe salvo en condiciones muy extremas.

La afinidad de las VMs a nodos NUMA

Es posible configurar que las maquinas virtuales tengan afinidad con un nodo NUMA, obviamente esto es algo que se debe de analizar cautelosamente debido a la cantidad de implicaciones que tiene en la gestión de los recursos. Cuando se cambia el nodo preferido para una VM, es necesario reiniciarla.

¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

En event viewer de los servidores hay eventos indicándote si en algún momento se ha tenido que usar recursos de otro nodo para servir por ejemplo la memoria pedida por una ampliación realizada a través de memoria dinámica. En Hyper-V, desde W2K8R2 tiene la posibilidad de evitar que una VM use recursos de mas de un nodo.

Activar esta opción tiene claras connotaciones como que por ejemplo se reducirá el numero de VMs que podremos correr en el host o se limitara la memoria RAM máxima que pueda tener una VM en función de la que este disponible en el nodo NUMA en la que corra.

Cuando activamos éste parámetro desde el punto de vista de los recursos del host es como si dividieras tu servidor en servidores de virtualización mas pequeños

Ya hemos instalado Exchange Server 2016 sobre una arquitectura on-premise… ahora nos queda darle vida, para ello y utilizando una consola de Power-Shell de Exchange con privilegios de administrador, iremos enseñando a nuestro Exchange como moverse.

Estos son los pasos que yo he ejecutado en un DAG a cuyo servidor los he llamado HOST y HOST2 y al fqdn del dominio público, lo he llamado DOMINIO. Serán esos ítems y algún otro que iré explicando al crear el DAG los que tendréis que modificar para configurar vuestro Multirol Exchange Server 2016 en modo DAG:

Cambio de Service Connection Point (SCP) para clientes internos

Set-ClientAccessServer HOST -AutoDiscoverServiceInternalUri https://DOMINIO/Autodiscover/Autodiscover.xml

Cambio OWA y ECP a AuthIntegrada en lugar de Formularios

Set–OwaVirtualDirectory «HOST\owa (Default Web Site)» -BasicAuthentication $false -FormsAuthentication $false -WindowsAuthentication $true

Ésta acción requiere un iisreset /noforce

Set–EcpVirtualDirectory «HOST\ecp (Default Web Site)» -BasicAuthentication $false -FormsAuthentication $false -WindowsAuthentication $true

De nuevo ésta acción requiere un iisreset /noforce

Importaremos el Certificado Público y pasamos a habilitar su uso para IIS en HOST y en cualquier otro Exchange

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificados\MiCert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

Enable-ExchangeCertificate -Thumbprint Un chorro de números de nuestro certificado -Services IIS

Configuración de InternalURL y ExternalURL para OWA, ECP, OAB, MAPI, ActiveSync, EWS

Set-OwaVirtualDirectory «HOST\owa (Default Web Site)» -InternalUrl https://DOMINIO/owa -ExternalUrl https://DOMINIO/owa
Set-EcpVirtualDirectory «HOST\ecp (Default Web Site)» -InternalUrl https://DOMINIO/ecp -ExternalUrl https://DOMINIO/ecp
Set-OabVirtualDirectory «HOST\oab (Default Web Site)» -InternalUrl https://DOMINIO/oab -ExternalUrl https://DOMINIO/oab
Set-MapiVirtualDirectory «HOST\mapi (Default Web Site)» -InternalUrl https://DOMINIO/mapi -ExternalUrl https://DOMINIO/mapi
Set-ActiveSyncVirtualDirectory «HOST\Microsoft-Server-ActiveSync (Default Web Site)» -InternalUrl https://DOMINIO/Microsoft-Server-ActiveSync -ExternalUrl https://correo.telyco.es/Microsoft-Server-ActiveSync
Set-WebServicesVirtualDirectory «HOST\ews (Default Web Site)» -InternalUrl https://DOMINIO/ews/exchange.asmx -ExternalUrl https://DOMINIO/ews/exchange.asmx

Configuración Outlook Anywhere

Set-OutlookAnywhere «HOST\Rpc (Default Web Site)» -ExternalHostname DOMINIO -InternalHostname DOMINIO -ExternalClientAuthenticationMethod Ntlm -InternalClientAuthenticationMethod Negotiate -SSLOffloading $False -ExternalClientsRequireSsl $True -InternalClientsRequireSsl $True

Configuración Clave

Set-ExchangeServer HOST -ProductKey «XXXXX-XXXXX-XXXXX-XXXXX-XXXXX»

Restart-Service MSExchangeIS

Creación del DAG, Adición de Nodos y configuración DAG

Para completar este paso necesitamos realizar antes algunos pasos previos en nuestra organización o dominio:

• Acceso a un servidor, (File Cluster) al que he llamado HostName, para crear un Recurso Compartido, al que he llamado, «DAGHOST16_FSW»
• Añadimos una entrada fqdn en el DNS de AD y le asignamos una IP del mimo ámbito o vlan en la que tengamos nuestro Exchange. A la que yo he llamado, DAGHOST16.

New-DatabaseAvailabilityGroup -Name DAGHOST16 -WitnessServer (HostName de mi File Share) -WitnessDirectory «H:\RECURSO COMPARTIDO\DAGHOST16_FSW» -DatabaseAvailabilityGroupIpAddresses (10.X.X.X)

Set-DatabaseAvailabilityGroup DAGHOST16 -NetworkCompression Enabled -NetworkEncryption Enabled -DatacenterActivationMode DagOnly

Add-DatabaseAvailabilityGroupServer DAGHOST16 -MailboxServer HOST

Creación, Configuración y Adición de copia de BBDD a la que he llamado ABOGADOS

New-MailboxDatabase -Name ABOGADOS -EdbFilePath E:\Mailbox\Abogados\Abogados.edb -LogFolderPath E:\Mailbox\Abogados\ -Server HOST

Restart-Service MSExchangeIS

Montamos la BD

Mount-Database ABOGADOS

Creamos una quota máxima de 2253 MB sobre los buzones que contendrá la BD Abogados

Set-MailboxDatabase ABOGADOS -ProhibitSendReceiveQuota 2253MB -IssueWarningQuota 1843MB -ProhibitSendQuota 2048MB

Solo si hemos montado un DAG, ejecutaremos el siguiente comando:

Add-MailboxDatabaseCopy ABOGADOS -MailboxServer HOST2

Mover buzones de arbitrajes y admin

New-MoveRequest «SystemMailbox{Otro chorro de números}» -TargetDatabase ABOGADOS
New-MoveRequest «Migration.Mas Numeros» -TargetDatabase ABOGADOS
New-MoveRequest «SystemMailbox{Mas Numeros}» -TargetDatabase ABOGADOS
New-MoveRequest Administrador -TargetDatabase ABOGADOS

Limpieza del BBDD creadas por la instalación de 2016

Remove-MailboxDatabase «Mailbox Database XXXXXXXXXX»

SÓLO SI INTEGRAMOS UC DE LYNC O SfB DE MICROSOFT COMO SOLUCIÓN DE UC

Configuración Lync

New-SettingOverride -Name OWAIMSettings -Server HOST,HOST2 -Component OWAServer -Section IMSettings -Parameters @(«IMServerName=FQDNdeLYNC»,»IMCertificateThumbprint=El de Lync») -Reason «OWA IM Integration»

Set-OwaVirtualDirectory «HOST\owa (Default Web Site)» -InstantMessagingCertificateThumbprint Los numeritos que no te digo -InstantMessagingType Ocs -InstantMessagingServerName FQDN.de.Lync

Get-ExchangeDiagnosticInfo -Server HOST -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Restart-WebAppPool MSExchangeOWAAppPool

Configuración OOS-Exchange

Set-MailboxServer HOST -WacDiscoveryEndpoint https://oos.DOMINIO/hosting/discovery

Creación de subscripción en el servidor de Exchange con el rol de EDGE

New-EdgeSubscription -FileName «C:\Edge16.xml»

Adición de subscripción en HOST de Exchange

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path «C:\Edge16.xml» -Encoding Byte -ReadCount 0)) -Site «MI SITE DE AD»

Certificado Wildcard

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\star_DOMINIO.pfx -Encoding Byte -ReadCount 0)) -Password:(Get-Credential).password

Enable-ExchangeCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Services IIS

Get-ExchangeCertificate

SÓLO SI INTEGRAMOS OWAC (Office Web App)

Configuración OOS

New-OfficeWebAppsFarm -InternalUrl «https://oos.DOMINIO» -ExternalUrl «https://oos.DOMINIO» -CertificateName «DOMINIO» -EditingEnabled:$True

Set-OfficeWebAppsFarm -OpenFromUrlEnabled