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 un RMM necesita disciplina: inventario, mapeo de catálogo, control por ventana, evidencia de resultado y seguimiento cuando algo falla.
1) Empieza con inventario, no con el comando
Antes de pensar en 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?
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 qué tan importante es cada una.
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.
2) Mapea contra el catálogo correcto
WinGet funciona con fuentes de paquetes. Microsoft documenta que el comando permite descubrir, instalar, actualizar, quitar y configurar aplicaciones en Windows, y que las fuentes de WinGet 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 Store;
- apps que reportan versión de forma incompleta;
- paquetes que requieren acuerdos de fuente;
- apps fijadas o excluidas de actualizaciones automáticas.
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. Si el match es ambiguo, déjalo en revisión en lugar de empujarlo a producción.
3) 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.
Por eso el flujo sano es:
1. Detectar apps instaladas. 2. Mapear paquete WinGet. 3. Probar en un grupo pequeño. 4. Revisar resultado y reinicios. 5. Abrir ventana de mantenimiento. 6. Verificar 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.
4) 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í.
5) 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.
6) 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é ventana aplica;
- qué falló y por qué;
- qué versión quedó instalada después.
Lunixar RMM conecta inventario, monitoreo y parches para que el trabajo no viva como comandos sueltos. La meta no es "correr WinGet". La meta es tener control operativo: saber qué cambiaste, dónde cambió y qué queda pendiente.
Para evaluar el flujo completo, revisa gestión de parches, inventario y monitoreo de dispositivos.
Tip práctico: antes de automatizar actualizaciones masivas, documenta tus reglas de exclusión. Algunas apps de negocio no deben actualizarse sin validación.
