Encontrar y eliminar actualizaciones antiguas de Windows (de forma segura) con PowerShell

Cómo las actualizaciones de Windows realmente consumen disco

Cuando la gente dice “las actualizaciones de Windows están ocupando espacio”, generalmente se refieren a una de cuatro cosas:

• El almacén de componentes (WinSxS): el verdadero peso pesado. Almacena componentes y múltiples versiones para servicing y reversión. No se puede “borrar” simplemente, porque está entrelazado con el servicing stack.
• La caché de actualizaciones (comúnmente C:\Windows\SoftwareDistribution\Download): descargas transitorias y staging. Normalmente es seguro limpiar si primero detienes los servicios.
• Caché de Delivery Optimization: intercambio peer-to-peer y caché local para contenido de Windows Update. Útil en flotas; molesto en servidores individuales con volúmenes del sistema pequeños.
• Artefactos antiguos del SO como Windows.old tras actualizaciones de funciones (más orientado a clientes, pero aparece en servidores si haces actualizaciones in-place).

La matiz operativa clave: uso de disco no es lo mismo que espacio recuperable. WinSxS puede parecer enorme, pero una gran parte está hardlinked en el SO y aplicaciones. Borrar lo “equivocado” no reducirá el uso—y podría romper el servicing.

Por eso el flujo de trabajo es: medir correctamente, identificar en qué categoría estás, elegir el mecanismo de limpieza de menor riesgo (preferir las herramientas de servicing integradas) y validar con logs y un ciclo de actualización posterior a la limpieza.

Guion rápido de diagnóstico

Cuando la unidad C: está dando la alarma y necesitas respuestas rápido, no vayas a hacer espeleología. Haz esta secuencia:

1) Confirma que el problema es real y local

• Revisa espacio libre y tasa de crecimiento. Si el disco es un LUN thin-provisioned, confirma que no sea un pánico del lado del almacenamiento disfrazado de “actualizaciones de Windows”.
• Confirma qué volumen está afectado: volumen del SO, volumen de datos, o una partición de recuperación pequeña a la que alguien asignó una letra de unidad (sí, pasa).

2) Identifica el directorio que más consume

• ¿Es WinSxS? ¿SoftwareDistribution? ¿Una carpeta de volcados? ¿Logs? ¿Una aplicación fuera de control? No puedes arreglar lo que te niegas a medir.

3) Decide la ruta de limpieza

• Si WinSxS es grande: usa la limpieza del almacén de componentes con DISM. No borres manualmente.
• Si SoftwareDistribution es grande: detén servicios, borra la caché, reinicia servicios.
• Si Delivery Optimization es grande: borra la caché de DO y ajusta la política.
• Si existe Windows.old: elimina mediante herramientas de limpieza soportadas, no con el Explorador.

4) Valida la salud del servicing antes y después

• Ejecuta comprobaciones de salud con DISM. Si el almacén de componentes está corrupto, la limpieza no se comportará como esperas.
• Después de la limpieza, ejecuta un ciclo de detección/instalación de actualizaciones (o al menos un escaneo) para confirmar que no rompiste Windows Update.

Datos interesantes y contexto histórico (para que dejes de adivinar)

1. WinSxS no es una “caché”. Es el almacén de componentes de servicing introducido para resolver el “DLL hell” y permitir un servicing fiable. Está concebido para ser grande.
2. El Explorador “miente” (en cierto modo) sobre el tamaño de WinSxS. Muchos archivos están hardlinked; contarlos como separados hace que la carpeta parezca más grande que el consumo real en disco.
3. DISM reemplazó a herramientas de servicing más antiguas. El cambio hacia DISM refleja que Windows avanzó a un servicing basado en componentes en todas las ediciones y roles.
4. Las actualizaciones acumulativas cambiaron el juego de limpieza. Los rollups mensuales y las actualizaciones acumulativas reducen la fragmentación de parches, pero pueden incrementar el staging y el footprint de rollback a corto plazo.
5. Existen Servicing Stack Updates (SSU) porque el servicing necesita servicing. Si rompes el stack, las actualizaciones se vuelven poco fiables o imposibles.
6. Windows Update usa múltiples servicios. Limpiar cachés sin detener servicios deja archivos bloqueados e inconsistencias—como intentar cambiar una rueda mientras conduces.
7. Delivery Optimization se diseñó para eficiencia de ancho de banda. En un servidor único, a menudo se comporta como un impuesto de disco que no aprobaste.
8. La limpieza del almacén de componentes puede eliminar la capacidad de desinstalar. Algunos modos de limpieza descartan componentes superseded intencionalmente; esa es una decisión de riesgo, no un “botón de espacio libre”.
9. Las actualizaciones antiguas suelen persistir para garantizar la reversión. El sistema conserva lo necesario para revertir un parche malo o para satisfacer grafos de dependencias.

Un modelo de seguridad: qué es seguro borrar y qué no

Dibujemos una línea entre “seguro con procedimiento” y “limitante para la carrera”.

Generalmente seguro (cuando sigues los pasos correctos)

• Caché de descarga de SoftwareDistribution (detén los servicios de WU primero). Estás eliminando instaladores descargados y contenido temporal, no actualizaciones instaladas.
• Caché de Delivery Optimization (limpia vía cmdlets/ajustes soportados). Estás eliminando payloads cacheados, no componentes del sistema.
• Archivos temporales y logs de CBS (con política de retención). Los logs no son sagrados; solo son útiles si aún puedes escribir nuevos.
• Windows.old (después de confirmar que no vas a revertir). Usa herramientas de limpieza soportadas para que permisos y puntos de reparse no te compliquen.

Seguro sólo mediante herramientas de servicing (DISM), no borrando

• WinSxS/almacén de componentes. Usa las operaciones de análisis/limpieza de DISM. La eliminación manual es la forma de crear una máquina que “funciona” hasta la próxima ventana de parches.

No toques a menos que disfrutes de outages extraños

• Podas manuales de C:\Windows\WinSxS. No.
• Limpieza de C:\Windows\Installer sin herramientas de inventario MSI. Borrar archivos MSI/MSP al azar rompe reparación/desinstalación y a veces actualizaciones.
• Hacks de registro para “desactivar actualizaciones” como estrategia de espacio. Eso no es limpieza; es deuda técnica.

Idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla; diseña y opera como si el fallo fuera normal. Eso incluye tus scripts de limpieza—supón interrupciones, reinicios y operaciones a medio hacer.

Broma #1: Borrar cosas al azar en C:\Windows es como “optimizar” un paracaídas quitándole las correas—técnicamente más ligero, operativamente emocionante.

Tareas prácticas (comandos, salidas, decisiones)

Estas son tareas reales que puedes ejecutar como administrador. Cada una tiene: un comando, lo que significa la salida y la decisión que tomas.

Nota sobre bloques de código: El formato del prompt abajo muestra una etiqueta tipo Linux, pero los comandos son de Windows PowerShell y se ejecutarán en PowerShell. Es una restricción de formato, no una elección de estilo de vida.

Tarea 1: Comprobar espacio libre en todos los volúmenes (línea base)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Select DriveLetter,FileSystemLabel,SizeRemaining,Size | Format-Table -Auto"
DriveLetter FileSystemLabel SizeRemaining        Size
----------- -------------- -------------        ----
C           OS             18.42 GB      127.99 GB
D           Data           512.10 GB     1023.99 GB

Qué significa: Confirma que la presión está en C:, no en un volumen de datos. También te dice si estás con “solo 18 GB” (manejable) frente a “300 MB” (triage urgente).

Decisión: Si C: está por debajo de ~5–10% libre, evita operaciones de larga duración que pueden crear archivos temporales (incluyendo algunas instalaciones de actualización) hasta recuperar espacio.

Tarea 2: Identificar rápidamente los principales consumidores de disco (sin herramientas de terceros)

cr0x@server:~$ powershell -NoProfile -Command "$paths='C:\Windows\WinSxS','C:\Windows\SoftwareDistribution','C:\Windows\Temp','C:\Windows\Logs','C:\ProgramData\Microsoft\Windows\DeliveryOptimization'; foreach($p in $paths){ if(Test-Path $p){ $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object -Property Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2)} } } | Sort-Object GB -Descending | Format-Table -Auto"
Path                                                        GB
----                                                        --
C:\Windows\WinSxS                                          12.84
C:\Windows\SoftwareDistribution                             6.10
C:\ProgramData\Microsoft\Windows\DeliveryOptimization        3.45
C:\Windows\Logs                                             1.12
C:\Windows\Temp                                             0.78

Qué significa: Obtienes una vista direccional rápida. El número de WinSxS aquí es una suma ingenua (los hardlinks pueden inflarlo), pero SoftwareDistribution/DO están más cerca de ser “reales”.

Decisión: Si SoftwareDistribution y DO son grandes, a menudo puedes recuperar espacio con riesgo mínimo antes de tocar la limpieza del almacén de componentes.

Tarea 3: Obtener el tamaño real recuperable del almacén de componentes (análisis DISM)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /AnalyzeComponentStore"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
Component Store (WinSxS) information:

Windows Explorer Reported Size of Component Store : 12.8 GB
Actual Size of Component Store : 8.9 GB
Shared with Windows : 6.7 GB
Backups and Disabled Features : 1.9 GB
Cache and Temporary Data : 0.3 GB

Date of Last Cleanup : 2025-12-02 03:12:44
Number of Reclaimable Packages : 4
Component Store Cleanup Recommended : Yes
The operation completed successfully.

Qué significa: “Actual Size” está más cerca del consumo real en disco. “Reclaimable Packages” y “Cleanup Recommended” te indican si DISM espera ganancias significativas.

Decisión: Si la limpieza está recomendada, programa una limpieza del almacén de componentes durante una ventana de mantenimiento, porque puede usar CPU/disco intensivamente y a veces requiere un reinicio.

Tarea 4: Validar que el almacén de componentes esté sano antes de la limpieza (escaneo DISM)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /ScanHealth"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
No component store corruption detected.
The operation completed successfully.

Qué significa: Es menos probable que encuentres fallos extraños durante la limpieza o futuras actualizaciones.

Decisión: Si se detecta corrupción, prioriza la reparación (/RestoreHealth) antes de empezar a borrar cachés. Corrupción más limpieza es la receta para máquinas inactualizables.

Tarea 5: Reparar el servicing si es necesario (DISM restore health)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /RestoreHealth"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The restore operation completed successfully.
The operation completed successfully.

Qué significa: DISM reparó el almacén de componentes usando fuentes locales o Windows Update.

Decisión: Si DISM no puede encontrar fuentes, necesitarás una fuente alternativa (ISO montada o fuente de reparación configurada). No procedas con “limpieza” si el almacén está roto; solo empeorarás la siguiente actualización.

Tarea 6: Hacer una limpieza segura del almacén de componentes (modo recomendado por defecto)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /StartComponentCleanup"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The operation completed successfully.

Qué significa: Elimina componentes superseded cuando es seguro. Este es el modo de limpieza “normal” que mantiene el sistema soportable.

Decisión: Usa esto primero. Es el mejor equilibrio entre espacio recuperable y mantener rutas de reversión para actualizaciones recientes.

Tarea 7: Modo agresivo (con consecuencias): reset base

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The operation completed successfully.

Qué significa: Descarta la capacidad de desinstalar actualizaciones superseded. Te comprometes con la línea base actual.

Decisión: Haz esto solo cuando (a) tengas fuerte confianza en la estabilidad de parches, (b) hayas probado planes de reversión (snapshots de VM, imágenes o reconstrucción rápida), y (c) la presión de disco sea crónica. No es una actividad de “viernes por la tarde”.

Tarea 8: Comprobar si hay un reinicio pendiente (antes de interpretar resultados)

cr0x@server:~$ powershell -NoProfile -Command "$p=@(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
); $p | ForEach-Object { [pscustomobject]@{Key=$_;Exists=Test-Path $_} } | Format-Table -Auto"
Key                                                                                               Exists
---                                                                                               ------
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending           False
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired         True

