Windows update rings: gates and go/no-go

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.

The problem

Update rings are timers. The broad ring is offered the update ten days after Patch Tuesday whether the pilot went well or not, and the report that counts installs does not say whether the rollout is under control. In a typical month the broad ring starts with the pilot still at 77%; the late ring for the trading floor was paused after a bad update and forgotten, so five weeks later it is two months behind and the pause expires with nobody deciding what happens next; sixty trading desktops sit in the broad ring and lose their headset audio at the market open; one laptop model fails the update with the same error code on a third of its devices; ninety devices have been waiting for a restart since before the deadline; a whole office stops checking in on the same day because of the VPN; the pilot is nine IT engineers out of ten; and the share of devices on the build two weeks after Patch Tuesday falls three months in a row. This is not the co-management tracker I published a while ago, which follows the state of each workload, nor the vulnerability SLA review of a few days ago: it follows one monthly update through the rings, and it pairs with the change calendar I published today, because a ring promotion is a change and should get a decision like any other.

What I built

Rings and gates: each ring against its offer date, deadline and grace; the gate between rings (the previous ring's share on the build, its failure rate, the days since it was offered, open P1 or P2 incidents on the update, known issues that block the next ring); rings promoted without a met gate; the go/no-go for the next promotion; paused rings; and policies that drift from the ring standard.
Devices behind: past the deadline and grace without the update, with a restart pending, not checked in (by site), in no ring or in two, on a Windows 11 version close to its end of servicing, or under a feature update safeguard hold.
Failures and composition: error codes by model, devices failing month after month, incidents tagged to the update, trading desktops outside the late ring, a pilot that misses the departments, models and sites of the broad ring, and rings off their target size.
Trend: the share on each month's update by day 7, 14 and 21 after Patch Tuesday, the median days to install by ring, and the devices behind every month.
report.html with a timeline of the month showing each ring's offer, deadline, grace, pause and gates; rollout-pack.md for the monthly patch meeting or the CAB, with the go/no-go and a decision line; CSVs for every area; and a read-only PowerShell exporter for Microsoft Graph, the Windows Update for Business reports in Log Analytics and Configuration Manager.

How it is built

Python with the standard library only. A device is on the build when the revision in its OS version is the month's Patch Tuesday revision or later; its ring comes from the groups or collections its policies are assigned to, with co-managed devices following the Configuration Manager deployment when the Windows Update workload has not moved to Intune; and each device is judged against its own deadline and grace, so a device that is still inside its window is not counted as behind. The demo is a made-up firm with a trading floor and 1,500 Windows 11 devices in four European cities, reviewed twenty days after the October Patch Tuesday, with the real builds, KB numbers, end of servicing dates and known issues from Windows release health and the problems placed on purpose. 13 tests, a runbook for the monthly cycle and the patch meeting, and a GitHub Actions workflow that runs the tests and rebuilds the demo data and the screenshot.

What I learned

From leading the Windows 11 migration of an office with a trading floor; from running Intune and MECM in co-management, with application packaging in SCCM, PDQ and MDT, Endpoint Privilege Management, BitLocker and Microsoft Defender; from years of automation with PowerShell and Microsoft Graph; and from release management, with its planning, testing, rollback and validation after each release, and the CAB as change process owner, supporting about 2,500 users across European offices. The lessons behind the tool are that a deferral says when a ring can get the update and only a gate says whether it should; that a pause is a clock that runs out on its own; that the late ring only protects the devices that are actually in it; that a pilot of IT staff tests IT's applications; that a whole site going quiet is the network, not the users; that one error code on one model is a baseline to fix once, not devices to repair one by one; that an installed update waiting for a restart protects nothing; and that the real measure is the share on the build at day 14 and 21, month after month.

Next steps

Run the export and the review on a schedule after Patch Tuesday and before each promotion, and post the gate to the patch channel.
Read the builds and known issues from the Windows Updates API in Microsoft Graph instead of copying them.
Add driver and firmware updates by model as a category of their own.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →