Hay una forma peligrosa de parchear apps de terceros.
Abrir una terminal. Correr todo. Esperar que nada truene.
Eso no es gestión de parches. Es una apuesta.
WinGet ayuda mucho, pero dentro de una operación RMM necesita disciplina: inventario, mapeo de catálogo, exclusiones, ventanas de mantenimiento, evidencia de resultado y seguimiento cuando algo falla.
1) Distingue parches de terceros de Windows Update
Cuando alguien busca gestión de parches de terceros o administración de parches externos, normalmente no habla de Windows Update. Habla de Chrome, 7-Zip, Zoom, lectores PDF, runtimes, herramientas remotas y otras aplicaciones instaladas fuera del sistema operativo.
Ese flujo necesita más control que un comando masivo. Incluso si ya usas Intune, SCCM u otra consola para parches de Windows, las aplicaciones externas siguen necesitando inventario confiable, catálogo, exclusiones, ventanas de mantenimiento y verificación posterior.
La diferencia importante es esta: Windows Update cubre el sistema operativo y componentes relacionados. Un flujo RMM para apps de terceros debe decir qué software existe, qué proveedor lo puede actualizar, en qué endpoints está instalado y qué versión quedó después.
Tip práctico: separa tus reportes de sistema operativo y aplicaciones de terceros. Si mezclas todo, no sabes qué equipo está inseguro por Windows y cuál por una app externa.
2) Empieza con inventario, no con winget upgrade --all
Antes de actualizar, necesitas saber qué existe.
No basta con decir "hay Chrome, 7-Zip, Zoom o algún runtime instalado". Necesitas nombre, versión, publisher, dispositivo y contexto operativo. Si no, terminas actualizando a ciegas.
La pregunta correcta es:
¿qué apps de terceros están instaladas, en qué versión y en qué endpoints?
WinGet puede ayudarte a listar aplicaciones instaladas y también puede mostrar actualizaciones disponibles. Pero en operación MSP eso no basta: necesitas relacionar ese dato con cliente, sitio, criticidad, usuario, ventana y riesgo.
Ese inventario es el puente entre inventario de software y gestión de parches. Sin ese puente, WinGet puede encontrar actualizaciones, pero tu operación no sabe cuál importa primero.
Tip práctico: separa apps por impacto. Navegadores, lectores PDF, herramientas remotas y runtimes comunes suelen necesitar más atención que utilidades poco usadas.
3) Mapea contra el catálogo correcto
WinGet trabaja con fuentes de paquetes. Microsoft documenta WinGet como una herramienta para descubrir, instalar, actualizar, quitar y configurar aplicaciones en Windows. También documenta que las fuentes deben ser seguras y confiables.
Eso importa porque el nombre instalado en Windows no siempre coincide limpio con el identificador del paquete.
Puedes encontrar casos como:
- nombre comercial distinto al package ID;
- versiones instaladas por MSI, EXE o Microsoft Store;
- apps que reportan versión de forma incompleta;
- paquetes que requieren aceptar acuerdos;
- apps fijadas, bloqueadas o excluidas de actualizaciones.
El mapeo serio guarda la relación entre software detectado y paquete candidato. No debería depender de "se parece al nombre".
Tip práctico: usa el ID exacto del paquete cuando puedas, por ejemplo con filtros exactos. Si el match es ambiguo, déjalo en revisión en lugar de empujarlo a producción.
4) Define exclusiones antes de automatizar
No todas las actualizaciones deben correr en automático.
Algunas apps de contabilidad, CAD, ERP, drivers, plugins o herramientas especializadas pueden romper flujos de negocio si cambian de versión sin validación. En esos casos, la exclusión no es flojera: es control operativo.
WinGet tiene mecanismos para limitar o bloquear actualizaciones mediante pins. En un flujo RMM, esa idea debe convertirse en política visible:
- apps permitidas para actualización automática;
- apps que requieren piloto;
- apps bloqueadas hasta aprobación;
- versiones máximas o rangos aceptados;
- excepciones por cliente o endpoint.
Tip práctico: antes de tu primera ventana masiva, documenta una lista de "no tocar sin validar". Esa lista te evita apagar un incendio que tú mismo provocaste.
5) Prueba antes de abrir la ventana de mantenimiento
Un update de terceros puede fallar por permisos, instalador interactivo, apps abiertas, idioma, arquitectura, dependencias o una versión que no se deja reemplazar.
Un flujo sano:
1. Detecta apps instaladas. 2. Mapea paquete WinGet. 3. Marca exclusiones y apps en revisión. 4. Prueba en un grupo pequeño. 5. Revisa resultado, reinicios y errores. 6. Abre ventana de mantenimiento. 7. Verifica que la versión final quedó instalada.
NIST trata la gestión de parches como mantenimiento preventivo, no como una reacción improvisada. Esa mentalidad aplica perfecto aquí: primero planeas, luego ejecutas, luego compruebas.
Tip práctico: define un grupo piloto por cliente o por tipo de endpoint. Si algo falla ahí, todavía estás a tiempo de ajustar antes de tocar toda la flota.
6) No confundas "ejecutado" con "resuelto"
El error clásico es cerrar el trabajo cuando el comando terminó.
Pero un comando terminado puede significar muchas cosas:
- actualizó correctamente;
- no encontró paquete;
- encontró paquete ambiguo;
- pidió interacción;
- falló el instalador;
- la app ya estaba en versión actual;
- necesita reinicio;
- la versión instalada no se pudo leer.
La verificación posterior es donde el RMM gana valor. Vuelves a leer inventario, comparas versión esperada contra versión real y separas éxitos de pendientes.
Tip práctico: mide dos números distintos: ejecuciones completadas y endpoints realmente actualizados. Si solo mides el primero, el reporte se ve bonito aunque la exposición siga ahí.
7) Conecta parches de terceros con vulnerabilidades
No todas las apps pendientes tienen la misma urgencia.
Si una actualización corrige una vulnerabilidad usada activamente, sube de prioridad. Si solo es una mejora menor en una app poco usada, puede esperar a la siguiente ventana.
Aquí conviene conectar este flujo con la gestión de vulnerabilidades en RMM: inventario, CVE, CISA KEV, EPSS, criticidad del endpoint y estado de parche deben hablar entre sí.
También conviene revisar la consola semanal del RMM para que los pendientes no se queden escondidos en una lista eterna.
Tip práctico: crea tres colas: crítico hoy, mantenimiento programado y seguimiento. Eso evita que todo parezca urgente y que lo importante se pierda.
8) Cómo debería verse dentro de un RMM
Un buen flujo de parches de terceros no debería obligarte a brincar entre consola, terminal, hoja de cálculo y ticket.
Debería responder rápido:
- qué apps tienen actualización disponible;
- qué paquete WinGet se usará;
- en qué endpoints se va a ejecutar;
- qué exclusión o pin aplica;
- qué ventana aplica;
- qué falló y por qué;
- qué versión quedó instalada después.
El objetivo no es "correr WinGet". El objetivo es control operativo: saber qué cambiaste, dónde cambió, qué quedó pendiente y qué evidencia puedes mostrar.
Para evaluar el flujo completo, revisa gestión de parches, inventario, monitoreo de dispositivos y reportes RMM.
Tip práctico: si no puedes explicar qué endpoints quedaron actualizados y cuáles siguen pendientes, todavía no tienes gestión de parches. Tienes ejecución remota con suerte.