Qué significa: Un reinicio pendiente puede impedir que la limpieza se finalice y puede retener espacio en disco como rehén.

Decisión: Si hay un reinicio pendiente, planea el reinicio. Muchas quejas de “la limpieza no funcionó” son en realidad “la limpieza está esperando un reinicio”.

Tarea 9: Medir el tamaño de la caché de SoftwareDistribution y decidir si vale la pena limpiar

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\Windows\SoftwareDistribution\Download'; $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2);Files=(Get-ChildItem $p -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object).Count} | Format-List"
Path  : C:\Windows\SoftwareDistribution\Download
GB    : 5.86
Files : 1432

Qué significa: Esto es típicamente recuperable, especialmente si los archivos son antiguos y las actualizaciones ya están instaladas.

Decisión: Si son varios GB y necesitas espacio ahora, límpialo de forma segura (tarea siguiente). Espera que Windows vuelva a descargar el contenido necesario más adelante.

Tarea 10: Limpiar SoftwareDistribution de forma segura (detener servicios, borrar, iniciar)

cr0x@server:~$ powershell -NoProfile -Command "Stop-Service wuauserv,bits,cryptsvc -Force; Start-Sleep 2; Remove-Item 'C:\Windows\SoftwareDistribution\Download\*' -Recurse -Force -ErrorAction SilentlyContinue; Start-Service cryptsvc,bits,wuauserv; Get-Service wuauserv,bits,cryptsvc | Select Name,Status | Format-Table -Auto"
Name      Status
----      ------
wuauserv   Running
bits      Running
cryptsvc  Running

Qué significa: Los servicios se reinician y la caché de descarga se borra. Si algunos archivos estaban bloqueados, pueden quedar; está bien si la mayoría se eliminó.

Decisión: Vuelve a comprobar espacio libre. Si recuperaste suficiente, para aquí. No apiles operaciones riesgosas cuando la victoria fácil la resolvió.

Tarea 11: Inspeccionar la caché de Delivery Optimization y limpiarla

cr0x@server:~$ powershell -NoProfile -Command "Get-DeliveryOptimizationStatus | Select-Object -First 3 | Format-List"
SourceURL            : 
FileSize             : 0
BytesFromCacheServer : 0
BytesFromPeers       : 0
BytesFromHttp        : 0
Status               : Idle

Qué significa: El estado no muestra directamente el tamaño de caché; más bien indica transferencias actuales. Para el tamaño de caché, mide el directorio y/o usa ajustes de limpieza.

Decisión: Si la carpeta DO es grande y no te beneficia el peer caching en servidores, bórrala y considera límites por política.

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache'; if(Test-Path $p){ $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2)} } | Format-List"
Path : C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache
GB   : 3.31

cr0x@server:~$ powershell -NoProfile -Command "Remove-Item 'C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache\*' -Recurse -Force -ErrorAction SilentlyContinue; 'cache-cleared'"
cache-cleared

Qué significa: La caché se elimina. Se volverá a poblar si DO permanece habilitado y ocurren actualizaciones.

Decisión: Si esto vuelve a aparecer, aplica un límite por política en lugar de ejecutar un trabajo diario de borrado que luche contra el SO.

Tarea 12: Encontrar actualizaciones instaladas y sus fechas de instalación (para decisiones de reversión)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID,InstalledOn,Description | Format-Table -Auto"
HotFixID  InstalledOn Description
--------  ----------- -----------
KB5034121 12/12/2025  Update
KB5033371 11/15/2025  Security Update
KB5032007 10/10/2025  Security Update

Qué significa: Una vista rápida de la actividad reciente de parches. No es perfecta para todos los tipos de actualizaciones, pero es una lente útil para el operador.

Decisión: Si el último parche fue muy reciente y estás en el “período de monitoreo”, evita /ResetBase hasta estar seguro de que no necesitarás una ruta de desinstalación.

