Parches acumulativos y KB: qué instaló de verdad un servidor Windows

Desde hace años las actualizaciones mensuales de calidad de Windows se publican como acumulativas: el paquete de un mes incluye las correcciones de los meses anteriores de su cadena. Microsoft las publica el segundo martes de cada mes, el llamado «martes de parches», y cada una lleva un identificador KB. Por eso un servidor al día no necesita tener instalados uno por uno todos los KB de la serie.

La consecuencia para el analista es práctica: el KB que dice faltar un escáner no se compara con la lista de instalados «a ciegas», sino con la cadena. Si el equipo tiene un acumulativo posterior de la misma cadena, lo anterior ya está dentro. Algunos componentes, como .NET Framework en ciertas versiones, se publican en paquetes aparte, y esos sí hay que mirarlos por separado. Abre la tabla reglas_de_lectura de la consola.

El catálogo del equipo de parches tiene una columna reemplaza. En cada fila dice cuál es el KB anterior que ese acumulativo deja sin objeto. Es la cadena de reemplazo: cada acumulativo apunta al del mes previo. Leerla bien permite responder, sin buscar en ningún sitio, si un KB que figura como faltante todavía tiene sentido pedirlo.

Un ejemplo con otros datos: si el catálogo dijera que el KB de noviembre reemplaza al de octubre, y alguien te pregunta por el de octubre, la respuesta útil es el de noviembre. Aplica la misma lectura a la tabla kb_catalogo, que mezcla acumulativos y un paquete de .NET que no pertenece a la cadena.

La build de Windows se escribe con cuatro números separados por puntos. En un servidor con Windows Server 2022, los dos primeros grupos identifican la versión del sistema operativo, y el último, la revisión, sube con cada acumulativo que se instala. Por eso la build que lee el inventario es una segunda evidencia, independiente del nombre del KB: dos servidores con la misma versión del sistema pero distinta revisión están a distancia de uno o varios meses.

Para comparar, se leen los números de izquierda a derecha y el último grupo es el que manda cuando los anteriores coinciden. En la tabla parque aparece la build_leida de cada servidor junto con su último KB instalado, y la columna build_resultante del catálogo dice qué build deja cada acumulativo.

El escáner autenticado compara el equipo con una lista de KB esperados. Algunos escáneres piden un KB concreto sin comprobar si lo reemplaza otro posterior, y el resultado es un hallazgo que no se sostiene. Con la cadena de la tarea 2 y la tabla instalados puedes comprobarlo: si el equipo tiene un KB cuya fila de catálogo reemplaza al que «falta», el hallazgo se descarta como reemplazado y se anota la evidencia.

Mira los tres hallazgos de hallazgos_del_escaner. Para cada uno, cruza el kb_que_dice_faltar con lo que figura instalado en ese host. Uno solo se cae al hacerlo.