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!

Capturando Windows 10 Pro para fábrica de Windows

Me he encontrado con este escenario ya dos veces. Clientes que cuentan con MECM o SCCM necesitan montar una fábrica de Windows para la distribución de imágenes corporativas de Windows 10 sin mucha intervención y disminuyendo el tiempo de espera de usuarios y bajando la carga al equipo de soporte.

Esta operación requiere de preparación de imagen y de una posterior captura. Para que sea una imagen única se ejecuta un proceso que se llama sysprep, que destruye los identificadores de usurio y máquina y permitiendo que se genere uno nuevo por cada distribución.

Todo fantástico. En Winodws 7 funcionaba a la primera y de maravillas. En Windows 10, no.

Con Windows 10 llevaron las Universal Apps. Básicamente son aplicaciones que tienen la interfaz moderna de Windows 10. Microsoft incluye muchas de terceros y propias para mejorar la experiencia del usuario. El problema está en que estas aplicaciones no son compatibles con el proceso de sysprep y hace que fallen. La solución está en eliminarlas a mano y continuar con el proceso.

¿Cómo se identifican?

No existe un listado definido de aplicaciones, porque cambian con cada build de Windows, pero son identificables cuando arroja el error.

El log se encuentra en %windir%\system32\sysprep\panther\setupact.log y %windir%\system32\sysprep\panther\setuperr.log y podrás ver algo como:

SYSPRP Package SpotifyAB.SpotifyMusic_1.148.625.0_x86__zpdnekdrzrea0 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

El problema está en la aplicación Spotify. Para quitarla hay que abrir una sesión de Powershell como administrador y teclear:

Get-AppxPackage *spotify* | Remove-AppxPackage

Santo remedio. Hacer lo mismo con todas que arrojen error.

Feliz 2021.

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!

Certificado autofirmado en IIS

Hola terrícolas.

En la entrega de hoy les vengo a explicar cómo generar un certificado autofirmado para IIS. Esto es válido desde IIS 7.0 hacia arriba. La verdad es que un certificado autofirmado no provee ninguna seguridad para nuestro sitio ni para nuestros visitantes. Lo importante es contar con un certificado de una entidad certificadora local, si el sitio es para consumo local o una entidad externa, como GoDaddy o GlobalSign si nuestro sitio será consumido desde internet.

Para comenzar con la instalación es imperante que el rol de IIS se encuentre instalado. Abrir la consola de administración e ir a Server certificates .

Luego ir a Create Self-Sign Certificate

Completar con la información del certificado

El certificado ya se encuentra creado. Ahora hay que asignarlo a un sitio web. Seleccionaremos el Default web site y nos iremos a bindings.

Solo queda asignar el certificado al sitio. Agregar el binding para el puerto 443 y asignar certificado.

Para probar abrir la URL en un navegador. El resultado esperado es que el sitio de un mensaje de error de seguridad.