Tarea 13: Confirmar que los servicios de Windows Update no estén inestables (la limpieza puede enmascarar problemas reales)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,bits,DoSvc | Select Name,StartType,Status | Format-Table -Auto"
Name    StartType Status
----    --------- ------
wuauserv Manual    Running
bits    Manual    Running
DoSvc   Manual    Running

Qué significa: Los servicios están en estados esperados. Si están Disabled, alguien “solucionó” las actualizaciones desactivándolas.

Decisión: Si están Disabled inesperadamente, corrige la política/ajuste. Limpiar cachés no ayudará si el motor de actualización está muerto.

Tarea 14: Validar archivos del sistema (SFC) cuando las actualizaciones se comportan raro

cr0x@server:~$ powershell -NoProfile -Command "sfc.exe /scannow"
Beginning system scan.  This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.

Qué significa: La integridad es buena. Si informa reparaciones, eso puede explicar fallos de actualización y churn extraño de disco.

Decisión: Si SFC encuentra corrupción repetidamente, tienes un problema más profundo (almacenamiento, AV, pipeline de imágenes defectuoso). No lo parchees con scripts de limpieza.

Tarea 15: Medir antes/después y registrar el delta (porque los humanos olvidan)

cr0x@server:~$ powershell -NoProfile -Command "$before=(Get-Volume -DriveLetter C).SizeRemaining; dism.exe /Online /Cleanup-Image /StartComponentCleanup | Out-Null; $after=(Get-Volume -DriveLetter C).SizeRemaining; [pscustomobject]@{BeforeGB=[math]::Round($before/1GB,2);AfterGB=[math]::Round($after/1GB,2);FreedGB=[math]::Round(($after-$before)/1GB,2)} | Format-List"
BeforeGB : 18.42
AfterGB  : 21.07
FreedGB  : 2.65

Qué significa: La limpieza recuperó espacio ahora, no “quizá más tarde.” Si no liberó nada, aprendiste sin adivinar.

Decisión: Usa el delta para elegir siguientes acciones: borrar cachés, mover logs, ampliar disco o cambiar la cadencia de parcheo.

Tres microhistorias del mundo corporativo (y lo que enseñan)

Microhistoria 1: El incidente causado por una suposición equivocada

Una gran aplicación interna empezó a fallar comprobaciones de salud después del Patch Tuesday. No estaba caída por completo; estaba “mayormente arriba”, que es el tipo de rotura que consume más tiempo. Algunos nodos del pool estaban bien, otros en bucle de reinicio durante mantenimiento, y el on-call veía cómo el balanceador de carga se quedaba sin targets saludables lentamente.

La causa raíz no fue la actualización en sí. Fue la limpieza: un ingeniero supuso que la carpeta WinSxS era “solo actualizaciones antiguas” y lanzó un script para borrar “subcarpetas grandes bajo C:\Windows” para recuperar espacio. Funcionó en un par de servidores no críticos, así que se promovió a “estándar”. Luego golpeó sistemas en medio del servicing.

Las máquinas no murieron de inmediato. Esa fue la trampa. Funcionaron hasta que la siguiente actualización acumulativa intentó preparar componentes y reconciliar dependencias. El servicing falló, los rollbacks se aplicaron parcialmente y ahora los nodos tenían estados de componentes desajustados. El bucle de reinicio no fue un clásico pantallazo azul; fue Windows intentando completar operaciones de servicing fallidas y perdiendo la pelea.

La solución no fue ingeniosa: restaurar desde snapshots conocidos para los nodos peores, y para los recuperables, reparar el almacén de componentes con DISM y reaplicar actualizaciones en una ventana controlada. La política de “limpieza” se reemplazó por una regla aburrida: si quieres WinSxS más pequeño, usas DISM, o no lo tocas.

Lección: La suposición equivocada suele ser sobre qué representa un directorio. En el servicing de Windows, las carpetas no son solo carpetas. Son contratos.

Microhistoria 2: La optimización que se volvió en contra

Otra compañía tenía una flota de VMs Windows Server con discos del sistema pequeños. Alguien fue proactivo y creó una tarea programada: cada noche detenía servicios de Windows Update, limpiaba SoftwareDistribution, limpiaba caché de Delivery Optimization, ejecutaba DISM cleanup y luego reiniciaba. Los gráficos de disco se veían geniales. El ingeniero fue elogiado por “mantener los servidores limpios”.

