WSUS y MECM

Hola gente linda! Hoy vamos a hablar sobre el funcionamiento de WSUS y su integración con MECM. No hablaré sobre la implementación, porque es un asunto super documentado en muchos rincones de internet.

Para partir, WSUS es una aplicación web que corre sobre IIS, tradicionalmente sobre el puerto 8530, que se conecta al servicio de Microsoft Update para descargar actualizaciones según el criterio definido. Estos criterios pueden ser: categorías, producto, fecha, estado, etc. Posteriormente, estas actualizaciones se distribuyen a equipos definidos. Si la implementación es sola, se configura mediante GPO para equipos que estén dentro de la red corporativa. Para equipos que no pertenezcan al dominio, se puede configurar una política local para que se actualicen contra el WSUS local y no internet.

Instalación

  • Considerar una máquina exclusiva para el servicio y una unidad de disco aparte para el almacenamiento de las actualizaciones.
  • Utilizar un servidor SQL Server externo para el almacenamiento de SUSDB. Puede ser un SQL Server Standard, incluso un Express. El uso de WID no es tan manejable y más complejo para la ejecución de mantenimiento. WID es un SQL Server hiper mega recortado y no tiene capacidades para administración acabada.
  • Si la organización tiene una extensión geográfica considerable, utilizar entidades secundarias para que vayan a sincronizar contra el principal. De este modo se ahorra en ancho de banda internacional. Para esto se requiere una buena organización de Active Directory.
  • Al momento de instalar se debe ajustar los parámentros de uso de memoria y CPU en el Application Pool para que el servicio no se vaya de espalda.

Uso y mantenimiento

  • Ejecutar plan de mantenimiento periodicamente.
  • Instalar herramientas para la visualización de reportes (Reporting Services Viewer y SQL Server CLR Types.)

Integración con MECM

  • Microsoft Endpoint Configuration Manager ofrece un rol llamado Software Update Point para manejar las actualizaciones de WSUS. Básicamente, este sol se conecta a WSUS y descarga las actualizaciones.
  • Una vez instalado el rol SUP NO se debe usar la consola de WSUS para operar. Solo para troubleshooting.
  • Revisión constante del estado de los componentes y de los log. La lectura de log es clave: WCM.log, wsyncmgr.log y WSUSCtrl.log

WSUS + MECM + SSL

  • Les comenté más arriba que es un serivio que funciona sobre HTTP. Si se agrega una capa de seguridad, funcionaría sobre HTTPS por el puerto 8531. Es necesario configurar el sitio en IIS y certificado correspondiente.
  • En la integración de ambas plataformas, corre la misma regla de no usar la consola de WSUS.
  • Eso si, siempre hay que estar atento a cuál es el origen. Siempre debe ser Microsoft Update (en el caso que no tengamos otro WSUS en la red). Si esta configuración toma cursos extraños, como por ejemplo, que se cambie de la nada o después de una sincronización, reiniciar website, servicio IIS y si vuelve en lo mismo, reiniciar la máquina.
  • Cualquier tarea automatizada de matenimiento que se quiera ejecutar, especialmente las que se realizan por Powershell, indicar el FQDN o el nombre de la máquina. El certificado fue configurado para la máquina y no para localhost. De esta forma se asegura la conexión.

Como siempre, recomiendo mantener respaldos actualizados y estar atentos a las vulnerabilidades encontradas y puntos de mejoras.

Chau!

Reflexiones sobre SQL Server

Para los que no lo conocen, SQL Server es el gestor de bases de datos relacionales de Microsoft. Tiene parecidos con todos los otros motores de otras marcas, gratuitos o pagados, pero tiene chichecitos propios que lo hacen atractivo. Es un producto al cual le tengo bastante cariño y he seguido sus avances a pesar que ya no trabajo directamente con él.

No obstante, últimamente por temas laborales me ha tocado interactuar bastante con él en distintos clientes y, en consecuencia, escenarios.

En este artículo pretendo compartir algunas experiencias relevante recogidas en el trabajo con clientes.

Always On

Esta es una tecnología de alta disponibilidad y recuperación de desastres, que aparece por primera vez en la versión 2012 y que ha ido evolucionando mejorando la cantidad de nodos síncronos permitidos, entre otras cosas. Viene junto a la edición Enterprise, pero hay uno en la edición Standard, pero que no tiene todas las capacidades que la incluida en Enterprise, por lo tanto, si se dispone de los medios, presupuesto, hardware y licencias, hay que usarla.

Las máquinas virtuales son geniales. La idea de optimizar el espacio, optimizar recursos y licenciamiento hace que hoy todo el mundo tenga máquinas virtuales para la mayoría de los escenarios. SQL Server puede correr perfectamente en máquinas virtuales. Eso si, se recomienda que los archivos de datos, log y tempdb queden en discos distintos y en ejes de discos distintos. Me refiero a que los discos duros de las máquinas virtuales son archivos que el hipervisor los interpreta como disco y se los presenta a la máquina virtual como un disco duro.

Volviendo al tema, Always On puede correr sobre máquinas virtuales, pero para conservar la esencia recomiendo lo siguiente:

  • Los nodos de Always On deben estar en host físico distinto. En lo posible en distintos rack, con alimentación eléctrica independiente y conectado a otro switch, en modalidad de multi subnet. El motivo es simple: si se cae el host físico completo, está el otro host que almacena los otros nodos. Si se cae el rack completo, está el otro.
  • Se puede hacer una extensión de Always On hacia un ambiente IaaS en Azure. Esto implica la instalación de un controlador de dominio en la nube. No sirve Azure Active Directory. Instalar el nodo de SQL Server y usar un load balancer. Además de configurar una VPN S2S y configurar reglas de firewall y network security group, según corresponda. Importante que las redes se deben ver, tanto en la nube como la red local. El load balancer debe estar configurado con el puerto de la instancia de SQL Server en Azure, debe ser local y tener una dirección ip local. El listener local se debe configurar con la red y la dirección ip del load balancer. Es él quien hará la «magia» al momento de hacer failover. Para más información sobre el listener leer: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15
  • Las versiones deben ser iguales y con el mismo nivel de parchado.
  • La autenticación integrada Windows la encuentro más segura si se está en un dominio. Sino, usar la de SQL Server.
  • NUNCA usar el usuario sa. Es como usar la cuenta administrator de un dominio o un root en Linux. Las razones son más que obvias.
  • Las aplicaciones pueden correr perfectamente en un sistema Linux. Lo importante es que el servidor debe tener configurado el DNS Suffix y debe estar apuntando al servidor DNS del dominio de Active Directory.
  • NUNCA configurar el listener en la tabla de hosts del servidor Linux o Windows. Para eso está el DNS.

SQL Server en dominio

Es muy común que SQL Server se instale en un dominio para aprovechar las características de administración, seguridad e integración con otras plataformas de monitoreo como System Center Operations Manager.

En el caso que este sea el escenario, recomiendo lo siguiente:

  • Iniciar la instalación con una cuenta de dominio que tenga privilegios de administrador local sobre el servidor. Una cuenta de administrador de dominio no es necesaria.
  • Idealmente no cambiar el nombre del servidor. En caso de hacerlo, configurar el SQL Server para que adopte el nuevo cambio.
  • Siempre usar una cuenta de servicio que esté en el dominio. Esto es para la seguridad del dominio y no tener problemas con los SPN. En caso de llegar a tener algún problema con estos usar la herramienta Microsoft Kerberos Configuration Manager for SQL Server Esta herramienta no nos hará perder el tiempo y generará los scripts necesarios, o en caso de tener permisos de administración sobre el dominio, hará los cambios. Un SQL Server con un SPN mal configurado provocará que las aplicaciones no puedan hacer uso del servicio a pesar que esté arriba.

Dos puntos importantes que no cabían arriba son:

  • Documentación al día: modelos, topologías, inventarios, etc.
  • Actualizaciones al día.

Eso. No sé que más les puedo decir. Cuiden sus motores de base de datos.

Chau!