Un anillo pausado y olvidado y un piloto solo de informáticos: Windows Update, anillo a anillo

El problema

Los anillos de actualización son temporizadores. El anillo general recibe la actualización diez días después del Patch Tuesday haya ido bien el piloto o no, y el informe que cuenta instalaciones no dice si el despliegue está bajo control. En un mes normal el anillo general arranca con el piloto todavía al 77%; el anillo tardío de la sala de trading se pausó tras una actualización problemática y nadie se acordó de él, así que cinco semanas después lleva dos meses de retraso y la pausa caduca sin que nadie haya decidido qué pasa después; sesenta puestos de trading están en el anillo general y se quedan sin audio en los cascos a la apertura del mercado; un modelo de portátil falla la actualización con el mismo código de error en un tercio de sus equipos; noventa equipos llevan esperando un reinicio desde antes de la fecha límite; una oficina entera deja de sincronizar el mismo día por la VPN; el piloto son nueve informáticos de cada diez; y el porcentaje de equipos con la compilación al día dos semanas después del Patch Tuesday baja tres meses seguidos. No es el seguimiento de cogestión que publiqué hace tiempo, que sigue el estado de cada carga de trabajo, ni la revisión del SLA de vulnerabilidades de hace unos días: sigue una actualización mensual a través de los anillos, y encaja con el calendario de cambios que he publicado hoy, porque promocionar un anillo es un cambio y merece una decisión como cualquier otro.

Qué he hecho

• Anillos y puertas: cada anillo frente a su fecha de oferta, su fecha límite y su periodo de gracia; la puerta entre anillos (el porcentaje del anillo anterior con la compilación, su tasa de fallos, los días desde que se le ofreció, incidentes P1 o P2 abiertos por la actualización y problemas conocidos que bloquean el siguiente anillo); anillos promocionados sin cumplir la puerta; el go/no-go de la siguiente promoción; anillos en pausa; y directivas que se apartan del estándar del anillo.
• Equipos con retraso: sin la actualización pasada la fecha límite y la gracia, con un reinicio pendiente, sin sincronizar (por sede), sin anillo o en dos, en una versión de Windows 11 cerca del fin de servicio, o retenidos por una safeguard hold de la actualización de características.
• Fallos y composición: códigos de error por modelo, equipos que fallan mes tras mes, incidentes asociados a la actualización, puestos de trading fuera del anillo tardío, un piloto al que le faltan los departamentos, modelos y sedes del anillo general, y anillos que no tienen el tamaño previsto.
• Tendencia: el porcentaje con la actualización de cada mes al día 7, 14 y 21 del Patch Tuesday, la mediana de días hasta instalar por anillo y los equipos que van con retraso todos los meses.
• report.html con una línea temporal del mes que muestra la oferta, la fecha límite, la gracia, la pausa y las puertas de cada anillo; rollout-pack.md para la reunión mensual de parches o el CAB, con el go/no-go y una línea para la decisión; CSV de cada área; y un exportador de solo lectura en PowerShell para Microsoft Graph, los informes de Windows Update for Business en Log Analytics y Configuration Manager.

Cómo está hecho

Python solo con la librería estándar. Un equipo tiene la compilación al día cuando la revisión de su versión del sistema es la del Patch Tuesday del mes o posterior; su anillo sale de los grupos o colecciones a los que están asignadas sus directivas, y los equipos en cogestión siguen el despliegue de Configuration Manager cuando la carga de trabajo de Windows Update no ha pasado a Intune; y cada equipo se mide con su propia fecha límite y su gracia, así que uno que aún está dentro de su plazo no cuenta como retrasado. La demo es una empresa inventada con sala de trading y 1.500 equipos con Windows 11 en cuatro ciudades europeas, revisada veinte días después del Patch Tuesday de octubre, con las compilaciones, los KB, las fechas de fin de servicio y los problemas conocidos reales del estado de versiones de Windows, y los problemas puestos a propósito. 13 tests, un runbook para el ciclo mensual y la reunión de parches, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De dirigir la migración a Windows 11 de una oficina con sala de trading; de gestionar Intune y MECM en cogestión, con empaquetado de aplicaciones en SCCM, PDQ y MDT, Endpoint Privilege Management, BitLocker y Microsoft Defender; de años automatizando con PowerShell y Microsoft Graph; y de la gestión de versiones, con su planificación, pruebas, marcha atrás y validación después de cada versión, y del CAB como responsable del proceso de cambios, dando soporte a unos 2.500 usuarios en oficinas europeas. Las lecciones que hay detrás de la herramienta son que el aplazamiento dice cuándo puede recibir un anillo la actualización y solo una puerta dice si debe; que una pausa es un reloj que se acaba solo; que el anillo tardío solo protege a los equipos que de verdad están en él; que un piloto de informáticos prueba las aplicaciones de informática; que una sede entera sin sincronizar es la red, no los usuarios; que un código de error en un modelo es una configuración base que se arregla una vez, no equipos que se reparan uno a uno; que una actualización instalada que espera un reinicio no protege nada; y que la medida de verdad es el porcentaje con la compilación al día 14 y 21, mes tras mes.

Siguientes pasos

• Ejecutar la exportación y la revisión de forma programada después del Patch Tuesday y antes de cada promoción, y publicar la puerta en el canal de parches.
• Leer las compilaciones y los problemas conocidos desde la API de Windows Updates de Microsoft Graph en lugar de copiarlos.
• Añadir las actualizaciones de controladores y firmware por modelo como una categoría propia.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.