Luego la conformidad de parches empezó a fallar. Las actualizaciones tardaban más. Algunos servidores perdieron sus ventanas de mantenimiento porque pasaban la primera mitad re-descargando contenido que acababan de borrar. El ancho de banda en algunos sitios se disparó justo cuando corrían los trabajos nocturnos. El equipo de WAN se involucró, lo cual nunca es una reunión divertida.

El revés fue sutil: limpiar cachés cada noche eliminó contenido local útil y forzó descargas repetidas. Ejecutar DISM nightly también compitió con otras tareas intensivas en disco como backups y rotación de logs, estirando las ventanas de mantenimiento. Y el reinicio forzado—a fin de “finalizar la limpieza”—a veces chocaba con procesos por lotes de la aplicación que se programaban en otra cadencia de reinicio.

El nuevo enfoque fue más lento, más seguro y más barato: limpiar SoftwareDistribution solo cuando exceda un umbral o cuando fallen las actualizaciones; limitar Delivery Optimization por política; ejecutar DISM cleanup mensual tras la verificación de parches; reiniciar solo cuando haya pending. El disco se mantuvo sano, el parcheo fue más rápido y el gráfico de WAN dejó de parecer un sismógrafo.

Lección: La sobreautomatización sigue siendo automatización. Si automatizas un comportamiento equivocado, escalas el dolor.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Durante una emergencia de seguridad, un equipo tuvo que parchear un lote de servidores con casi nada de espacio libre. Los sistemas eran estables pero ajustados—volúmenes OS pequeños, logging agresivo y meses de “lo arreglaremos después”. Todos esperaban una noche larga.

Un ingeniero tenía el hábito aburrido: cada mes, después de parchear, capturaba una línea base del uso de disco por buckets—WinSxS (vía DISM analyze), tamaño de SoftwareDistribution, tamaño de caché DO y espacio libre total—y lo guardaba con el registro de cambio. Nada sofisticado, solo un CSV pequeño y una nota.

Esa historia les permitió actuar rápido. Pudieron ver que WinSxS no era inusualmente recuperable, pero SoftwareDistribution había crecido tras un ciclo de actualización fallido dos semanas antes. Limpiaron la caché de descarga de forma segura, obtuvieron el margen suficiente para instalar el parche de emergencia y evitaron movimientos agresivos de /ResetBase que habrían eliminado opciones de reversión durante un parche arriesgado.

Después de la emergencia, arreglaron el problema real: una fuente de actualización mal configurada que causaba descargas y fallos repetidos. La práctica “aburrida” de baseline no solo salvó disco—ahorró tiempo de decisión cuando el tiempo era el recurso escaso.

Lección: Las líneas base parecen burocráticas hasta que se convierten en el camino más corto hacia la decisión correcta.

Errores comunes: síntoma → causa raíz → solución

1) “WinSxS tiene 20 GB, así que lo borraré”

Síntoma: Fallos de servicing, actualizaciones acumulativas fallan, máquinas atascadas en “configurando actualizaciones” al reiniciar.

Causa raíz: La eliminación manual rompe hardlinks y manifiestos de componentes.

Solución: Deja de hacer limpieza manual. Repara con DISM /RestoreHealth, luego usa /StartComponentCleanup. Restaura desde snapshot si el servicing es irreparable.

2) “Limpié SoftwareDistribution pero no recuperé espacio”

Síntoma: El directorio sigue grande o el espacio libre sin cambios.

Causa raíz: Los servicios seguían en ejecución; archivos bloqueados. O la presión de disco está en otra parte (logs, volcados, datos de la app).

Solución: Detén wuauserv, bits y cryptsvc primero; borra solo el subfolder Download; vuelve a medir los principales consumidores.

3) “DISM cleanup corrió, pero nada cambió”

Síntoma: WinSxS sigue grande, paquetes recuperables aún mostrados, o no se liberó espacio.

Causa raíz: La limpieza ya se hizo recientemente; no hay nada recuperable. O un reinicio pendiente impide la finalización.

Solución: Ejecuta /AnalyzeComponentStore y revisa “Date of Last Cleanup” y paquetes recuperables. Revisa claves de reinicio pendiente; reinicia en ventana y vuelve a comprobar.

4) “Después de /ResetBase no podemos desinstalar la actualización mala”

Síntoma: Opciones de desinstalación faltantes, rollback bloqueado.

Causa raíz: /ResetBase descarta componentes superseded y rutas de desinstalación por diseño.

Solución: No uses /ResetBase a menos que tu estrategia de reversión sea “restaurar/reconstruir”. A corto plazo, restaura desde snapshot/imagen o mitiga con cambios de configuración.

5) “Los scripts de limpieza hacen más lento el parcheo”

Síntoma: Las actualizaciones se descargan repetidamente; la ventana de mantenimiento se alarga.

Causa raíz: Borrados de caché excesivos fuerzan redescarga y revalidación.

Solución: Añade umbrales y limpieza activada por fallos; conserva cachés salvo que sean el problema.

6) “El disco se llena de nuevo justo después de la limpieza”

Síntoma: Recuperas espacio y luego desaparece en horas/días.

Causa raíz: Reintentos de actualizaciones, parches fallidos, repoblación de caché DO, volcados de crash o logs fuera de control.

Solución: Identifica la fuente de crecimiento con mediciones programadas; arregla fallos de actualización; limita DO; ajusta retención de logs; mueve volcados/logs a un volumen de datos si procede.

Listas de verificación / plan paso a paso

Lista A: Emergencia “C: casi lleno” (15–30 minutos)

1. Mide espacio libre (Tarea 1). Decide si necesitas espacio inmediato para evitar impacto en servicio.
2. Mide los grandes buckets (Tarea 2). No asumas que son actualizaciones.
3. Limpia la caché de descarga de SoftwareDistribution (Tarea 10) si es grande. Suele ser la recuperación más rápida y segura.
4. Limpia la caché de Delivery Optimization si es enorme y no la necesitas (Tarea 11).
5. Vuelve a medir y detente si estás nuevamente por encima de tu umbral operativo (Tarea 15).

Lista B: Limpieza planificada en ventana de mantenimiento (más segura, más profunda)

1. Comprueba reinicio pendiente (Tarea 8). Si hay pendiente, reinicia primero o planifica reinicio después.
2. Analiza almacén de componentes (Tarea 3). Confirma que la limpieza esté recomendada.
3. Escanea salud (Tarea 4). Repara si es necesario (Tarea 5).
4. Ejecuta /StartComponentCleanup (Tarea 6).
5. Sólo si está justificado: considera /ResetBase (Tarea 7) cuando la estrategia de rollback sea restaurar/reconstruir.
6. Comprobación posterior: vuelve a ejecutar el análisis y mide el espacio libre; confirma que Windows Update escanee/instale correctamente.

Lista C: Control continuo (para dejar de apagar incendios)

1. Establece umbrales para limpiar cachés (por ejemplo, SoftwareDistribution > 5 GB activa limpieza).
2. Baselínea el tamaño real de WinSxS y paquetes recuperables mensualmente (guardar salida de Tarea 3).
3. Dimensiona discos OS como adulto: las actualizaciones acumulativas, rollback y logs necesitan margen. Si tu disco OS es pequeño por tradición, la tradición está equivocada.
4. Haz que el parcheo sea aburrido: cadencia consistente, reinicios consistentes, verificación consistente.

Broma #2: La forma más rápida de hacer que un servidor Windows se quede sin disco es programar una reunión llamada “De verdad deberíamos arreglar la utilización de disco”.

Preguntas frecuentes (FAQ)

1) ¿Puedo borrar archivos dentro de C:\Windows\WinSxS para liberar espacio?

No. Puedes reducir el tamaño del almacén de componentes usando DISM, que comprende dependencias de componentes y hardlinks. La eliminación manual rompe el servicing y puede causar fallos en futuras actualizaciones.

2) ¿Por qué WinSxS parece más grande de lo que “realmente” es?

Porque Windows usa hardlinks. El Explorador y sumas recursivas ingenuas pueden contar los mismos datos subyacentes varias veces. La salida de análisis de DISM es la lente correcta para la recuperabilidad.

3) ¿Es seguro borrar C:\Windows\SoftwareDistribution\Download?

Sí, cuando detienes los servicios relacionados con Windows Update primero. Estás removiendo descargas cacheadas, no parches instalados. Windows volverá a descargar lo que necesite.

4) ¿Limpiar SoftwareDistribution romperá Windows Update?

Normalmente no, pero puede resetear el estado de descarga local. Si borras más que el contenido de descarga (o borras mientras los servicios están corriendo), puedes crear errores de actualización que requieran pasos de reparación.

5) ¿Cuál es la diferencia entre /StartComponentCleanup y /ResetBase?

/StartComponentCleanup elimina componentes superseded cuando es seguro y tiende a preservar la capacidad de desinstalación para algunas actualizaciones. /ResetBase es más agresivo y elimina la posibilidad de desinstalar actualizaciones superseded.

6) ¿Cuánto espacio debo mantener libre en la unidad del SO?

Para servidores, apunta a un buffer estable: suficiente para una actualización acumulativa, staging, logs y una ventana de rollback. Prácticamente, mantener al menos 10–20 GB libres (o ~10–15%) evita muchos problemas, pero flotas con parcheo intenso pueden necesitar más.

7) ¿Puedo hacer estas limpiezas de forma remota en muchos servidores?

Sí. Usa PowerShell remoting para ejecutar los mismos pasos de DISM y limpieza de caché, pero añade guardarraíles: captura antes/después, comprueba reinicios pendientes y evita modos agresivos a menos que el servidor esté en estado conocido y bueno.

8) ¿Por qué el espacio libre no aumenta inmediatamente después de la limpieza DISM?

A veces la limpieza se finaliza en un reinicio, o el espacio está retenido por operaciones pendientes. Además, tu medición de carpetas grandes puede estar inflada por hardlinks. Usa DISM analyze y revisa el estado de reinicio pendiente.

9) ¿Debo limpiar la caché de Delivery Optimization en servidores?

Si no te beneficia el peer caching y estás limitado de espacio, sí—límpiala y ponle un tope por política. Si ejecutas muchas máquinas en un sitio, DO puede ser beneficioso; adminístralo en lugar de borrarlo cada noche.

10) ¿Qué pasa si DISM falla con errores de fuente durante /RestoreHealth?

Entonces tu fuente de reparación no está disponible. Necesitarás proporcionar una fuente conocida buena (a menudo un ISO montado que coincida con la build del SO) o configurar una fuente de reparación. No procedas con limpiezas agresivas cuando el almacén no puede repararse.

Próximos pasos que realmente puedes hacer esta semana

• Elige tres servidores que crónicamente estén bajos en C: y ejecuta DISM analyze (Tarea 3). Registra “Actual size”, “Reclaimable packages” y “Last cleanup.” Esa es tu línea base.
• Implementa limpieza de caché basada en umbrales para SoftwareDistribution (Tarea 9 + Tarea 10). No lo ejecutes nightly por defecto; ejecútalo cuando esté realmente grande o cuando fallen las actualizaciones.
• Decide tu postura de rollback antes de usar /ResetBase. Si tu rollback es “desinstalar la última actualización”, evítalo. Si tu rollback es “restaurar snapshot/reconstruir”, puede ser aceptable.
• Dimensiona volúmenes OS como adulto: reserva espacio para actualizaciones acumulativas y operaciones de mantenimiento. El almacenamiento es más barato que el downtime.
• Después de cualquier limpieza, ejecuta un ciclo de escaneo/instalación de actualizaciones con tus herramientas normales. Una limpieza que rompa el parcheo no es limpieza; es sabotaje con pasos extra.

Si tomas un solo hábito de esto: mide con DISM, limpia con DISM y trata la eliminación de cachés como un bisturí—no como una motosierra.